where are unions and bitfields particularly used ?

A

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. ;) )
 
D

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
 
D

Dan Pop

In said:
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
 
D

Dave Thompson

In said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

enum as bitfields 11
Arrays of Unions 21
unions within an array 10
Alternative approach to bitfields 9
Bitmask vs bitfields 6
properly using unions. 9
Real Life Unions 67
Extending unions and ABI? 12

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top