[M3devel] <*LAZYALIGN*>

[Rodney M. Bates]

I'll put it in comments in the code.  I am sure I can fix it to
handle LAZYALIGN too,  just not sure whether I can do it without
requiring existing pickle files to be regenerated and/or existing
code that reads/writes pickles to need recompilation.

Anybody on this list who has code that might be affected if pickles
or compiled code were invalidated by a change?

I do propose we change the way of telling the compiler to do
LAZYALIGN so that it is a property of a type and affects all
variables of that type.

Olaf Wagner wrote:
> 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
> 
> 
> 
> 

-- 
-------------------------------------------------------------
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