Since the original 8086 and 8088 do not have a software exception for illegal instructions, how do they behave when fed such, for instance "FF FF" (not an opcode) ? Do they stall, do it reset itself, possibly emitting a special cycle indication on its control bus ?
A:
If memory serves, Intel's official claim was that they were all NOPs.
In reality, at least a few of the undefined op-codes do execute as real instructions that produce results. For example, the second byte of AAD or AAM is 00001010. That converts to 10 in decimal. If you execute an instruction with the same first byte as one of those (11010101 or 11010100 respectively), but change the second byte to another value (say 00000100), it'll do the same basic thing, but in the base you've specified (octal for 00000100).
Edit: You seem intent on turning your question into one that almost nobody can really answer. You started by asking about undefined op-codes, but then restrict it to some subset of those Intel said were undefined, and only want to know about those that were really, truly undefined (by some definition that apparently exists only in your head).
The only question that seems answerable at all is "what did ffff do?" At one time I might have been able to answer that, but about all I can say any more is "apparently nothing memorable."
As for claiming it can't be right, you seem to be mistaking this for something Intel really cared about. For the most part, undocumented op codes were exactly that: undocumented. They went to considerable effort to document how things would work when you followed the "rules", but mostly ignored what would happen otherwise.
From the sound of things, about all that will satisfy you is a real 8088/8086 that's still operational that you can test with. I wish you the best of luck with finding that.
Jerry Coffin
2010-05-11 15:22:28
"If memory serves, ... they were all NOPs"I have a hard time believing that : how would the CPU know the *length* of the illegal instruction, IOW, how many bytes to skip after the supposed NOP ? No, it can't be right. Thanks anyway.Somebody else ? Maybe someone with a 8086 in working order can check the real thing (e.g. in DEBUG)
Ninho
2010-05-11 21:10:54
On seing my comment above, I regret the phrasing "it can't be right", please do not take offence. Addition : Please note original question is about truly /invalid/ opcodes (if any...), not 'bout so-called undoumented (and by now well known) ones including aliased versions of doc'd operations.To be specific, are you all saying executing a sequence starting "FFFF" on a 8086 or 8088 would have just incremented IP by 2 and continued fetching/executing opcodes ?
Ninho
2010-05-12 08:41:33
Re: Jerry Coffin's edit: Beyond doubt there exist ppl who either know the answer or would be in a position to do meaningful tests, this is why I cared to ask (here and on Usenet group c.l.a.x.) Whether such people will see my question and bother to (research and) reply remains to be seen. Acquiring a PC fossil is not practical for this old man, and not worth the expense either. Thank you very much indeed (first time user of this question board; am I supposed to give you credits of sort or otherwise acknowledge your good will?)
Ninho
2010-05-12 13:42:57
A:
If you are really interested, you can purchase the appropriate components from Jameco (they sell pulls for 8088, 8086, and even the NEC V20 CMOS "turbo" clone) and build a simple/small machine to test it out.
Chris D.
2010-09-28 00:46:50