[M3devel] <*LAZYALIGN*>

[Tony Hosking]

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
>