View mode: basic / threaded / horizontal-split · Log in · Help
October 18, 2010
Re: struct field alignment
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
October 18, 2010
Re: struct field alignment
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.
October 18, 2010
Re: struct field alignment
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
October 21, 2010
Re: struct field alignment
> 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?
October 22, 2010
Re: struct field alignment
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.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home