[Top][All Lists]
[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