where are unions and bitfields particularly used ?

[August Derleth]

On Fri, 14 May 2004 15:07:39 +0000, Dan Pop wrote:
[snip discussion on unions and bitfields]

Neither definition will work on a VAX, but it is highly unlikely that
anyone will bother porting code developed these days to an architecture
that has been dead for a decade...

Ah, the VAX: A vast improvement on many of its successors.

(IMHO, writing C for a VAX is a waste of a good ISA anyway. )

 

[Dave Thompson]

In <[email protected]> (e-mail address removed) (Guruz) writes:

eg: A IP address [as] a union [of 4 :8 bitfields or one int]

OTOH, since this approach is quite convenient in practice, all you need
in order to use it on *most* implementations is an alternate definition
of union ip (one in which the order of definition of f1, f2, f3, f4 is
reversed) and an externally defined macro that indicates which definition
must be actually used on that particular implementation. Neither
definition will work on a VAX, but it is highly unlikely that anyone will
bother porting code developed these days to an architecture that has been
dead for a decade...

AIR VAX longword (integer) was (pure) little-endian. It was its
floating-point, and I think only some of the several formats, that
followed PDP-11 mixed-endian bogosity, which -11 also did to long.

- David.Thompson1 at worldnet.att.net

 

[Dan Pop]

In <[email protected]> (e-mail address removed) (Guruz) writes:

eg: A IP address [as] a union [of 4 :8 bitfields or one int]

OTOH, since this approach is quite convenient in practice, all you need
in order to use it on *most* implementations is an alternate definition
of union ip (one in which the order of definition of f1, f2, f3, f4 is
reversed) and an externally defined macro that indicates which definition
must be actually used on that particular implementation. Neither
definition will work on a VAX, but it is highly unlikely that anyone will
bother porting code developed these days to an architecture that has been
dead for a decade...

AIR VAX longword (integer) was (pure) little-endian. It was its
floating-point, and I think only some of the several formats, that
followed PDP-11 mixed-endian bogosity, which -11 also did to long.

A while ago, when I expressed a similar opinion, P.J. Plauger claimed
that both PDP-11 and the VAX were mixed endian. It made sense, if the
two platforms were supposed to be able to exchange binary data files...

There is no way to define the endianness of floating point types, because
it's far from obvious which is the little end and which is the big one.

Dan

 

[Dave Thompson]

On 14 May 2004 15:07:39 GMT, (e-mail address removed) (Dan Pop) wrote:

[ union 4-byte integer to bytes ] is quite convenient in practice, all you need
in order to use it on *most* implementations is [choice of LE or BE]. Neither
definition will work on a VAX, but [...] that has been
dead for a decade...

AIR VAX longword (integer) was (pure) little-endian. It was its
floating-point, and I think only some of the several formats, that
followed PDP-11 mixed-endian bogosity, which -11 also did to long.

A while ago, when I expressed a similar opinion, P.J. Plauger claimed
that both PDP-11 and the VAX were mixed endian. It made sense, if the
two platforms were supposed to be able to exchange binary data files...

VAX native longs (at machine level and to system calls) were
definitely little-endian -- remember the box drawings aligned on the
right and with (cell) addresses increasing upwards? And you could do
the trick or more likely mistake of passing by reference (e.g.
FORTRAN) a short to a long or vice versa and have it work (only!) for
smallish values. I think there were some programs, and perhaps library
options, that handled (integer) data -- especially, as you say, in
files -- in PDP-11 format, but I didn't use them.

There is no way to define the endianness of floating point types, because
it's far from obvious which is the little end and which is the big one.

The "natural" way, on most machines, was usually to have biased
exponent above "mantissa" (really significand), because before NaNs
(and for normalized values) you could do the same bitwise comparision
(i.e. the same hardware) as for (unsigned) integer and get the correct
result. (And with sign at the top, the same bitwise comparison as S&M
integer, which I think is only a couple of gates different from 2sC.)
And that is in fact how FP11 and (some?) VAX formats are laid out
after you put the bytes in "canonical" order.

- David.Thompson1 at worldnet.att.net