[M3devel] <*LAZYALIGN*>

[Rodney M. Bates]

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