[M3devel] <*LAZYALIGN*>

[Darko]

It's been several years since I looked at the code, so my recollection  
is obviously faulty. But this means that the actual change is a  
positive one, allowing more packings to be legal, and there is no need  
for any pragmas.

So the new alignment rules would be that for any platform that allows  
it, allow fields to align on byte boundaries, except traced references  
that must be aligned on word boundaries.

This would mean that a pickle packed on a platform with the more  
liberal alignment might be illegal on another platform. Therefore  
caution should be taken, otherwise I see no problem with this.


On 23/02/2008, at 8:49 AM, Rodney M. Bates wrote:

> No, this is exactly what the language says and means.  However,  
> there is
> more, in the same section that I took for granted:
>
> "The values allowed for n are implementation-dependent.  An illegal  
> value for n is a
> static error.  The legality of a packed type can depend on its  
> context; for example, an
> implementation could prohibit packed integers from spanning word  
> boundaries."
>
> In other words, the compiler must either locate a packed field with  
> no preceding
> padding, or else emit an error, and this is what both PM3 and CM3  
> do.  LAZYALIGN
> weakens the CM3's restrictions and changes the handling of your  
> example from a
> a compile error to respecting the no-padding rule.  Either way is  
> consistent with
> the language.
>
> Darko wrote:
>> I think you may be reading that definition too literally. Any   
>> processor is going to data alignment rules so 'adjacent' is subject  
>> to  what can be implemented on the processor. The problem I have is  
>> that  the existing code doesn't pack to the limits of the  
>> processor, but to  some arbitrary alignment. Thus my comment about  
>> viewing so-called lazy  alignment as a fix to an alignment bug.
>> On 23/02/2008, at 2:35 AM, Rodney M. Bates wrote:
>>>
>>>
>>> Darko wrote:
>>>
>>>> There wouldn't be any explicit expression. in the source, but   
>>>> there  would be a flag in Target.i3 for turning it off and on  
>>>> for  different  platforms.
>>>> Although the details may be a bit off, the principal is this:
>>>> before byte alignment change:
>>>> RECORD
>>>> a: BITS 8 FOR 0..255; (* takes 32 bits *)
>>>> b: BITS 32 FOR INTEGER; (* takes 32 bits *)
>>>
>>>
>>> ^If the compiler's alignment rules are not lazy, then this violates
>>> a language rule and should not compile.  From 2.2.5, Packed types:
>>>
>>> "...variables of type T that occur in records, objects, or arrays  
>>> will
>>> occupy exactly n bits and be packed adjacent to the preceding  
>>> field or
>>> element."
>>>
>>> To get the padding between a and b, you would have to either put  
>>> it in
>>> with an explicit pad field, or remove the BITS 32 from the type of  
>>> b.
>>>
>
> -- 
> -------------------------------------------------------------
> 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