Frank Heckenbach wrote:
Peter N Lewis wrote:
At 22:03 -0700 12/5/03, Gale Paeper wrote:
The question is whether a maximum-field-alignment (command line or compiler) option should have any effect on packed types. I didn't think about that case before, but my answer to that question is "no".
Var R: packed record a: Boolean; b: 1..3; end;
Use of "packed" could imply a local maximum-field-alignment=8 (or 0) for the type, so that always SizeOf( R) = 1.
Any other opinions ?
I don't use maximum-field-alignment myself, so I don't care much either way. BP compatibility should be of no concern either if they use `--ignore-packed' anyway.
So if there's consensus, I think I can change it.
Before you change it, I think some more investigation is needed to see what effect it will have on the packed types layouts found in Apple's Pascal Universal Interfaces.
In essense, maximum-field-alignment was a solution hack to get the correct type layout alignments needed for interfacing with Mac OS X when using a GPC compatible translation of Apple's Pascal Interfaces. Since the hack seems to be working for Mac OS X, I wouldn't like to see it break as a result of a change "fixing" something unrelated to Mac OS X interfacing.
The change sounds fine to me. Traditional Mac Pascals treat packed fairly well and will align most things on byte boundaries (or less for booleans). I suspect most of the packed records in the interfaces are there only because Byte (Cardinal(8)) is normally two bytes long (don't ask), and so the use of a sensible UInt8 probably resolves the problems anyway.
The combination of maximum-field-alignment and packed records should allow us to easily ensure records are correctly aligned, so I'd say go ahead with the changes as described - packed should override maximum-field-alignment.
Does everyone agree to it?
In some testing on the effect of maximum-field-alignment on Mac interfaces packed types, I've found a few packed types whose size changes between $maximum-field-alignment=16 and the built-in PPC compiler default. However, I also found that for some of those changing size types, the $maximum-field-alignment=16 type size doesn't match up with MAC68K alignment size obtained with CodeWarrior Pascal and THINK Pascal. When taken together, I think this indicates the root cause of the changing type sizes in those cases is due to a fundamental difference in the GPC/gcc type layout algorithm which isn't directly controllable with the maximum-field-alignment setting.
Since it is just a couple of packed types in the Mac interfaces and the size differences may not turn out to be of any importance upon more detailed investigation, I think the best way to work the changing size problem on those Mac interface types is through tweaking the few affected type declarations in the interfaces if it turns out necessary to do so. (I think the problem is with record alignment rather than field alignment which can be fixed with explict pad field declarations where MAC68K alignment implictly pads to achieve record alignment requirements.)
(maximum-field-alignment was implemented mostly because of the Mac interfaces, so if the change won't break anything there, this is probably the most important thing.)
For the vast majority of the packed types in the Mac interfaces, further investigation shows Peter's assessment of the effect of maximum-field-alignment on packed data types was correct. Therefore, I no longer have any reservations about the change.
P.S. Since I don't think it would be of interest to the wider GPC audience, I didn't get into the details of the differences. Once I complete a few more investigations, I'll following up with the folks working on the Mac interfaces (e.g., Peter and Adriaan) on the nature of the problem and what interface changes, if any, are needed for correct interfacing functionality.
Gale Paeper gpaeper@empirenet.com