packed array size

Frank Heckenbach ih8mj at
Tue Oct 3 19:26:08 CEST 2006

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.

: Variable parameters
: [...] An actual variable parameter shall not denote a component of a
: variable where that variable possesses a type that is designated
: packed. [...]
: 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 Heckenbach, f.heckenbach at,, 7977168E
GPC To-Do list, latest features, fixed bugs:
GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE  D101 CD02 4C9D 0FE0 E5E8

More information about the Gpc mailing list