Tuesday, July 11, 2006

Here is another little misconception:
CPU Capability detection coming to a BOINC client near you soon

BOINC does not use the processor's CPUID instruction to determine what instruction sets are supported.

Using CPUID is a good idea if you are an OS, but it is a bad idea if you are an application. There are two parts to the supported instruction set problem, one is the CPU and the other is the OS.  If your OS doesn't support the desired instruction set you are just asking for trouble.

Here is an example of what I mean. Let us take Windows 95 Gold without any patches, and a modern single core processor.

Back when Windows 95 was released MMX and 3DNow was just taking off and SSE wasn't mainstream. MMX still used the standard 80-bit x87 floating point registers and so the OS really didn't have to do anything new to support it. A thread context therefore only had to worry about the general purpose registers, floating point stack registers, and debug registers and everything for the thread stayed consistent when the OS changes execution to another thread.

Now enter modern processors, with the introduction of SSE new registers were added to the CPU. Registers XMM0-XMM7. If the OS doesn't know about those registers it cannot save the registers before moving on to another application. In the worst case scenario you could have data from your favorite DVD interfering with a BOINC Science application since they'll both be overwriting one another's register values. E@H processing TV signals and your DVD player displaying E@H data as video artifacts.

It appears Intel and AMD created something known as enhanced protected mode which exposes the additional SSE registers otherwise they stay hidden from applications and the OS if the OS doesn't initialize itself as enhanced protected mode aware. So if you are attempting to run an SSE application on a CPU/OS combination that doesn't support it you should get an illegal instruction error or privileged instruction error.

Apparently AMD decided to increase the number of registers available on the AMD64 line from 8 to 16, but I don't currently know if this is only for 64-bit OS's or for both 32-bit and 64-bit OS's. If there isn't a special safe guard the OS has to follow, things could end up like the DVD player scenario I mentioned above.

So BOINC queries the OS for what instruction sets are supported, if the OS can detect it, it should support it.

On Windows, the function is called IsProcessorFeaturePresent().

On Linux, we currently read /proc/cpuinfo.

On the Mac we'll probably be using sysctl().

----- Rom

References:
http://en.wikipedia.org/wiki/IA-32

Tuesday, July 11, 2006 1:17:51 PM (Eastern Daylight Time, UTC-04:00)
What about FreeBSD, Ron?

Oh and have you got my email about this?

Personally I don't understand your mistrust to cpuid. How do you think Linux obtains that /proc/cpuinfo data? Yes, using cpuid instruction. No, it's not filtering out features applications can't use. And /proc/cpuinfo is rather non-portable to other Unixes.
Pav Lucistnik
Tuesday, July 11, 2006 3:22:14 PM (Eastern Daylight Time, UTC-04:00)
Somebody just needs to submit a patch for FreeBSD.

It isn't exactly mistrust of CPUID, I'm well aware of the fact that the OS's use CPU ID to discover that information.

In order for that information to be put into the /proc/cpuinfo virtual file it has to be run through a translation process. All the CPU returns is a collection of bits. Some chunk of code converted those bits into human readable text.

If some new bit shows up that the kernel doesn't check for, it won't show up in the list of CPU features since it doesn't know what that bit means.

----- Rom
Thursday, July 13, 2006 7:28:16 AM (Eastern Daylight Time, UTC-04:00)
Patch for FreeBSD is in your mail by now, Rom.
Pav Lucistnik
Comments are closed.