Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!husc6!spdcc!ima!esegue!Postmaster From: johnl@esegue.segue.boston.ma.us (John R. Levine) Newsgroups: comp.os.msdos.programmer Subject: Re: Detecting an 80486 Message-ID: <9008211347.AA05979@esegue.segue.boston.ma.us> Date: 21 Aug 90 17:47:10 GMT References: <26a858b9@ralf> <3817@altos86.Altos.COM> <1990Aug14.025550.17669@esegue.segue.boston.ma.us> <9008161307.AA11621@esegue.segue.boston.ma.us> Sender: Postmaster@esegue.segue.boston.ma.us Organization: Segue Software, Cambridge MA Lines: 33 In-Reply-To: <3839@altos86.Altos.COM> In article <3839@altos86.Altos.COM> you write: >Deep down inside, I still feel more comfortable trapping invalid opcodes >because this method relies on documented differences in the CPUs. Do keep in mind that every Intel CPU appears to have secret, undocumented opcodes. The 8086 has POP CS (useful, huh?) The 286 has the infamous LOADALL. Early 386 chips had bit insert and extract instructions which they removed when they noticed that you could do the same thing faster via double register shifts. I expect that the 386 and 486 also have something like LOADALL to aid testing. History suggests that when clone CPUs come out, the vendors won't leave well enough alone and will add new instructions of their own, viz. the V20 and V30 which have some instruction that puts you into Z80 mode. Expecting undocumented opcodes to fail seems to me a fragile way to test CPU types, independent of the difficulty of persuading operating systems to give you control back after the trap, since they might do something else already. Even worse, I can easily imagine that 386 operating systems will for upward compatibility purposes simulate the new 486 instructions, albeit very slowly, so that any test that depended on BSWAP not working would fail. I can cite lots of cases of this in the past, such as the Microvax which only implements about 80% of the Vax instruction set in hardware with the obscure instructions simulated by the operating system, or early versions of VM/370 which when run on a 360/67 would simulate the new 370 instructions so they could debug new 370 software. For that matter, consider the way that most 386 operating systems simulate a missing 387. The 486 manual explicitly documents the flag peculiarities that their sample code uses to test CPU types. They're not totally foolish, I expect that they'll try not to break the test code in the future chips. Regards, John Levine, johnl@esegue.segue.boston.ma.us, {spdcc|ima|world}!esegue!johnl