Re: m68k structure packing

[Kamil Iskra <kamil at dwd dot interkom dot pl>]

On Tue, 30 Sep 1997, Jim Wilson wrote:

> However, there remains a specific question here as to how this affects the
> m68k port with respect to the known and documented problems with
> PCC_BITFIELD_TYPE_MATTERS and STRUCTURE_SIZE_BOUNDARY.  It is not obvious
> what the interaction is.  But as I mentioned in my previous mail, I am starting
> to suspect that improvements to the unaligned/packed structure field support
> over the years has accidentally solved this known problem, in which case this
> may now be a `historical' problem.

This is also my assumption, based on the testing that I've done (more on
this later).

> If you haven't done so already, and if
> you really care about this problem, take a look at the
> PCC_BITFIELD_TYPE_MATTERS documentation.

I've read it at least dozen times, I could probably quote some parts from
memory :-).

I also asked these sort of questions quite a long time ago on gcc2, but no
one was able, or cared, to help. I'm happy that this issue was finally
given the attention it (IMHO) deserves :-).

Fo the m68k-amigaos port, I undefined STRUCTURE_SIZE_BOUNDARY, without
defining PCC_BITFIELD_TYPE_MATTERS. According to tm.texi and expmed.c
(store_fixed_bit_field), this is not supposed to work. Here's one comment
from the latter file:

  /* There is a case not handled here:
     a structure with a known alignment of just a halfword
     and a field split across two aligned halfwords within the structure.
     Or likewise a structure with a known alignment of just a byte
     and a field split across two bytes.
     Such cases are not supposed to be able to occur.  */

I made plenty of testing, varying from trivial cases to really
pathological ones, like operations on 64-bit bitfields in a structure
where the compiler could only assume 8-bit alignment. They compiled and
run fine, and I couldn't find a flaw by looking at the assembler output.
The compiler would simply use 1-byte loads and stores, shifts, ands and
ors. It was quite impressive, actually :-). These were clearly the cases
that, according to the comment above, were not supposed to work. Yet they
did.

We've also done a lot of "real life" tests, by simply using such a
compiler to rebuild complete source tree of GeekGadgets, a project
consisting of hundreds of megabytes of well-known free sources. We haven't
observed any decrease in the stability of the binary tree. Of course, most
of us don't use 68000 any more, but still some people do and they haven't
reported any problems after the switch to unaligned structures took place.

Actually, this problem would be hard to observe in the real life. That's
because most structures have "int" or pointer fields, thus imposing the
2-byte boundary. Only structures consisting of chars or bitfields only are
laid out differently, and such structures are rare. I analysed every
single standard header file looking for such structures, and I found just
one, if I remember correctly. Still, it contained an even number of chars
and no bitfields, so it made no difference :-). In order to ensure the
binary compatibility with the older software, I also compiled IXEmul, our
UNIX emulation software (something similar in principles to cygnus.dll in
cygwin32, I guess), with both "aligning" and "not aligning" compilers, and
byte-compared the resulting object files.  Again, of the several hundreds
of them, only one was different, because the not aligning compiler had to
be more pessimistic when accessing a bitfield of a structure passed to the
function by pointer. Still, the produced code was correct and backwards
compatible.

/ Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 1.6 GB, 18 MB RAM \
| iskra@student.uci.agh.edu.pl  kiskra@ernie.icslab.agh.edu.pl |
| http://student.uci.agh.edu.pl/~iskra                         |
\ PGP public key available via Finger or WWW                   /