[M3devel] <*LAZYALIGN*>

[Darko]

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