[fpc-pascal] Implementation of variant records
Ralf Quint
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
referring to...
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
alignment/register width.
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...
Ralf
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
More information about the fpc-pascal
mailing list