gm2
[Top][All Lists]
Advanced

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

[Gm2] Control of memory alignment


From: Benjamin Kowarsch
Subject: [Gm2] Control of memory alignment
Date: Sun, 11 Dec 2011 13:41:41 +0100

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.

rgds
bk




reply via email to

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