[M3devel] <*LAZYALIGN*>

[Rodney M. Bates]

The word "Packing" in RTPacking is perhaps misleading.  Using BITSIZE,
etc. only works for getting object layouts as on the machine executing
the code, which is all that is needed when writing a pickle.

When reading, Pickle code needs to know the layouts of a type both as
it is on the reading machine and as it was on the machine that wrote
the pickle.  The type description that the compiler generates is
excerpted and contains no field displacements, just lists of field
types (which are either recursive type descriptions or builtin types).
So it is independent of word sizes, etc.

Pickles regenerates the displacements using the few target machine
characteristics in a RTPacking.T  It traverses a type description and
simultaneously computes two sets of field displacements, both as they
are on the reading machine and on the writing machine.  For the latter,
the value of RTPacking.T is (after a compact bit encoding) stored in the
header of the pickle file.  For the former, it's gotten by techniques like
using BITSIZE.  This is actually all done in RTTipe, part of m3core, and
called by Pickle code.

This is very fragile.  RTTipe has to duplicate the compiler's layout
behavior.  There is no shared code.  Making it common would involve
quite a bit of rework, as the two use substantially different data
structure and code organization.  It will be obvious what kind of bit
damage could occur if the two algorithms didn't agree.

This is why I am obsessing over LAZYALIGN.  I have been comparing the
field displacement computations in RTTipe and in the compiler.  The
former is oblivious to LAZYALIGN.

Note that all this is required even without any packing of small fields
within words.  E.G., a record with two INTEGER fields, pickled on a
32-bit machine and unpickled on a 64.

Tony Hosking wrote:
> Rodney,
> 
> Why does there need to be an entry for LONGINT in RTPacking?  I would  
> have thought all packing is done on word-sized units anyway. Each  side 
> of the connection can check BITSIZE(LONGINT) to figure out what  to do 
> presumably no differently from the way INTEGER is communicated  between 
> 32-bit and 64-bit machines.  Am I missing something?
> 
> -- Tony
> 
> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote:
> 
>> Ah, OK.  I don't much delve in pickle-land.  Anything I can help with?
>>
>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote:
>>
>>> 1) RTPacking.T and needs to have a separate size for LONGINT,
>>>    (which can vary independently of the size of INTEGER).
>>> 2) Variable length values of subrange bounds found in type
>>>    descriptions (in TipeDesc.i3) can now have values beyond
>>>    what the native word size can represent.
>>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently)
>>>    is not handled by Pickles.
>>>
>>> I have done some coding on this, but have been interrupted.
>>>
>>> Tony Hosking wrote:
>>>
>>>> Why is LONGINT for pickles not yet supported?
>>>
>>>
>>> -- 
>>> -------------------------------------------------------------
>>> Rodney M. Bates, retired assistant professor
>>> Dept. of Computer Science, Wichita State University
>>> Wichita, KS 67260-0083
>>> 316-978-3922
>>> rodney.bates at wichita.edu
> 
> 
> 

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu