[M3devel] <*LAZYALIGN*>

[Darko]

The alignment behaviour is absolutely crucial to programming natively  
in Mac OS X and should be kept. I have a great need for it.

The PRGAMA is of no use and can be removed.

Does anyone have any objections to making this alignment behaviour  
standard?


On 19/02/2008, at 4:36 AM, Tony Hosking wrote:

> Can someone remind me again why we need LAZYALIGN?  I concur with  
> Randy that if it is rarely used and moreso breaks things I would  
> argue to abandon it.
>
> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote:
>
>> I use pickles extensively and they are used also by network objects.
>> I've never used LAZYALIGN.
>> My vote is that we don't break something (pickles/netobj) to add  
>> support for something that is rarely used.
>> Regards,
>> Randy
>>
>> >>> "Rodney M. Bates" <rodney.bates at wichita.edu> 2/15/2008 5:06 PM  
>> >>>
>> 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
>>
>