[M3devel] <*LAZYALIGN*>

[Tony Hosking]

Jay,

Modula-3 has a perfectly good way of saying what you want as PACKED  
types.  Whether they are fully implemented or not is another question.

-- Tony

On Feb 12, 2008, at 6:34 AM, Jay wrote:

> I strongly suggest that at least in some contexts, no padding ever  
> be quietly inserted, and that all seeming need for padding generate  
> an error, unless explicitly quashed, preferably by explicit  
> insertion of padding fields by the programmer, and/or rearrangement  
> sorted by size, or possibly some annotation of the overall struct/ 
> record/class/module, an annotation such as <* silent padding ok*>.
> Alignment issues really bug me...
> I realize many data structures are only ever seen in memory, by one  
> process, so it doesn't matter, but when it matter, the languages/ 
> tools seem to fall down.
> As well, "padding" fields should be annotated as such and the  
> compiler warn or error if they aren't needed.
>
> It's just dumb that code like:
>
> struct
> {
>    int32 a;
>    int64 b;
> };
>
> when defining some stable important binary layout can have a  
> varying but silently allowed meaning based on command line switches  
> or targets.. Yes, I'm a dumb programmer to write it, but man the  
> tools are lagging.
>
> This will fall on deaf ears and far from sufficient ears even if  
> they were hearing.
> It's the C compilers that are somewhat broken here imho.
> C is unnecessarily broken here. Imho it's a big cause for headaches  
> and easily solved....it doesn't have to stink so badly, if anyone  
> cared..
>
> I have had to maintain structs that had to look the same across  
> different targets and therefore insert target-dependent padding.  
> Ok, but it should have been easier. When I was done, I put in  
> compile time asserts as to the offset of every single field so the  
> next guy would have an easier time, and assiduously commented every  
> byte of padding in the struct and its target-dependentness....
> This was like for shared memory.
>
> Grumble,
>  - Jay
>
>
>
> > From: darko at darko.org
> > To: rodney.bates at wichita.edu
> > Date: Tue, 12 Feb 2008 15:37:52 +1100
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] <*LAZYALIGN*>
> >
> > 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
> >
>
>
> Connect and share in new ways with Windows Live. Get it now!