Re: Isn't it time there was a standard align statement?



artifact.one@xxxxxxxxxxxxxx wrote:
It'd be really pleasant (in my opinion) if the next revision of the
C language actually allowed some portable control over data
alignment.

Compiler-specific mechanisms for this stuff are so varied that
it becomes impossible to even abstract the details away behind
preprocessor macros.

What I'd like to see:

/* per structure alignment */
align(16) struct xyz {
char x;
char y;
int z;
};

Why would you "like to see" this? If you're dealing with
a particular compiler for a particular piece of hardware, you
can use whatever compiler-specific mechanisms are provided.
But if you're seeking "portable control," how portable is the
magic number 16?

> [...]
so in the case of the host implementation not supporting the specified
alignment, a warning should be emitted and either the closest or
natural alignment should be given. Warnings can obviously be made
fatal with compiler specific switches - and that's no business of the
language.

If different implementations can do whatever they please with
the directive, how "portable" is it? As with register you can
write it and be assured all compilers will accept it, but as with
register you don't really know what effect it will have on the code.

It just seems that this really should be standardized as it clearly
is useful for a vast number of programmers who need to get close to the
hardware but don't want to stray into assembly code (think Altivec,
SSE).

I'm not familiar with them, but I'll suppose they're machines
with unusual and finicky alignment constraints. Very well, then:
What *one* value can you put inside an align(N) directive such that
the data will be aligned as desired on both of these machines and
on all others, too? To put it another way, if you are concerned
about such details it seems "portability" has already ceased to be
a concern.

Sounds like EXACTLY the point of the C language, doesn't it?

You'll need to ask dmr, but I don't think so.

I wouldn't mind so much if compiler implementors had come up with a
vaguely portable way of doing this, but they haven't even come close.
GCC and Intel have won joint first prize for 'most pleasant
implementation' though (__attribute__ or _declspec()).

The details of data alignment are themselves non-portable, so
the incentive to develop a portable means of controlling them seems
small. Whenever you decree that the alignment of thus-and-such
should be this-and-that, you immediately restrict the portability
of the code. All I can see is that you're proposing a portable
way to declare that a piece of code is non-portable.

--
Eric Sosman
esosman@xxxxxxxxxxxxxxxxxxx
.



Relevant Pages

  • Re: C portability is a myth
    ... portability has to do with availability, ... I am not convinced yet that it isn't a compiler bug (I saw ... >> was the C standard itself which was the culprit in causing the ... Porting requires effort regardless of whether or not I have conformed ...
    (comp.lang.c)
  • Re: Standard Ada Preprocessor
    ... because Ada cannot deal with the portability issues. ... > you are interfacing directly to some special-purpose hardware. ... by their nature not compiler ... one platform you get 3 members back, and on another you get 5, ...
    (comp.lang.ada)
  • Re: <ctype.h> toLower()
    ... I need to link in the standard C library. ... > know what the target platform is, your compiler doesn't. ... at it -- it might not explain portability, ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Isnt it time there was a standard align statement?
    ... same method of specifying data alignment. ... The hardware is the same, ... fatal with compiler specific switches - and that's no business of the ... A vector math portability library. ...
    (comp.lang.c)
  • Re: Isnt it time there was a standard align statement?
    ... alignment, a warning should be emitted and either the closest or ... fatal with compiler specific switches - and that's no business of the ... about such details it seems "portability" has already ceased to be ... every struct in a codebase has the last member uint32_t checksum; I need a macro that would set a member value and modify the checksum member: ...
    (comp.lang.c)