• Please review our updated Terms and Rules here

Undocumented Instructions on Intel 8088 and NEC V20

sergey

sergey

Veteran Member
Joined
Jul 15, 2010
Messages
880
Location
Silicon Forest, Oregon, USA
Today, in my quest to find ways for identifying various 8088 clones, I tested behavior of some undocumented instructions on several 8088-compatible CPUs that I have (inspired by this post).

Processors tested:
NEC V20HL (improved V20)
Intel 8088 - Early 1978 version (one with MOV SS bug)
Intel 8088 - Later 1983 version
Intel 80C88A - Early version, apparently manufactured by OKI
Intel 80C88AL - Manufactured by Intel (designed by Harris?!)
KR1810VM88 - Soviet 8088 clone
AMD 8088
NEC 8088

Instructions tested:
D6 (SALC)
F1 (INT1)
FF FF (??? DI)

To my disappointment I didn't find any new ways to differentiate between 8088. On 8088 clones these instructions behaved the same.
- Both original Intel 8088 chips and all clones executed D6 as SALC (if {CF == 0} {AL = 0} else {AL = FF}). NEC V20HL executed D6 as XLAT.
- All processors including V20 ignored F1 (INT1) and did a 2-byte NOP instead. Perhaps it was implemented in later processors? Or maybe I messed up in my test code...
- All processors including V20 executed FF FF as PUSH DI. I think I have an explanation for this behavior. For whatever reason Intel implemented two versions of PUSH reg and POP reg instructions - a one byte instruction (5x in case of PUSH, e.g. 57 for PUSH DI) and two bytes instruction (FF F7 for PUSH DI). It looks that processors will not decode 4th bit of the second byte, and so FF FF is executed as FF F7. I verified it on other registers, and indeed FF F8 is executed as PUSH AX, FF F9 is executed as PUSH CX, and so on...

It is interesting though that NEC V20 is different in many aspects from NEC 8088 (which is behaves exactly like Intel 8088). Given that NEC had access to 8088 design I am wondering if NEC intentionally not implemented undocumented 8088 instructions, or it perhaps it was a side effect of the "clean room" V20 development process. The two byte PUSH / POP case is especially puzzling. Why NEC choose to implement two byte PUSH, including the non-documented FFFF version, but it didn't implement two byte POP?

Counting NEC V20 and 8088 differences I have the following:
AAD/AAM - Intel 8088 honors the second byte (operand), NEC V20 ignores it and always uses base 0Ah (10)
D6 executed as SALC by 8088 and as XLAT by NEC V20
Following interrupts NEC V20 resumes executing string instructions with both segment override and REP prefixes. 8088/80C88 won't do that.
NEC V20 doesn't properly implement two byte POP (8F Cx)
And the obvious - NEC V20 can execute 80186 instructions (e.g. PUSHA), while 8088 can't.

As far as differences between 8088 versions I have:
- Early Intel 8088 (MOV SS / POP SS bug) - easily detected by executing POP sreg in single step, buggy processor will do single step interrupt after that instruction, fixed 8088 (1981+ and all non-Intel clones) will skip to the next instruction.
- Harris 80C88, MHS 80C88, Intersil 80C88, and Intel 80C88AL also skip interrupts following PUSH sreg, while all NMOS 8088 versions and OKI 80C88 process interrupts normally.
 
At least the Intel versions of the 8088 and 8086 didn't actually disable 0F - POP CS, allthough they never documented it either (for good reasons). I don't know if it is interepted as an unconditional branch, or if the prefetch queue is left intact after the jump (!). It's actually just a variation of the regular POP seg. instructions so there may be a posibility that it isn't handeled any different compared to the other variations.
 
per said:
At least the Intel versions of the 8088 and 8086 didn't actually disable 0F - POP CS, allthough they never documented it either (for good reasons). I don't know if it is interepted as an unconditional branch, or if the prefetch queue is left intact after the jump (!). It's actually just a variation of the regular POP seg. instructions so there may be a posibility that it isn't handeled any different compared to the other variations.
Click to expand...

I actually tested POP CS and MOV CS,reg/mem some time ago. All 8088 processors and NEC V20 execute these instructions as unconditional JMP - CS is changed with the new value, IP is advanced to the next instruction. This includes Intersil 80C88 for which the datasheet specifically says that "MOV CS, REG/MEMORY not allowed." (page 36). And by the way it doesn't say anything about POP CS (page 29 of the same datasheet).
 
Actually, there are a lot of differences between 8088 and V20 instruction sets, including a second ESC opcode for a different coprocessor, the 8080 emulation instructions, as well as the BCD string instructions.

But you knew that...
 
sergey said:
I actually tested POP CS and MOV CS,reg/mem some time ago. All 8088 processors and NEC V20 execute these instructions as unconditional JMP - CS is changed with the new value, IP is advanced to the next instruction. This includes Intersil 80C88 for which the datasheet specifically says that "MOV CS, REG/MEMORY not allowed." (page 36). And by the way it doesn't say anything about POP CS (page 29 of the same datasheet).
Click to expand...

Along these lines, I gave up trying to determine whether or not 8088 or 80C88 was installed (I remember our email conversations). Were you able to get any further with this, or is the 80C88 simply identical to 1981+ 8088s?
 
sergey said:
Counting NEC V20 and 8088 differences I have the following:
AAD/AAM - Intel 8088 honors the second byte (operand), NEC V20 ignores it and always uses base 0Ah (10)
Click to expand...

Did you verify this for both instructions? I'm asking because someone seems to think AAM with an operand other than 10 should work on the NEC V processors;
Code: 
; aam imm:  ah = al / imm, al = al % imm.
; This should work on the NEC V20/V30, unlike aad.

I'm guessing he's wrong but would appreciate if someone could confirm this.
 
IIRC, it works on the V20/V30--but I can verify if desired. It'd break a lot of code otherwise.

Just verified it:

AX=0015->D4 0A->AX=0201
AX=0015->D4 05->AX=0401

Okay? Now please put that notion where it belongs. Common sense should have told you the answer.

Now, there may be other processors, NEC and otherwise, such as the V60/V70, where that does not obtain, but I don't have systems with those installed. If they work on the V20 though, they'll work on the V40/V50 also.
 
Last edited:
See my amended post above yours--I just did! Good thing that I didn't have to go digging a V20 system out of the pile.

808x compatibility was the top of the list when I talked to the guys in Natick. I did find a couple of issues, however with the 8080 emulation feature. JRT Pascal 1.0-compiled programs die on the thing in 8080 mode. Something about using the byte just before a target of a call to store the return address stack...my memory is a little fuzzy on that one. But JRT Pascal was the only commercial program that had the problem that any of us found. It's probably documented in some of the V-series MicroNotes.
 
Last edited:
Thanks! I've put that notion where it belongs. :) I don't recall where I got it to begin with though when searching the web I find several places saying that this doesn't work on NEC processors. Here's an example.
 
You must log in or register to reply here.
Back
Top