Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!apple!vsi1!altos!altos86!rcollins From: rcollins@altos86.Altos.COM (Robert Collins) Newsgroups: comp.os.msdos.programmer Subject: Re: Detecting an 80486 Message-ID: <3839@altos86.Altos.COM> Date: 20 Aug 90 16:26:59 GMT References: <26a858b9@ralf> <3817@altos86.Altos.COM> <1990Aug14.025550.17669@esegue.segue.boston.ma.us> <9008161307.AA11621@esegue.segue.boston.ma.us> Reply-To: rcollins@altos86.UUCP (Robert Collins) Organization: Altos Computer Systems, San Jose, CA Lines: 46 In article <9008161307.AA11621@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes: > >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. > You can't access CR0 in CPL3. So setting any bit in CR0 in V86 mode will be trapped. I have tried setting bit18 in EFLAGS, and found it not to be latched in real mode. I found this astonishing, and therefore posted my results. Since that posting I did further testing, and found my first conclusion to be wrong. ----------------------------------- Continuation of a posting that I didn't get a chance to finish: ----------------------------------- As I said in another posting, trapping invalid opcodes, and setting undefined bits in EFLAGS both have their pitfalls, and both are seemingly valid techniques for determining CPU type. However, setting undefined bits in EFLAGS relies on (apparently) undocumented default settings for these bits in EFLAGS. Deep down inside, I still feel more comfortable trapping invalid opcodes because this method relies on documented differences in the CPUs. Another consideration is upward compatibility, and expandability. What about the '586? Will the '586 behave in the same manner -- that isn't documented? Since Intel published the CPU detection code themselves, that is a good chance that the '586 will behave in the same manner. But this conclusion assumes that the guy that wrote the code has good connections in the CPU department. If have found that Intel isn't like this at ALL. One hand doens't know, nor have access to, what the other hand is doing. So, just because Intel published the code, and the code relies on undocumented features of the chip, doesn't guarantee the code will work on the '586. Chosing which algorithm to use now becomes a consideration of the '586. Which probability is greater: the '586 having another new non-intrusive opcode, or the '586 having another new bit in EFLAGS? -- "Worship the Lord your God, and serve him only." Mat. 4:10 Robert Collins UUCP: ...!sun!altos86!rcollins HOME: (408) 225-8002 WORK: (408) 432-6200 x4356