[M3devel] <*LAZYALIGN*>

Darko darko at darko.org
Tue Feb 12 05:37:52 CET 2008


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




More information about the M3devel mailing list