CBFalconer wrote:
Adriaan van Os wrote:
Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/
- New option `--maximum-field-alignment=N'
Also as a compiler directive $maximum-field-alignment=N.
It works great, for example the following data structure
type word8 = cardinal( 8); word16 = cardinal( 16); word32 = cardinal( 32); rec = record a, b, c: word8; d: word16; e: word32 end;
returns different sizes (in bytes) for different aligments (in bits):
N=0 size=12 N=32 size=12 N=16 size=10 N=8 size=9
Huh? By my reckoning everything is fouled. N=32 should yield 20, n=16 --> 12, n=8 seems ok.
I haven't looked into the actual implementation, but if the directive just ties into the back-end's stor-layout.c maximum_field_alignment useage (as discussed a while back in the pack struct thread), then the size and field offsets obtained with $maximum-field-alignment=N depends upon the target configuration settings.
If I'm not mistaken, the some of the target dependencies are:
1. Natural integer size (e.g., 16, 32, 64, etc. bits)
2. Memory packing policies for various types and type sizes (e.g., are sub-integer size types packed into natural integer size memory chunks?)
3. Where does the next memory field start in natural integer size bit offset terms. (I believe this has to be within the bit range of the natural integer size. If it is outside the range it reverts to bit 0.)
The above three items are factored in when determining the actual memory offset used for each field. (Note: Floating point fields have additional considerations.)
For the PPC, Darwin, Mach-o target (i.e., gpc/gcc for Mac OS X) the natural integer size is 32 bits, sub-integer types are packed into natural integer sized memory chucks if the type doesn't spill across a natural integer size boundary, and by default the next memory non-packed field start is bit 0 ( in left to right ascending bit numbering scheme).
Using $maximum-field-alignment to change the default for item 3 (as I think it probably does) for the values of N listed should yield the record sizes Adriaan has reported for Mac OS X GPC.
For N=0 or 32 (which actually gets reverted to 0), the first three (8 bit) fields are packed into the first 32 bit memory chunk with 8 bits of padding since the next field is too large for the remaining bits and next field start setting is bit 0, the forth (16 bit) field is in the second 32 bit memory chunk with 16 bits of padding (next field too large etc.), and the last, remaining (32 bit) field is in the third and last 32 bit menory chunk.
For N=16, the too-large-fit next field starting bit offsets are 0 or 16 bits thus the 16 bit pad is eliminated. For N=8, the offsets are 0, 8, 16, and 24 bits thus both the 8 bit and 16 bit pads are eliminated.
Hopefully the above will help clarify the intend useage of the $maximum-field-alignment directive. It isn't used to specify the minimum size for each specific field in a record; rather, it is more of a padding and inter-machine-word field splitting control for combinations of multiple, varying sized fields.
Gale Paeper gpaeper@empirenet.com