www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - struct field alignment

reply Walter Bright <newshound2 digitalmars.com> writes:
http://www.digitalmars.com/d/2.0/attribute.html#align

Over time, it has become clear to me that there are only two useful alignments:

   align     // set to whatever the C ABI alignment is
   align(1)  // pack everything in, no alignment padding

I think any other alignments should be deprecated. Note that with align(1), any 
alignment is achievable simply by adding in byte fields where desired.
Oct 17 2010
next sibling parent reply BCS <none anon.com> writes:
Hello Walter,


 http://www.digitalmars.com/d/2.0/attribute.html#align
 
 Over time, it has become clear to me that there are only two useful
 alignments:
 
 align     // set to whatever the C ABI alignment is
 align(1)  // pack everything in, no alignment padding
 I think any other alignments should be deprecated. Note that with
 align(1), any alignment is achievable simply by adding in byte fields
 where desired.
 


If that's the case, then having a number in there seems silly: how about 
align and pack?

-- 
... <IXOYE><
Oct 17 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
BCS wrote:

 If that's the case, then having a number in there seems silly: how about 
 align and pack?



Another keyword.
Oct 17 2010
parent "Craig Black" <cblack ara.com> writes:
Not that it's a big deal but another idea align(pack), which could be 
implemented without making pack a keyword.

"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:i9gbr2$2c11$1 digitalmars.com...

 BCS wrote:

 If that's the case, then having a number in there seems silly: how about 
 align and pack?



 Another keyword.
Oct 18 2010
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 18 Oct 2010 06:00:49 +0400, Walter Bright  
<newshound2 digitalmars.com> wrote:


 http://www.digitalmars.com/d/2.0/attribute.html#align

 Over time, it has become clear to me that there are only two useful  
 alignments:

    align     // set to whatever the C ABI alignment is
    align(1)  // pack everything in, no alignment padding

 I think any other alignments should be deprecated. Note that with  
 align(1), any alignment is achievable simply by adding in byte fields  
 where desired.


On some platforms it is desired to align struct Vec { float[4] data; } on  
16 bytes. I don't recall why now, but I know for sure we do that for all  
platforms (other than PC maybe). I guess that has something to do with  
vector operations.

Bikeshed note: how about align(C) to be consistent with both align(1) and  
extern(C)?
Oct 17 2010
next sibling parent reply BCS <none anon.com> writes:
Hello Denis,


 On some platforms it is desired to align struct Vec { float[4] data; }
 on  16 bytes.


At a guess, that is aligning the structure in memory, not the members in 
the struct. I think the 2nd is the question here.


 Bikeshed note: how about align(C) to be consistent with both align(1)
 and  extern(C)?
 


vote++;


-- 
... <IXOYE><
Oct 17 2010
parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 18 Oct 2010 06:22:32 +0400, BCS <none anon.com> wrote:


 Hello Denis,


 On some platforms it is desired to align struct Vec { float[4] data; }
 on  16 bytes.


 At a guess, that is aligning the structure in memory, not the members in  
 the struct. I think the 2nd is the question here.


Yes, I was talking about stack alignment.


 Bikeshed note: how about align(C) to be consistent with both align(1)
 and  extern(C)?


 vote++;


align(default) could also work.
Oct 17 2010
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Denis Koroskin wrote:

 On some platforms it is desired to align struct Vec { float[4] data; } 
 on 16 bytes. I don't recall why now, but I know for sure we do that for 
 all platforms (other than PC maybe). I guess that has something to do 
 with vector operations.


I was thinking of special casing such arrays to be 16 byte aligned by default.



 Bikeshed note: how about align(C) to be consistent with both align(1) 
 and extern(C)?


align is shorter than align(C).
Oct 17 2010
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 17 October 2010 20:07:26 Walter Bright wrote:

 Denis Koroskin wrote:

 On some platforms it is desired to align struct Vec { float[4] data; }
 on 16 bytes. I don't recall why now, but I know for sure we do that for
 all platforms (other than PC maybe). I guess that has something to do
 with vector operations.


 
 I was thinking of special casing such arrays to be 16 byte aligned by
 default.
 

 Bikeshed note: how about align(C) to be consistent with both align(1)
 and extern(C)?


 
 align is shorter than align(C).


It would be clearer though.

- Jonathna M Davis
Oct 17 2010
prev sibling parent Emil Madsen <sovende gmail.com> writes:
About the 16byte alignment, of 4floats, its mostlikely for SSE :)

On 18 October 2010 04:16, Denis Koroskin <2korden gmail.com> wrote:


 On Mon, 18 Oct 2010 06:00:49 +0400, Walter Bright <
 newshound2 digitalmars.com> wrote:

  http://www.digitalmars.com/d/2.0/attribute.html#align

 Over time, it has become clear to me that there are only two useful
 alignments:

   align     // set to whatever the C ABI alignment is
   align(1)  // pack everything in, no alignment padding

 I think any other alignments should be deprecated. Note that with
 align(1), any alignment is achievable simply by adding in byte fields where
 desired.


 On some platforms it is desired to align struct Vec { float[4] data; } on
 16 bytes. I don't recall why now, but I know for sure we do that for all
 platforms (other than PC maybe). I guess that has something to do with
 vector operations.

 Bikeshed note: how about align(C) to be consistent with both align(1) and
 extern(C)?




