[M3devel] <*LAZYALIGN*>

[Darko]

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