[M3devel] <LAZYALIGN>

Tue Feb 12 12:34:08 CET 2008

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.
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080212/cc293c1a/attachment-0002.html>