🚀 go-pugleaf

In <17906@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes:
>In <328@ctycal.UUCP>, ingoldsb@ctycal.UUCP (Terry Ingoldsby) writes:
>> This discussion, IMHO, is pointless.  The C compilers work just fine the way
>> are (or at least the ones I am familiar with).  I don't think some of the
>> people discussing this realize the implications of what they propose.
>Wrong.  It depends on what you do.  [specifics deleted..]
>  I have to do things like reach out over the network, and read
>data structures out of the remote controllers.  These structures for the
>most part, are a mix of byte and word fields.  I then have to parse through
>them, and isolate the parts.  Structures are the obvious way to do this.
>BUT, the @#$% compiler choses to pad byte or char values out to ints.

I also have the same problem.  Having the compiler pad to the "native" data
size is OK if (and ONLY if) you have complete control over that data structure
and do not need to share it with other programs/systems.  However, in data
communications protocols (pick one), the programmer has NO control over the
data structure -- it is predefined, and doesn't come with that nice padding
that the compiler likes to put in.  Some recent RISC compilers (I'm looking
at the 29K) allow you to specify whether structures are "packed" or not, 
which I think is mandatory.  Unfortunately, in the case of the 29K compiler,
although it will "pack" structures, as far as I know it will NOT generate
the appropriate instructions to access those structures if the external
memory subsystem does NOT support non-aligned accesses. Oh, well....

M. A. Pasek               Software Development              NCR Comten, Inc.
(612) 638-7668              MNI Development               2700 N. Snelling Ave.
pasek@c10sd3.StPaul.NCR.COM                               Roseville, MN  55113