On Sep 30, 2005, at 12:10 PM, Thiemo Seufer wrote:
> Cyrus Harmon wrote:
>> Dear sbcl-devel,
>> The following patch allows for explicitly setting an :alignment
>> keyword option in sb-alien struct definitions such as the following:
>> (sb-alien:define-alien-type align-test-struct
>> (sb-alien:struct nil
>> (s1 sb-alien:unsigned-char)
>> (c1 sb-alien:unsigned-char :alignment 16)
>> (c2 sb-alien:unsigned-char :alignment 32)
>> (c3 sb-alien:unsigned-char :alignment 32)
>> (c4 sb-alien:unsigned-char :alignment 8)))
>> This may seem like a rather silly thing to do, but certain compilers
>> support a #pragma pack that packs struct fields more tightly together
>> and this can be used to ensure that the sb-alien struct alignment
>> matches the compilers.
> As a sidenote, a plain "#pragma pack" usually means byte-packed to the
> minimal size, which is different to what is wanted here.
Yes, it was not my intent to imply that the example I gave is an
example for use with a #pragma pack'ed function. OTOH, I assume an
alien struct in which all the members were set to :alignment 8 would
be the same as #pragma pack. But my knowledge of #pragma pack isn't
really why I did this, merely a foil to try to motivate
the :alignment mechanism for others who could care less about the 16-
bit MacOS toolbox structs I've been using.
> Sidenote 2, such pragmas break the C ABI guarantees about struct
> layout, they usually shouldn't show up in exported interfaces.
Fair enough. And further, no one in their right mind should make a C
compiler with weird 16-bit alignment for compatibility with emulators
of ancient microprocessors, but that's what I've got.
>> My actual motivation for this, although I
>> would request that you not dismiss this out of hand just because this
>> happens to be the motivating reason, is to make sb-alien struct
>> definitions for various Mac OS toolbox structures that, for 68k
>> compatibility reasons, are compiled with an Apple specific #pragma
>> align=m68k directive that causes things to be 16-bit aligned instead
>> of 32-bit aligned.
> Since compiler writers don't use completely random alignment rules,
> it might be better to have one :maximum-alignment key for the whole
Yes, this might be a better approach for this particular problem.
This route seemed more expedient, but I'm open to suggestions on how
to handle this as you describe.
> (Probably I underestimate the insanity of Apple's compiler guys, the
> struct you are describing usually has no padding whatsoever.)
an eight-bit char followed by a long would be laid out like so:
0 1 2 3 4 5 6
[char] [pad] [32-bit long ... ] ....
I'm sure they had a good reason at the time (no reason for 32-bit
alignment in a 16-bit world?) and later when they needed
compatibility between in-memory data structs between the ppc and the
68k it was either pay the price for trying to translate every struct
on the fly or pay the price for 16-bit alignment on ppc. They chose
the later route and there are still some MacOS toolbox routines that
use these. Fortunately, these are being replaced by modern-ish
interfaces, but it's a long process.
As it stands with this patch, one can access 68k toolbox structs.
Perhaps the maximum-alignment method would be cleaner, but I'm not
quite sure how to go about doing that. Any chance of seeing this
patch go in as is?