[fpc-pascal] Implementation of variant records
freedos.la at gmail.com
Fri Jul 5 18:23:13 CEST 2019
On 7/5/2019 5:07 AM, Marco van de Voort wrote:
> 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.
That's rather odd. I have done a lot of data conversion between
different architectures, always using Pascal, and can't recall where an
explicit "packed" record element was not aligned at a byte level, and
this was IIRC introduced with UCSD Pascal, which was based on a 16bit
p-code machine, regardless of the underlying CPU, so your CDC reference
doesn't directly apply.
And the concept of a "packed record" (as coming from UCSD Pascal) should
be different from the explicit PACK/UNPACK from ISO7165, which can also
be applied arrays and sets, which I think is what you are likely
The only time I had to deal with PACK/UNPACK was on some HP (fka Compaq
fka DEC) Pascal for (Open)VMS, and a packed record would work on a byte
level, unless sets smaller than a byte where used, with the whole record
then padded in memory (but not on storage) to the necessary
Can't find my old Metrowerks CodeWarrior manuals right now, that is the
only time I have worked with a (non-UCSD) Pascal on a PPC (and 68k)
processor to check what how that was defined in there...
This email has been checked for viruses by Avast antivirus software.
More information about the fpc-pascal