Frank Heckenbach wrote:
Peter N Lewis wrote:
Basically, we need something like --record-alignment={1,2,4} (and a corresponding compiler directive we can add to the system interfaces) so that items N bytes or larger are aligned to N bytes (where N is 1 2 or 4).
Or would it be sufficient, say, to let `--pack-struct' pack to byte boundaries (more precisely, just like what GCC does), and only real `packed' structures to the bit level?
And add a compiler directive for `pack-struct'.
I will be pleased with the latter solution and it should be sufficient, especially in combination with a maximum-field-alignment directive. Besides, for binary compatibility, you can always add pad bytes.
I'm not exactly sure of the history, but I guess this was done before GPC supported bit-level packing at all (which wasn't implemented until 1997 IIRC). When it was added, maybe noone thought of the option, so I suppose the side-effects on the option's behaviour were never intended.
The Apple version of gcc (front-end or back-end) has the following options: malign-mac68k, -malign-power and -malign-natural.
I don't know what they do (don't seem to be part of official gcc-3.2.1). I hope they just set maximum_field_alignment.
Yes, non-standard gcc.
Also, it would be important to know if the restriction of passing fields of packed records as actual variable parameters could be relaxed to only those cases where the field isn't aligned on byte boundaries (as a non ISO-Pascal feature).
Too fragile -- adding, say a `Boolean' field before the field in question would break `var' parameter usage somewhere else.
OK, not needed with the above changes to --pack-struct.
Besides, some platforms require bigger alignment (many RISC machines). So, say, an Integer that happens to fall on an odd byte boundary would work as a `var' parameter on some machine and not on others.
Which implies that on such a platform --pack-struct will not pack on byte-boundaries but "more precisely, just like what GCC does" ?
Finally, this would be another standard incompatibility of dubious merit (if you want `var' parameters, don't use `packed', period) which is likely to cause problems when porting to other compilers ...
You migth say that it allows compilation of some BP (and maybe other dialect) programs which do use packed fields as `var' parameters (non-standard, since BP ignores `packed' completely). But it wouldn't work in general. A general solution to *this* problem would be a new option `ignore-packed' which is also easy to implement. Then BP compatibility would use `--pack-struct --ignore-packed'. :-)
Sounds logical.
Gale Paeper wrote:
If there is a way to get C pragma's passed through from Pascal source code, Apple's "#pragma options align={mac68k|power|reset}" implementation is in file darwin-c.c located in the gcc/config directory of the GPC Mac OS X build source you are distributing from your GPC web page. In essense, all that is required to get mac68k alignment is to set maximum_field_alignment = 16 and for power alignment set maximum_field_alignment = 0. Apple's pragma code just maintains a save/restore stack and makes the appropriate assignment to maximum_field_alignment. (A batch file search on the sources will reveal maximum_field_alignment is used in stor-layout.c for field alignment for struct/record type layouts.)
If some sort of C pragma pass through isn't possible from Pascal source code, I suggest that the record alignment solution be compatible with Apple's solution which is in turn compatible gcc's general storage layout pragmas. That way we can piggyback off of Apple's efforts in maintaining mac68k and power record alignment working in gcc for Mac OS X.
We don't need the `#pragma' syntax, I think. Implementing an option to set maximum_field_alignment would be easy. `maximum-field-alignment=N' (i.e. `--maximum-field-alignment=N' as a command-line option and `{$maximum-field-alignment N}' as a compiler directive; as usual these would be equivalent).
A maximum-field-alignment option and directive will be very welcome.
Regards,
Adriaan van Os