On Tue, May 06, 2003 at 03:05:21PM +0200, Guillem Jover wrote: > Hi, > > On Mon, May 05, 2003 at 06:27:05PM -0400, Nathanael Nerode wrote: > > After the 486, Intel always provided a method to determine the CPU type and > > features available. As far as I can tell, there's no easy programmatic way > > to tell the difference between a (old, no CPUID) 486 and an (old, no CPUID) > > 386 without risking an illegal instruction, which bites. :-( (I could be > > wrong.) > > They exist and are not so difficult. One is by issuing illegal > instructions like you have commented, the only thing to do is to trap > INT 6 (Invalid Opcode). The only problem you may find is that really old > cpus don't support this INT (only 80186+). > > The other is a little bit more fun, you have to test for cpu specific > non-documented behaviour, like how many bits shift a shl in a 8088 or > 80186+, when does the cpu increment the sp (stack pointer) when doing > a push/pop, which flags can or cannot be set, etc. I did some years ago > asm code that distinguished from 8088 to the new CPUID aware cpus, > including the distinction from 8086 and 8088, or from NEC V20 among > others. =P > > And I've seen code that did more insight testing. (I can give > code / pointers to anyone interested). > Note: the CPU manuals from Intel include an official assembler sequence which does not generate exceptions or anything. The 16 bit version requires ring 0 privileges, the 32 bit version does not. Distinguishing amongst pre-CPUID submodels (like 386DX versus 386SX or Intel 386 versus AMD 386 takes more tricks), but the code cleanly distinguishes 086 from 186 from 286 from 386 from 486-noCPUID from CPU-with-CPUID. > regards, > guillem > -- This message is hastily written, please ignore any unpleasant wordings, do not consider it a binding commitment, even if its phrasing may indicate so. Its contents may be deliberately or accidentally untrue. Trademarks and other things belong to their owners, if any.
Attachment:
pgp65LxmhcbtX.pgp
Description: PGP signature