Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!apple!altos!altos86!rcollins From: rcollins@altos86.Altos.COM (Robert Collins) Newsgroups: comp.os.msdos.programmer Subject: Re: Detecting an 80486 Message-ID: <3827@altos86.Altos.COM> Date: 15 Aug 90 20:48:50 GMT References: <26a858b9@ralf> <3817@altos86.Altos.COM> <1990Aug14.025550.17669@esegue.segue.boston.ma.us> Reply-To: rcollins@altos86.UUCP (Robert Collins) Organization: Altos Computer Systems, San Jose, CA Lines: 76 In article <1990Aug14.025550.17669@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes: > 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. > There are > lots of differences other than new instructions. For example, on a PUSH SP, > the 8086 pushes the decremented SP but newer processors push the original > value. Which is exactly how my subroutine detects an 8086/80186. Since the 8086 has no capability to trap invalid opcodes, you must do this first before using opcodes not in the CPU. > When you push the flags register with PUSHF, the 8086 always sets > bits 12-15 to one, the 286 always sets them to zero, and the 386 and 486 > store some actual flags there. The 486 uses flag bit 18, which the 386 > didn't. Intel provides sample code that is straightforward and doesn't > depend on catching traps. Looks good to me. I looked for documentation to verify this and found that the '286 manual makes no mention of any flags differences with the 8086. That's not to say they don't exist. However, in the '386 PRM the difference of the flags register of the '386 vs. 8086 IS documented; but in differences with the '286 no flags difference is documented. > Sounds perfect. Does anyone have this online already ? If not, does > anyone who has the 486 programmer's wanna type it in ? You peaked my curiocity. I typed it in. If I am following this discussion correctly, the intension is to have a program that detects the differences between CPU's that will work in real mode, protected mode, and virtual 8086 mode. The algorithm that Intel provides makes no attempt to detect the '486. So, with that in mind, I took their same approach, and applied it to bit 18 of EFLAGS in an attempt to detect the '486. This approach won't work in real mode, but does in protected mode. 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, and is therefore less than "perfect." Furthermore, it might be noted, that the algorithm Intel provided is documented as follows: "This code is intended for application programs executing in real-address mode" (P. 22-11). Now, back to my original point of mode-independant CPU detection. As I pointed out in a previous posing, I believe that the manufacturers of QEMM, et. al. who don't pass control of INT6 to the user-program are in error, and in jeopordy of being "incompatible" with software that was written in accordance with the original '386 PRM. There is still a lot of code out there that hasn't been changed. (Hopefully this won't sound like "my code is better than your's...but.) The code I wrote is totally mode-independant. It works in real mode. It works in protected mode (with some obvious changes to the interrupt trapping mechanism). And it works in VM86 mode -- provided the host kernal passes control to the INT6 handler defined in the V86 task. I think it should be obvious that software that doesn't follow this convention is circumventing the whole idea of V86 tasks. Imagine if INT0, INT1, INT3, or INT4 weren't passed to the V86 task! In fact, I would go so far as to say that ALL CPU-generated interrupts that are defined on the 8086 and 80186 should be passed to the V86 task... and guess what? That list includes INT6 -- invalid opcode. -- "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