www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Any chance of 128-bit alignment of static arrays?

reply Don Clugston <dac nospam.com.au> writes:
When using SSE/SSE2, it's necessary to have arrays aligned to 128-bit (16 byte) 
boundaries. For DMD Windows, this is satisfied for arrays allocated on the
heap, 
but not for arrays on the stack, nor for static arrays.

There's no workaround that I know of; for example, you cannot put the array in
a 
struct and specify an alignment, because the struct itself will only be aligned 
to a 8 byte boundary.

I recognize that there are major difficulties in aligning arrays on the stack, 
but could we get 16 byte -aligned double and float static arrays and array 
literals? Or is this an OPTLINK limitation?
Oct 29 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don Clugston wrote:

 When using SSE/SSE2, it's necessary to have arrays aligned to 128-bit 
 (16 byte) boundaries. For DMD Windows, this is satisfied for arrays 
 allocated on the heap, but not for arrays on the stack, nor for static 
 arrays.
 
 There's no workaround that I know of; for example, you cannot put the 
 array in a struct and specify an alignment, because the struct itself 
 will only be aligned to a 8 byte boundary.
 
 I recognize that there are major difficulties in aligning arrays on the 
 stack, but could we get 16 byte -aligned double and float static arrays 
 and array literals? Or is this an OPTLINK limitation?


It's not an optlink problem. Let me look into it.
Oct 29 2007
parent reply Dan <murpsoft hotmail.com> writes:
Walter Bright Wrote:


 Don Clugston wrote:

 When using SSE/SSE2, it's necessary to have arrays aligned to 128-bit 
 (16 byte) boundaries. For DMD Windows, this is satisfied for arrays 
 allocated on the heap, but not for arrays on the stack, nor for static 
 arrays.
 
 There's no workaround that I know of; for example, you cannot put the 
 array in a struct and specify an alignment, because the struct itself 
 will only be aligned to a 8 byte boundary.
 
 I recognize that there are major difficulties in aligning arrays on the 
 stack, but could we get 16 byte -aligned double and float static arrays 
 and array literals? Or is this an OPTLINK limitation?


 
 It's not an optlink problem. Let me look into it.


Heh, actually Walter, I've been studying alot on osdev.org, and I've completely
given up with D because it only allows me to program for an obsolete platform.

I really do like the notation, but it's the final code that counts, and only
YASM assembler is letting me do what I need to.

If I may be so brash; D needs ucent, 16-byte alignment, XMM8-15, R*X 64-bit
GPR's, the amd64 instruction set, version(Windows64), version(linux64), and
version(DInline_Asm*) with that featureset.

If ucent is done properly, I understand it'll take alot of work.  You'd want to
bind it to the XMM registers and they use completely different instructions
than ulong's and uints.

Anyways, I'll talk to you guys later.
Oct 29 2007
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Dan" <murpsoft hotmail.com> wrote in message 
news:fg61am$2p80$1 digitalmars.com...


 Heh, actually Walter, I've been studying alot on osdev.org, and I've 
 completely given up with D because it only allows me to program for an 
 obsolete platform.

 I really do like the notation, but it's the final code that counts, and 
 only YASM assembler is letting me do what I need to.

 If I may be so brash; D needs ucent, 16-byte alignment, XMM8-15, R*X 
 64-bit GPR's, the amd64 instruction set, version(Windows64), 
 version(linux64), and version(DInline_Asm*) with that featureset.


You must not have heard of GDC.  My friends and I are using it and its 
extended inline ASM to write a kernel for x86-64 in D.  Keep in mind that 
the inline ASM provided by the DMDFE isn't supposed to be the _only_ inline 
ASM that compilers can support.  TBH I kind of like the route GDC has taken 
in this regard, as it means traditional ASM syntaxes can be preserved, 
instead of having to map them, possibly unfavorably, to fit in with the 
syntactic boundaries of the D grammar.


 If ucent is done properly, I understand it'll take alot of work.  You'd 
 want to bind it to the XMM registers and they use completely different 
 instructions than ulong's and uints.


I don't really see how ucent at all maps to XMM registers.. [u]cent is an 
integer type, which would probably be represented as a RDX:RAX pair, much as 
[u]long is EDX:EAX in x86.  The multimedia registers are completely 
different semantically, and mapping them to an integer type makes no sense.

If D did include i.e. float4, meaning 4 32-bit IEEE 754 floats to be put 
into a SIMD register, it would be a first for any programming language.
Oct 29 2007
parent Don Clugston <dac nospam.com.au> writes:
Jarrett Billingsley wrote:

 "Dan" <murpsoft hotmail.com> wrote in message 
 news:fg61am$2p80$1 digitalmars.com...
 

 Heh, actually Walter, I've been studying alot on osdev.org, and I've 
 completely given up with D because it only allows me to program for an 
 obsolete platform.

 I really do like the notation, but it's the final code that counts, and 
 only YASM assembler is letting me do what I need to.

 If I may be so brash; D needs ucent, 16-byte alignment, XMM8-15, R*X 
 64-bit GPR's, the amd64 instruction set, version(Windows64), 
 version(linux64), and version(DInline_Asm*) with that featureset.


 
 You must not have heard of GDC.  My friends and I are using it and its 
 extended inline ASM to write a kernel for x86-64 in D.  Keep in mind that 
 the inline ASM provided by the DMDFE isn't supposed to be the _only_ inline 
 ASM that compilers can support.


It would be horrible if that situation persists long-term, though. It's 
fantastic to be able to write asm code that will work on Linux and Windows.

   TBH I kind of like the route GDC has taken

 in this regard, as it means traditional ASM syntaxes can be preserved, 
 instead of having to map them, possibly unfavorably, to fit in with the 
 syntactic boundaries of the D grammar.
 

 If ucent is done properly, I understand it'll take alot of work.  You'd 
 want to bind it to the XMM registers and they use completely different 
 instructions than ulong's and uints.


 
 I don't really see how ucent at all maps to XMM registers.. [u]cent is an 
 integer type, which would probably be represented as a RDX:RAX pair, much as 
 [u]long is EDX:EAX in x86.  The multimedia registers are completely 
 different semantically, and mapping them to an integer type makes no sense.


Agreed. I haven't found any XMM instructions which use 128-bit integers. Only 
pairs of QWORDS.


 
 If D did include i.e. float4, meaning 4 32-bit IEEE 754 floats to be put 
 into a SIMD register, it would be a first for any programming language. 


I wonder if there is any advantage to float4 over float[4] ? (with float[4] 
being optimised specially by the compiler to be SIMD). It would allow you to
use 
  SIMD registers for parameter passing in extern functions, I guess.
Oct 30 2007