[fpc-pascal] Implementation of variant records

Marco van de Voort fpc at pascalprogramming.org
Fri Jul 5 14:07:46 CEST 2019

Op 2019-07-05 om 13:53 schreef Ralf Quint:
>>> IMO, the variants in a variant record should always overlay 
>>> correctly (like unions in C),
>>> so the variant part should start at offset 32 in this case, and this 
>>> is where all three
>>> variants should start.
>> This is not a guarantee case in the Pascal language, afaik many old 
>> compilers don't even try, but make fields sequential.
>> As soon as you have expections of overlaying, you are dialect and 
>> architecture specific. 
> Shouldn't a PACKED Record guarantee that values are aligned at the 
> byte level?
In Borland and x86 pascals in general that is somewhat the norm.

But the original Pascal architecture was not byte, but word addressable, 
and "packed' there meant packing several fields into one word.  Access 
to packed fields meant loading the word, and shifting the values out.

 From https://en.wikipedia.org/wiki/CDC_6600


The central processor had 60-bit <https://en.wikipedia.org/wiki/60-bit> 
words, while the peripheral processors had 12-bit 
<https://en.wikipedia.org/wiki/12-bit> words. CDC used the term "byte" 
to refer to 12-bit entities used by peripheral processors; characters 
were 6-bit, and central processor instructions were either 15 bits, or 
30 bits with a signed 18-bit address field, the latter allowing for a 
directly addressable memory space of 128K words of central memory 
(converted to modern terms, with 8-bit bytes, this is 0.94 MB).


Strings that were packed had 10 6-bit chars in a word etc. But for some 
array operations, operating on unpacked data (IOW one element per word) 
was easier. There were standard procedures (builtins?) PACK and UNPACK 
to convert between packed and unpacked arrays/records.

Packing was explicit and was meant as a generalized solution to counter 
the memory waste of such schemes (since one 6-bit char/60bits word is 
quite wastful), not to govern the memory layout precisely, that was 
architecture/implementation dependent. The architectures varied to 
wildly for that.

Other, newer, processors were less funky, but sometimes still had 
limitations. I can still remember the initial powerpc port having a 
problem on some (603) processors that couldn't load floating point 
values from unaligned addresses. (lfd/stfd or so)

And of course Alpha (older multias only?) that had exceptions on 
unaligned access iirc.

More information about the fpc-pascal mailing list