No,
The way you check if SSE FP / xmm is supported is to issue an
instruction with an xmm operand inside of a try catch loop:
try
{
issue asm which uses xmm registers such as:
pxor xmm0 xmm1
}
catch(...)
{
if you get here an illegal instruction exception occurred then xmm
registers are not supported.
}
Incidentally, in our case, just having an Atholon XP with Windows XP does
not mean support for xmm / SSE FP. Your BIOS needs to support it as well.
We have on machine in our test labs that is exactly this case. Atholon
2400+ XP with Win XP and no support for xmm / SSE FP.
AMD has a great sample program for determining which CPU flags are
supported. You can find it at:
http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_871_2364,00.html
Aron Rosenberg
SightSpeed Inc.
<p>At 08:36 PM 1/17/2004 +0100, you wrote:>Greetings,
>
>
>my apologies for putting this trash in the mailing list but the topic
>about SSE run-time option interested me pretty much.
>Looks like some people is really experienced on the topic. I would really
>appreciate if somebody could point me to good resources about SSE and
>Altivec (not necessarly on the net, I'm ready to invest some money if
>necessary). I already have intel manuals about SSE and I took a look at
>Intel's document proposed by Ian.
>
>I was somewhat shocked by reading a mail posted by Jan-Marc (Date: 14 Jan
>2004 02:44:59 -0500). I guess I badly misunderstood it by jumping to wrong
>conclusions but does this means the only way to recognize if (say) SSE is
>supported by OS is to check its version?
>This looks something problematic to me especially for open-source OSs
>where one can recompile the kernel as he wants - kernel version number may
>not really be representative of the functionalities supported.
>
>
>Thank you,
>Massimo
<p>--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'speex-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
IIRC this try/catch trick only works for windows. On Unix, the only way
I found was to catch the SIGILL and use setjmp/longjmp.
Jean-Marc
Le sam 17/01/2004 à 15:17, Aron Rosenberg a écrit :> No,
>
> The way you check if SSE FP / xmm is supported is to issue an
> instruction with an xmm operand inside of a try catch loop:
>
> try
> {
> issue asm which uses xmm registers such as:
> pxor xmm0 xmm1
> }
> catch(...)
> {
> if you get here an illegal instruction exception occurred then xmm
> registers are not supported.
> }
>
> Incidentally, in our case, just having an Atholon XP with Windows XP
> does not mean support for xmm / SSE FP. Your BIOS needs to support it
> as well. We have on machine in our test labs that is exactly this
> case. Atholon 2400+ XP with Win XP and no support for xmm / SSE FP.
>
> AMD has a great sample program for determining which CPU flags are
> supported. You can find it at:
>
>
http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_871_2364,00.html
>
> Aron Rosenberg
> SightSpeed Inc.
>
>
> At 08:36 PM 1/17/2004 +0100, you wrote:
> > Greetings,
> >
> >
> > my apologies for putting this trash in the mailing list but the
> > topic about SSE run-time option interested me pretty much.
> > Looks like some people is really experienced on the topic. I would
> > really appreciate if somebody could point me to good resources about
> > SSE and Altivec (not necessarly on the net, I'm ready to invest
some
> > money if necessary). I already have intel manuals about SSE and I
> > took a look at Intel's document proposed by Ian.
> >
> > I was somewhat shocked by reading a mail posted by Jan-Marc (Date:
> > 14 Jan 2004 02:44:59 -0500). I guess I badly misunderstood it by
> > jumping to wrong conclusions but does this means the only way to
> > recognize if (say) SSE is supported by OS is to check its version?
> > This looks something problematic to me especially for open-source
> > OSs where one can recompile the kernel as he wants - kernel version
> > number may not really be representative of the functionalities
> > supported.
> >
> >
> > Thank you,
> > Massimo
--
Jean-Marc Valin, M.Sc.A., ing. jr.
LABORIUS (http://www.gel.usherb.ca/laborius)
Université de Sherbrooke, Québec, Canada
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Ceci est une partie de message numériquement signée.
Url :
http://lists.xiph.org/pipermail/speex-dev/attachments/20040117/b22c2c9d/signature-0001.pgp
Greetings, <p>my apologies for putting this trash in the mailing list but the topic about SSE run-time option interested me pretty much. Looks like some people is really experienced on the topic. I would really appreciate if somebody could point me to good resources about SSE and Altivec (not necessarly on the net, I'm ready to invest some money if necessary). I already have intel manuals about SSE and I took a look at Intel's document proposed by Ian. I was somewhat shocked by reading a mail posted by Jan-Marc (Date: 14 Jan 2004 02:44:59 -0500). I guess I badly misunderstood it by jumping to wrong conclusions but does this means the only way to recognize if (say) SSE is supported by OS is to check its version? This looks something problematic to me especially for open-source OSs where one can recompile the kernel as he wants - kernel version number may not really be representative of the functionalities supported. <p>Thank you, Massimo <p><p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'speex-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> On Intel, there is a instruction you can use to find out what version of > the CPU you have and by extension what level of vector support it > provides. One problem is that this instruction isn't on every processor > you are likely to run across, so you still have to do the try/catch method > to determine if that instruction is available. Intel has written some code > that does this into libpr0n, which is the native image library for > Mozilla. You can take a peak at that if you like. They also discuss it in > their software optimization manuals.Well, cpu detection is one thing (the instruction is "cpuid"), but the main problem is detecting that the OS supports the xmm resgisters. That's where it was simpler to just try something and catch the illegal instruction. Maybe there's a special register in the CPU where that the OS sets when it supports SSE, but I haven't found it. Jean-Marc -- Jean-Marc Valin, M.Sc.A., ing. jr. LABORIUS (http://www.gel.usherb.ca/laborius) Université de Sherbrooke, Québec, Canada -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: Ceci est une partie de message numériquement signée. Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20040117/84f459be/signature-0001.pgp
On MacOS, the preferred way to detect AltiVec is to query the OS. The OS
itself does a runtime detection of the hardware capabilities. If it was
staticly defined at compile time, someone could just compile the OS on one
machine and write the OS onto a hard drive, move the drive to another
machine, try to boot off it and crash.
There are a couple of different ways to do this on MacOS. These are
described here:
http://developer.apple.com/hardware/ve/g3_compatibility.html
On Intel, there is a instruction you can use to find out what version of
the CPU you have and by extension what level of vector support it
provides. One problem is that this instruction isn't on every processor
you are likely to run across, so you still have to do the try/catch method
to determine if that instruction is available. Intel has written some code
that does this into libpr0n, which is the native image library for
Mozilla. You can take a peak at that if you like. They also discuss it in
their software optimization manuals.
Ian
---------------------------------------------------
Ian Ollmann, Ph.D. iano@cco.caltech.edu
---------------------------------------------------
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'speex-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
On 17-jan-04, at 23:29, Ian Ollmann wrote:> > On MacOS, the preferred way to detect AltiVec is to query the OS.FWIW, it's the same on Linux. But that doesn't work with too old kernels. The SIGILL thing is 100% fully portable to any POSIX compliant systems... Not that I recommend it if the OS-querying interface is in place; that interface will also give you nice information like cache-line size etc. <p>Segher --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'speex-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.