🚀 go-pugleaf

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