>> I seem to recall that the VAX floating point formats, when stored in
>> memory, inherit the PDP-11 byte order, which is neither little
>> endian nor big endian.

Well, I wouldn't say neither; rather, I'd say both.  I think PDP-11
endian for a 32-bit value 0xabcdefgh stored in four 8-bit bytes is 0xcd
0xab 0xgh 0xef - the 32-bit value is split into two 16-bit values,
which are arranged big-endian, but then each 16-bit value is split into
two 8-bit bytes which are arranged little-endian.  (I'm sure someone
will correct me if I've got this wrong.)

Yes, the VAX has inherited this to a certain extent.  If you take an
F-float value (in binary) sign=s exp=eeeeeee
mantissa=mmmmmmmmmmmmmmmmmmmmmmm in memory and load it as a 32-bit
integer, the integer you get will be mmmmmmmmmmmmmmmmseeeeeeeemmmmmmm.
(The VAX did _not_ use the PDP-11 format for 32-bit integers; they are
uniformly little-endian.)

My VARM shows this as

	 1 1
	 5 4             7 6           0
	+-+---------------+-------------+
	|S|      exp      |  fraction   |  :A
	+-+-----------------------------+
	|            fraction           |  :A+2
	+-------------------------------+

which makes it look less weird, temporarily. :-)

> libm don't do any byte assumptions about the floating point format
> (do anyone ever do that???),

Yes.  See, at least, lib/libm/noieee_src/n_cbrt.c and .../n_support.c
for non-IEEE, and lib/libm/src/math_private.h for IEEE.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B