[M3devel] <*LAZYALIGN*>

[Rodney M. Bates]

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