-- 
// Yours sincerely
// Emil 'Skeen' Madsen
Oct 18 2010
prev sibling next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Sun, 17 Oct 2010 22:00:49 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:


 http://www.digitalmars.com/d/2.0/attribute.html#align

 Over time, it has become clear to me that there are only two useful  
 alignments:

    align     // set to whatever the C ABI alignment is
    align(1)  // pack everything in, no alignment padding

 I think any other alignments should be deprecated. Note that with  
 align(1), any alignment is achievable simply by adding in byte fields  
 where desired.


I mainly do GP-GPU work using NVIDIA's CUDA + D. Passing data into and out  
of the GPU requires conforming to align(8) and align(16) structs as well  
as structs that contain align(8)/align(16) structs. At first, I tried  
using align(8)/align(16) + .alignof, only to find out that those weren't  
supported. Currently, I use an enum flag and a bunch of packing/unpacking  
routines in order to send/access data. Maintaining the correct alignment  
with composite structs manually is a difficult/brittle endeavor; its fine  
for interfacing with a stable code base, but not for development where  
things are constantly changing. Also, CUDA requires that the programmer  
maintain the proper function call alignment, adding another place where  
one has to remember to pad correctly.

Although I have a solution that works well for me, the one thing I lament  
about not having a canonical D way of expression align(8)/align(16), even  
at only a meta-information level, is that if phobos gets a small vector  
library, I can't use it and conversely I'm not motivated to improve/submit  
my own small vector library to phobos.
Oct 17 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Robert Jacques wrote:

 Although I have a solution that works well for me, the one thing I 
 lament about not having a canonical D way of expression 
 align(8)/align(16), even at only a meta-information level, is that if 
 phobos gets a small vector library, I can't use it and conversely I'm 
 not motivated to improve/submit my own small vector library to phobos.


I'm painfully aware that align(8)/(16) don't work on the 32 bit targets. I've 
been reluctant to fix that because it involves some performance degradation 
(keeping the stack so aligned requires the insertion of stack adjustment 
instructions here and there).

With the 64 bit target, however, the C ABI will force the issue. It'll support 
those alignments.
Oct 17 2010
parent "Robert Jacques" <sandford jhu.edu> writes:
On Sun, 17 Oct 2010 23:38:34 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:


 Robert Jacques wrote:

 Although I have a solution that works well for me, the one thing I  
 lament about not having a canonical D way of expression  
 align(8)/align(16), even at only a meta-information level, is that if  
 phobos gets a small vector library, I can't use it and conversely I'm  
 not motivated to improve/submit my own small vector library to phobos.


 I'm painfully aware that align(8)/(16) don't work on the 32 bit targets.  
 I've been reluctant to fix that because it involves some performance  
 degradation (keeping the stack so aligned requires the insertion of  
 stack adjustment instructions here and there).

 With the 64 bit target, however, the C ABI will force the issue. It'll  
 support those alignments.


Cool. I understand the performance issue, but would it be possible for the  
internal alignment of a struct to be correct? i.e. struct A { float x;  
float2 point; } would be properly aligned internally: struct A { float x;  
int padding; float2 point; }. That way, 32-bit programs could read binary  
files from 64-bit programs and vice-versa.
Oct 21 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:


 I'm painfully aware that align(8)/(16) don't work on the 32 bit targets. I've 
 been reluctant to fix that because it involves some performance degradation 
 (keeping the stack so aligned requires the insertion of stack adjustment 
 instructions here and there).


On the other hand stack-allocated structs and arrays that need to be 16-byte
aligned may speed up the code if used with certain SSE+ instructions.

If it is something that must be used for the whole program then you may add a
compiler switch to activate stack alignment on request.

If it may work for a single compilation unit then use something like:
align(16) module foobar;

If it may work for a single function, then then you may add the alignment for
functions:
align(16) int foo(int x) {...

Bye,
bearophile
Oct 18 2010
prev sibling next sibling parent Fawzi Mohamed <fawzi gmx.ch> writes:
On 18-ott-10, at 04:00, Walter Bright wrote:


 http://www.digitalmars.com/d/2.0/attribute.html#align

 Over time, it has become clear to me that there are only two useful  
 alignments:

  align     // set to whatever the C ABI alignment is
  align(1)  // pack everything in, no alignment padding

 I think any other alignments should be deprecated. Note that with  
 align(1), any alignment is achievable simply by adding in byte  
 fields where desired.


I fully agree that those two are the only really useful alignment  
properties for fields in a struct.
Another thing that is needed is specifying the alignment of the struct  
itself, for example if it contains fields that one wants to use with  
SSE.
So one should have the freedom to specify the wanted alignment for the  
structure

Fawzi
Oct 18 2010
prev sibling parent Trass3r <un known.com> writes:
 http://www.digitalmars.com/d/2.0/attribute.html#align

 Over time, it has become clear to me that there are only two useful  
 alignments:

    align     // set to whatever the C ABI alignment is
    align(1)  // pack everything in, no alignment padding

 I think any other alignments should be deprecated. Note that with  
 align(1), any alignment is achievable simply by adding in byte fields  
 where desired.


Isn't the first case unnecessary if C ABI alignment is the default one  
anyway?
Oct 21 2010