Re: real.c on unicosmk

[Paul Koning <pkoning at equallogic dot com>]

>>>>> "Stephen" == Stephen L Moshier <steve@moshier.net> writes:

 >> > ..  The PDP-11 floating point format is similar to a VAX but > I
 >> think the byte order is slightly scrambled relative to VAX format.
 >> 
 >> I'd have to check the memory order question.


 Stephen> Here is a list of bit patterns for various computers, as
 Stephen> they would have been written for the contemporaneous
 Stephen> software of the day.

 Stephen> http://www.netlib.org/port/Mach/

 Stephen> If you expressed a floating point value as a big-endian
 Stephen> array of 16-bit integers, both a PDP-11 and a VAX would
 Stephen> interpret the same floating point value.  If you used 32-bit
 Stephen> integers, however, they didn't look the same.  The reason
 Stephen> for that was the high-order 16 bits would come first in
 Stephen> memory on a PDP-11 but last on a VAX.  The PDP-11 definition
 Stephen> was an arbitrary software specification, since there were no
 Stephen> actual hardware 32-bit operations.

I don't understand the point about 32-bit integers, because both GAS
and the PDP11 architecture handbook say that 32 bit ints are stored
low half first.  There are in fact a few hardware 32-bit int
operations: the convert to/from float opcodes.

 Stephen> Here is an example of the bit-scrambling from the above
 Stephen> list, the pattern for single precision log of 10.

 Stephen> PDP-11, O07746420233 (= 0x3f9a209b) = DATA LOG10(1),LOG10(2)
 Stephen> / O037632, O020233 VAX, Z209B3F9A

Ok, that fits all the documentation I have: viewed as a string of
bytes they both translate to the same string, namely 9A 3F 9B 20 hex,
reading from lowest to highest memory address.  If you look at the
components of the float number, it looks very strange as a 32-bit
value on a VAX (with the exponent buried in the middle) but given the
desire to be memory-compatible with the PDP11 it all makes sense.

	paul