"wacky sub-architectures?" I beg to differ. :-) There are really only 4, and I think I can argue them down to two, at least for Intel boxes.
In the beginning was the Intel 386, and its pipelined younger brother the 486. And between Intel and AMD, a lot of those chips got sold and most of the world loved them for it. Then came the Pentium, and with its 2nd generation, the MMX integer SIMD instructions. Pentium II also included MMX. Next came the Pentium III, which had MMX and the single precision version of MMX, called SSE. I'm leaving out the Pentium Pro because those chips shipped mainly into servers. Then came the Pentium 4, with MMX, SSE, and the double-precision version of SSE, called SSE2. This progression occurred because of the algorithm being followed at Intel: put in whatever fits, and make sure the memory bandwidth to support it is there. I'll be really surprised if enough interesting sound work was being done on 386's and 486's that we need to even remember those. In fact, are there really enough Pentium boxes remaining in the field to care about them and their MMX-only capability? I'm not so sure about Pentium II machines, which were shipped as high as 400 MHz, and might be still fast enough and widely enough used that we still care about them in this context. To look at all this another way, what's the problem if we restrict our attention here to just Pentium III and newer designs? If the new instruction sets are enough of a win to ever use, then they're also enough of a win to entice people to buy up. They have to, sooner or later. -Bob Colwell -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Steve Harris Sent: Monday, February 18, 2002 7:23 AM To: [EMAIL PROTECTED] Subject: Re: [linux-audio-dev] MMX, SSE, SSE2, 3DNOW On Sat, Feb 16, 2002 at 09:09:24 +0100, Alexander Ehlert wrote: > Hi, > > AFAIK there are no flags whatsoever to indicate which processor a plugin > might use. So if someone wants to hack a plugin that uses SSE > instructions and someone else tries to use that on a host without SSE > support -> crash. So wouldn't it be good to add some architecture flags, > that could be queried by the host? So far, I have only distributed binaries in RPM only, which has architecture dependencies. Actually they are wrongly labelled as i386, they are really i686. I don't think the plugin should pick a code block based on some detection code, that would make the plugins image larger, and therefore less efficient. There are far too many wacky sub-architectures of x86's to include SIMD instructions for all of them in one binary. I have plyed with multi-format binaries (see mail later today), and it is tricky. I think the right thing to do is to take the same approach as with normal libraries and binaries, and label the packages. - Steve
