Waldek Hebisch wrote:
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).
The latter is explicitly forbidden in ISO Pascal. The fact that some compilers (including GPC, ATM) don't check for such errors may be considered a bug (or omission) rather than a feature ...
IME, almost all cases of such type-casting are either to or from an unstructured block of memory (untyped pointer, array of Byte, etc.). AFAIK, C's aliasing rules explicitly allow for such cases (i.e., casting to "[unsigned] char *" in C terms).
But AFAIK aliasing optimizations have significant effect (10-20% on SPEC), so I want to turn them on. Yes, I will need special code to avoid mis-optimizing casts (or declare them illegal, like C folks did).
I also think such optimizations can be worth adding some special code. Perhaps we could make an option to turn strict aliasing on (probably with a special case for "unstructured" memory, as above, which the backend may already do automatically, because of C), so programmers could use it and care about their special cases (if any) explicitly. Of course, we'd have to check the RTS etc. for such special cases (which are more likely to be there than in average code), so we probably can't just turn it on now.
Well, the current scheme [half-word acccess] was introduced many years ago. I do not say that the goals were attained. I am just trying to reconstruct the rationale.
It was even before I started working on GPC, so that's also just AFAIK, but I think it was intended just as a temporary Q&D solution (obviously not taking into account element sizes) until the backend would support packed arrays like it does packed records. This hasn't happened (and it seems it never will, or do you have other information, Waldek?), so we still have the Q&D way.
Yes. However when packing 63 bit elements on 32 bit machine (or 127 bit elements on 64 bit machine) using two acceses causes trouble -- gpc implementation would need quadruple precision shifts.
I think it could also be done with rotations, but it would probably require a bit of code ...
I do not know if I really want to bit-pack subranges bigger then word size. But currently gpc packs them (the results are bogus...).
Depending on the implementation ultimately chosen, it might not be worth it, indeed. Though we could pack some "harmless" types (I remember someone once requiring about 24 bit packed types, for reasons of range vs. memory, and these types currently work), and we should probably warn about types we don't pack despite an explicit "packed" ...
Jonas Maebe wrote:
On 10 Sep 2006, at 13:11, CBFalconer wrote:
I don't understand why there is a problem. Packed array components are not directly accessible in any case, they have to be processed through the standard procedures pack and unpack anyhow.
Packed array components are directly accessible by indexing the packed array like a regular array (at least in both GPC and FPC). And I think it's even required for ISO Pascal since otherwise you would not be able to access the individual characters of a string by indexing strings, as I understand it (since their contents consists of a packed array of char).
That's right. ISO defines Pack and Unpack, but it's a misconception that packed arrays can be accessed only through these routines. There are a few restrictions, such as quoted below, but direct access in general is not forbidden.
: 6.7.3.3 Variable parameters : : [...] An actual variable parameter shall not denote a component of a : variable where that variable possesses a type that is designated : packed. [...] : : 6.7.3.7.3 Variable conformant arrays : : [...] An actualĂ‚Âparameter shall not denote a component of a variable : where that variable possesses a type that is designated packed.
Frank