Re: Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture
On Sat, May 07, 2016 at 04:14:05PM +0200, Christian Seiler wrote:
> On 05/07/2016 03:59 PM, Geert Stappers wrote:
> > On Sat, May 07, 2016 at 03:23:41PM +0200, Geert Stappers wrote:
> >> My gut feeling says that the package 'sse-support' is sabotage on architecture "any".
Obviously, it's arch specific.
> > This is from #823465 http://bugs.debian.org/823465
Sadly, nope. We'd need to somehow add a (possibly indirect) dependency on
686-support to every single gcc-compiled package on i386.
> > I now have a better idea _why_ a sse-suport package.
> >
> > My concern is how should look a Debian control file at source level ( arch all ).
> > At arch Intel makes a 'Depends: sse-support' sense
> > Having at arch ARM 'Depens: sse-support' also, will prevent install, but not `build`.
>
> I really don't get what you are saying here. Of course one would NOT
> have an arch: any package in Debian that depends on sse-support on
> non-i386, you'd put in Depends: sse-support [i386] in debian/control
> and the package build would then add the dependency on i386, but not
> and anything on other platforms. (If the package in question even
> supports other platforms than x86 in the first place.)
I'd guess a package that has generic code paths is unlikely to have such a
strict dependency (although sse2 is so old that a number-crunching package
probably won't bother with runtime detection).
> Why so critical? The current situation is that if there's a package
> in the archive that now only works with SSE extensions, and is not
> easily portable to non-SSE (for example, if it contains hand-written
> assembly code), then the only recourse that's available _now_ is to
> drop i386 from that package's architecture (because it will segfault
> without a good error message) - or to add detection in preinst...
Detection in preinst is exactly what sse-detect is for, yeah.
> @Adam: One suggestion though: since this might also come in handy
> in other places, I'd recommend you name the source package something
> more generic (such as cpu-support or so, assuming that's not taken
> already, I didn't check), and have it generate a binary package with
> the name sse-support. I'm pretty sure that other cases could come up
> with a similar requirement in the future, and that way they'd easily
> find a home.
Good idea! The test harness is already templated, so there's no reason to
make this x86 specific.
I think I'll put the master list as an 822-formatted file like:
.--====
Name: sse2
Architecture: any-i386
Instruction: addpd %xmm0, %xmm1
Name: sse3
Architecture: any-i386 any-amd64 x32
Instruction: haddpd %xmm0, %xmm1
Name: fp11
Architecture: pdp11
Instruction: ldbt
`----
which on pdp11 will generate fp11-support which will do the right thing
(assuming I read the docs correctly, I don't know PDP-11 assembly :þ).
Meow!
--
How to exploit the Bible for weight loss:
Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat.
Reply to: