From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kamil Iskra To: Jim Wilson Cc: egcs@cygnus.com Subject: Re: m68k structure packing Date: Wed, 01 Oct 1997 05:44:00 -0000 Message-id: References: <199710010442.VAA02338@cygnus.com> X-SW-Source: 1997-10/msg00009.html 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 /