[M3devel] <*LAZYALIGN*>

[Olaf Wagner]

Perhaps we should check-in this description somewhere near the
actual code? Or is there enough documentation already?

Olaf

PS: Based on your description, I'd say we should abandon LAZYALIGN.
     Or at least put a big sticker on that it will break pickles.

Quoting "Rodney M. Bates" <rodney.bates at wichita.edu>:

> 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



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194