Alternate encodings of 80287 instructions in 486 NDP???

[Kevin Lawton]

I noticed in a book on the 286/287, there are a couple entries
in the opcode table for 287 instructions which are listed as
"redundant opcode". For instance, the instruction

FCOM ST,ST(i)

has a primary encoding of

ESC 0 FCOM ST(i)
11011 000 11 010 iii

but also a redundant encoding of

ESC 4 FCOM ST(i)
11011 100 11 010 iii

Does anyone have any experience with these. I'm curious why I haven't
seen alternate encodings listed in other books.

Do the 386/486 support these alternate encodings of NDP instructions?

Thanks much.
Kevin P. Lawton
k...@ll.mit.edu

+----------------------------------------------+
| "How does he know we're going the wrong way. |
| He doesn't know where we're going." |
| |
| John Candy, "Planes, Trains and Automobiles" |
+----------------------------------------------+

[|S| Norbert Juffa]

In <1994Mar19.0...@ll.mit.edu> k...@ll.mit.edu writes:

> I noticed in a book on the 286/287, there are a couple entries
> in the opcode table for 287 instructions which are listed as
> "redundant opcode". For instance, the instruction
>
> FCOM ST,ST(i)
>
> has a primary encoding of
>
> ESC 0 FCOM ST(i)
> 11011 000 11 010 iii
>
> but also a redundant encoding of
>
> ESC 4 FCOM ST(i)
> 11011 100 11 010 iii
>
>
> Does anyone have any experience with these. I'm curious why I haven't
> seen alternate encodings listed in other books.
>
> Do the 386/486 support these alternate encodings of NDP instructions?
>
> Thanks much.
> Kevin P. Lawton
> k...@ll.mit.edu

Intel 387, Cyrix 83D87, IIT 3C87, and Intel 486DX support the redundant
encodings that are listed in the Intel 287 User's manual. Probably the
ULSI 83C87 also supports them, but I am not sure about that one (I don't
have one at home currently to check). Using the alternate emcodings doesn't
buy you anything, except for the questionable advantage that they offer a
FFREEP instruction that has no corresponding "legal" encoding. My advice
would be to stay away from these encodings. It seems the redundant opcodes
originally were introduced by incomplete opcode decoding inside the 287.
They were not intended to be used at all, but as he story goes, some
assemblers/compilers at that time used the alternate encodings anyhow, so
they had to be put into subsequent math coprocessor as well so code produced
by these assemblers/compilers would not break.

-- Norbert Juffa (s_j...@iravcl.ira.uka.de)