gm2
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gm2] Control of memory alignment


From: gaius
Subject: Re: [Gm2] Control of memory alignment
Date: Sat, 24 Dec 2011 13:20:30 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Benjamin Kowarsch <address@hidden> writes:

> Hi
>
> I saw this recent post by Dragisa Duric on memory alignment:
>
>> IMO - we also need a mechanism to fix a sequence of fields to word boundary. 
>> Obviousy, a field without "BY" will fit to its default alignment position, 
>> but what if we have
>> 
>> type = RECORD
>> foo: INTEGER BY 2;
>> bar: CARDINAL BY 4;
>> butalso: CARDINAL BY 2; (* and we need to have this aligned to some 
>> boundary… *)
>> END;
>> 
>> Alignment can be pretty complicated these days when on same architecture 
>> some people decide to align 64 bit values to  byte positions divisible by 8… 
>> And other do not. I met such a situation while wrapping Gtk2 to Modula-3… 
>> gcc aligns such values to divisible-by-4 byte positions, while cm3 aligns to 
>> divisible-by-8…
>
>
> I would like to chime in on that with a general suggestion.
>
> It is good style to differentiate between what is language and what is 
> compilation control. The litmus test is to the question: "Does this change 
> the meaning of the program or does it merely influence the compilation 
> process itself but leave the meaning of the program as it is?"
>
> Features that determine the meaning of a program are part of the language 
> while features that merely influence the compilation process are compiler 
> directives or pragmas.
>
> Initially, pragmas appeared in Modula-2 in form of special comments, later, 
> in ISO M2 they got their own delimiters. In either case it is obvious that 
> there was always a clear intent to separate pragmas from ordinary syntax. For 
> good reason. Separating the two makes the code more readable and 
> maintainable. I would like to promote this principle here.
>
> In Modula-2 R10 we have followed this principle very strictly and in order to 
> make sure that certain important pragmas are portable, we defined a number of 
> language defined pragmas, one of which is an alignment pragma:
>
> alignPragma :
> "<*" ALIGN "=" inPragmaExpression "*> ;
>
> An in-pragma expression is a compile time expression that may contain 
> constants defined in the source and invoke certain pervasive functions such 
> as TSIZE for example.
>
> Using this approach it is then possible to control the alignment of data via 
> pragmas without losing the ability to use compile time expressions to 
> determine the alignment parameter. For example:
>
> x : CARDINAL <* ALIGN = TSIZE(CARDINAL) * 4 *> ;
>
> I'd like to suggest that GM2 should also follow an approach by which such 
> features that do not alter the meaning of a program are implemented as 
> pragmas.
>


Hi Benjamin,

ok this sounds sensible, how about:

TYPE
   rec =3D RECORD
            <* alignment: MOD 1 *>    (* default to align fields on
                                         separate byte boundaries *)
            x: INTEGER <* alignment: MOD 1 BY 2 *> ;  (* align on byte
   boundary (again) but the INTEGER is only to use 2 bits *)
            y: INTEGER <* alignment: MOD 0 BY 6 *> ;  (* pack field, y,
   onto previous byte (if room).  This INTEGER is to use 6 bits *)
         END ;

the big/little endianness of bit ordering would be exactly the same as
the C compiler

regards,
Gaius

ps.  my work email is still down - but I can be reached by:  gaius at
gnu dot org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]