Peter N Lewis wrote:
For these two reasons I have an urgent feature request, which is to make --pack-struct available as a compiler option that can be added to the Pascal source code.
Unfortunately, it looks like this will not help :-(
--pack-struct appears to do exactly the same thing as "packed record", which is too strong because of the added restriction of failing with var parameters.
True.
What is needed is a relaxation of the alignment restrictions when building a record, without the onerous restriction of bitfield packing. Presumably this would help with Borland compatibility as well.
I think so. -- Actually, also for standard compliance; currently GPC with `--pack-struct' violates the standard.
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'.
If this sounds reasonable, and if folks have advice on the exact user interface for this, then I'm willing to take a crack at this in the source to "get my feet wet".
Thanks for the offer, but I think in this case it's not necessary. I know the affected parts of the code, and the changes will probably be rather small, so I can do them quickly when I'm sure what they should look like.
Specific advice would include the exact name "record-alignment", whether it should take a parameter, or instead be --no-record-alignment, --record-alignment1, --record-alignment2, --record-alignment4. The latter would seem more in keeping with the options in general, as I could not find any other compiler directive that took a parameter, but correct me if I'm wrong.
There are some: field-widths, enable-keyword, disable-keyword, setlimit, gpc-main, init-modules, define, include, ...
Adriaan van Os wrote:
--pack-struct is a gcc option, not a gpc option, so I wonder if packing is a front-end or a back-end issue. I hope Frank knows.
Packing record fields is a backend issue, but the frontend must set some flags in the "tree nodes" to indicate what it wants (both byte and bit packing are available there, separately). Packed arrays are completely handled in the frontend because the backend doesn't support them (yet). :-(
`--pack-struct' is a "backend" option, but it only sets a global flag (flag_pack_struct) and leaves it up to the frontend to use it.
In GPC currently `packed' in a type definition just turns on this flag temporarily, and if this flag is set (either way), it marks types for packing both ways.
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.
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.
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.
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'. :-)
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).
Frank