[M3devel] <*LAZYALIGN*>

[Darko]

We seem to be going through these same point several times. I'm not sure
what the difficulty is, I'm just repeating myself.

Keep in mind this applies *only* to packed structures, ie BIT FOR or bit
fields.

The change I put in libralised the *M3* alignment rules so that BITS FOR
fields in structures would align on byte boundries if possible instead of
restricting them to word alignment generally. GCC happily generates code
for this. There may be restrictions in GCC's C as to how you can arrange
bit fields but I don't see what they have to do with M3.

This is absolutely essentail for using the native APIs on Mac OS X and its
removal would make M3 pointless for use on the Mac, at least more me.

This should be the default behviour. If you are using BITS FOR it's
becuase you want to arrange the fields in a record in particular way. Why
then arbitrarliy pad out the fields? If performance is an issue, the user
should be using appropriate field bit sizes. The implementation rule for
BITS FOR in M3 is implementation dependent, there are no language issues.

The LAZYALIGN pragma (that is, the prgama itself) is something Olaf
created and had nothing to do with me. I diagreed with it and never used
it in the version of the compiler I ran. I support its removal.



> On Feb 18, 2008, at 3:01 PM, Darko wrote:
>
>> 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?
>
> What do you mean make LAZYALIGN standard?  Why wouldn't we go with
> the standard gcc-backend alignment?  Perhaps I don't understand what
> it is you are doing or trying to do.  Again, please remind me what it
> is that LAZYALIGN does and why it is needed.
>
>> 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
>>>>
>>>
>
>