[M3devel] <*LAZYALIGN*>

[Tony Hosking]

Why is LONGINT for pickles not yet supported?

On Feb 14, 2008, at 5:56 PM, Rodney M. Bates wrote:

> OK.  So would my proposal 1) below suffice, that the alignment  
> rules are a
> property of a type and thus the same for every variable of that type?
>
> More immediately relevant, is it true that nothing that uses  
> LAZYALIGN rules
> is ever pickled?  I believe current pickles will trash things badly  
> if that
> happens.  Fixing this without invalidating existing pickles and/or  
> compiled
> code looks tricky.
>
> If nothing LAZYALIGN is pickled, I am hoping to be able to come up  
> with
> a scheme that will fix pickles, not require rewriting of any  
> already existing
> pickle files or recompilation of existing object code, and yet not  
> introduce
> any new bugs involving old pickles/code.
>
> Maybe I should just postpone this one until after LONGINT in  
> pickles is supported
> (only with STRICTALIGN, as now for other types.)
>
> Darko wrote:
>> That's not quite right. Certain Mac API structures need to be  
>> aligned  to Motorola 68K alignment for historical reasons. All  
>> other structures  should use normal alignment to be compatible  
>> with C and Unix  interfaces. The alignment change was implemented  
>> to be supported only  in packed structures as a natural and  
>> intuitive way to "force"  alignment. You could view it as a bug  
>> fix to overly restrictive  alignment rules in packed structures.
>> On 12/02/2008, at 2:46 PM, Rodney M. Bates wrote:
>>> It sounds like all that Mac OS X needs is for _all_ types in an  
>>> entire
>>> program to use the liberal packing rules.  Have I understood   
>>> correctly?
>>> I would have no grief over that.
>>>
>>> Darko wrote:
>>>
>>>> The liberalised alignment rules are required for the native Mac  
>>>> OS  X  API and should stay. You cannot use that API without  
>>>> them. I  think the  pragma is not required and can be removed. I  
>>>> agree with  all the points  you make. The effect of the modified  
>>>> alignment  rules it to allow  *packed* structures to have  
>>>> members aligned on  byte boundaries. This  has the effect of  
>>>> packing the fields in the  tightest arrangement  allowed by the  
>>>> platform. This might affect  performance, but if the  user is  
>>>> concerned about this they should  specify field bit sizes that   
>>>> deliver improved performance. I don't  see a need to specify  
>>>> this on a  structure level, for the reasons  you give and  
>>>> because the difference  isn't significant enough in  the case of  
>>>> packed structures and their  physical layout and  restrictions  
>>>> are platform dependent anyway.
>>>> I might also add that the alignment code is currently broken  
>>>> on   I386_DARWIN.
>>>> - Darko
>>>> On 11/02/2008, at 8:55 AM, Rodney M. Bates wrote:
>>>>
>>>>> Does anybody know about the status of pragma <*LAZYALIGN*>?  Is it
>>>>> being used anywhere?
>>>>>
>>>>> It is not documented in pragmas.html.  The compiler front end   
>>>>> appears
>>>>> to accept it.  (In fact, Decls.m3 contains constants that suggest
>>>>> limitations on what declarations the pragma can appear on, but  
>>>>> these
>>>>> are not actually enforced.)  It liberalizes the alignment rules,
>>>>> generally allowing scalars to start on any byte boundary.
>>>>>
>>>>> Pickles have to be able to reconstruct the layout of types as the
>>>>> compiler would have done it for a machine (on which a now-being- 
>>>>> read
>>>>> pickle was written) with different word size and alignment   
>>>>> properties.
>>>>> Currently, pickles are completely unaware of lazy alignment.  It
>>>>> would have to be encoded in type descriptions generated by  
>>>>> the   compiler
>>>>> using TipeDesc and read by pickles using RTTipe.
>>>>>
>>>>> Most troubling to me is what looks like a linguistic Pandora's  
>>>>> box.
>>>>> The pragma can be associated with any constant, variable, or type
>>>>> _declaration_ (not type definition), with the result that  
>>>>> different
>>>>> values of the same type can actually be different in their  
>>>>> alignment
>>>>> rules and thus their layout.  Similarly for different identifiers
>>>>> equated to the same type.  Although the effects of this could   
>>>>> possibly
>>>>> be hidden from the programmer in purely safe code, not so with   
>>>>> unsafe
>>>>> code.  I haven't thoroughly thought this through,  but seems to  
>>>>> me  to
>>>>> really fly in the face of the whole typing philosophy of the   
>>>>> language.
>>>>>
>>>>> For example, if pickles were to read in an object value, and there
>>>>> were >1 variants of the object's type in the reading program,    
>>>>> differing
>>>>> only in the alignment rules, how would it decide which one to  
>>>>> build?
>>>>> In fact, ignoring pickles altogether and just looking at a  
>>>>> single   program,
>>>>> if the object's type doesn't actually uniquely give its memory   
>>>>> layout,
>>>>> how can it be accessed correctly?
>>>>>
>>>>> Additionally, a quick look at the compiler suggests it won't   
>>>>> generate
>>>>> correct code for whole record assignment when the LHS and RHS  
>>>>> are  the
>>>>> same type but have different alignment characteristics.
>>>>>
>>>>> The more I think about it, it seems the only workable   
>>>>> possibilities  are:
>>>>>
>>>>> 1) Require the pragma to be associated only with a type   
>>>>> _definition_  not a
>>>>>  declaration (e.g., allow RECORD <*LAZYALIGN*> ... END) and  
>>>>> make   this a
>>>>>  property of the type that propagates to all names for the type  
>>>>> and
>>>>>  all variables, constants, etc.  Also, this would make this  
>>>>> property
>>>>>  a part of the type signature that pickles uses when reading, -OR-
>>>>>
>>>>> 2) Forget it altogether.
>>>>>
>>>>> What do people think?
>>>>> -- 
>>>>> -------------------------------------------------------------
>>>>> 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