On 10 Sep 2006, at 01:24, Waldek Hebisch wrote:
For gpc this is more complicated: gpc generates C-like code which then goes trough gcc optimizers. Normally optimizers assume that memory is accessed only trough pointer of one type (hence one size), so there there is extra work involved to avoid mis- optimization.
That's only if you use -fstrict-aliasing afaik, and is only an issue here if a packed array is typecasted to different packed array types which use a different access size. Besides, users can also typecast it to a regular array (e.g. of integer) with a different access size, so you have to take this into account anyway.
Further, accessing memory with different sizes can happen in a lot of different ways (e.g. someone typecasts one array type to another, one record type into another, or even simply a variant record with two or more overlapping array fields). Did you have to add special code to avoid gcc mis-optimizing all those cases?
Also, using different access size risks processor stalls on write buffers -- I am not sure if we care about such stalls when optimizing for space, but I would prefer to avoid them.
Such stalls only occur if you are accessing the same data using different access sizes, right? I don't think this is an issue, because a) GPC will always use the same access size for a particular kind of packed array, and so will FPC b) when typecasting one kind of packed array to another you may get different access sizes, but then again that will also happen if you typecast it to something else than a packed array (e.g. an array of integer or so).
The issue is not really the access size as explained above, but the (currently consequent) size of the entire packed array (as the subject indicates :) One solution might be to decouple them, although it's of course space-wasting to round up the size of a packed array to a multiple of 4 bytes if you're only going to use byte accesses anyway.
Size and alignment. The following record:
type pr = packed record b : boolean; a : packed array [0..1] of 0..1000000 end;
naively should take 7 bytes, but with word access it will need 12 bytes. And program which interprets record on disk must know alignment to find the data.
I think packed records are a special case: they should always result in minimal alignment (that's the whole point of using packed records). So I would not align that array either, and FPC will also use byte-sized accesses there (not yet implemented) and an alignment of one (already the case currently).
A special case of also having the size rounded up to the next byte is technically a little more difficult (in case it would normally be a multiple of 4 bytes), but doable if considered really necessary.
Jonas