Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!usc!snorkelwacker!spdcc!esegue!Postmaster From: johnl@esegue.segue.boston.ma.us (John R. Levine) Newsgroups: comp.os.msdos.programmer Subject: Re: Detecting an 80486 Message-ID: <9008161307.AA11621@esegue.segue.boston.ma.us> Date: 16 Aug 90 17:08:01 GMT References: <26a858b9@ralf> <3817@altos86.Altos.COM> <1990Aug14.025550.17669@esegue.segue.boston.ma.us> Sender: Postmaster@esegue.segue.boston.ma.us Organization: Segue Software, Cambridge MA Lines: 29 In-Reply-To: <3827@altos86.Altos.COM> In article <3827@altos86.Altos.COM> you write: > >In article <1990Aug14.025550.17669@esegue.segue.boston.ma.us> [I wrote]: >> The Intel 486 Programmer's manual has sample code to tell the difference >> among the 8086, 286, 386, and 486 without any trapping at all. > >The code being referenced is on page 22-12 of the Intel "i486 Microprocessor >Programmer's Reference Manual" (PRM) PN 240486. The code on this page does >NOT detect the difference between '386 and '486. Actually, the code to tell a 386 from a 486 is on page 3-42. >> The 486 uses flag bit 18, which the 386 didn't. >Bit18 gets latched on the '486 only in protected mode, and is always cleared >in real mode. On the '386, bit18 is always cleared. Therefore, this >technique WON'T work to detect the '486, ... The manual says that the trap provoked by bit 18, alignment check, won't happen in real mode, but nowhere that I can see do they say anything about bit 18 being forced to zero. (To make alignment checks happen,you have to set the enable bit, bit 18 in CR0, the processor must be in user mode at CPL 3, and you must set flag bit 18.) Has someone tried this and found that you can't set bit 18 in real mode on a 486? (I only have a 386, not a 486, so I can't try it myself.) If flag bit 18 really doesn't work, it might work to try wiggling bit 18 in CR0 which is unimplemented on the 386. Regards, John Levine, johnl@esegue.segue.boston.ma.us, {spdcc|ima|world}!esegue!johnl