[M3devel] <*LAZYALIGN*>

[Rodney M. Bates]

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