[fpc-pascal] Implementation of variant records

[Ralf Quint]

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