In article <1993Jan11.191838.10819@odin.diku.dk> dingbat@diku.dk (Niels Skov Olsen) writes:
quoted text
>
>  # smlnj
>  Standard ML of New Jersey, Version 0.91, October 26, 1992
>  This is an alpha version for Linux (built with Linux 0.98.1).
>  val it = () : unit
>  - 2.0; 
>  Unimplemented FPU Opcode at eip=0003B144 : dc d4 (d0+4)
>
>  uncaught exception Div

Wow.  What are you (or rather smlnj) doing that results in that
operation? The fp-operation DC D4 isn't a normal floating point
instruction, although it does actually execute the "fcom st(4)"
instruction on a real coprocessor.  The official code for "fcom st(4)"
is D8 D4, and the DC D4 sequence shouldn't be used. 

It sounds like either:
 - gas gives the wrong opcode for "fcom st(4)".  Not likely, as at
   least the gas I use gives the correct D8 D4 sequence.
 - the smlnj port doesn't know how to use assembler, and coded the
   instructions directly in binary, and used the unofficial opcodes.
   Does smlnj do this kind of thing?
 - smlnj just contains some bug and happens to jump to an address that
   countains garbage.  Unlikely, if this happened with different
   versions. 
 - smlnj does something else weird.

Anyway, it could be seen as a misfeature of the math emulator not to
emulate the unofficial codes, so I'll look into it anyway.  But I'd
suggest the smlnj people use the standard opcodes in any case. 

                Linus