View mode: basic / threaded / horizontal-split · Log in · Help
October 29, 2007
Any chance of 128-bit alignment of static arrays?
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?
October 29, 2007
Re: Any chance of 128-bit alignment of static arrays?
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.
October 30, 2007
Re: Any chance of 128-bit alignment of static arrays?
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.
October 30, 2007
Re: Any chance of 128-bit alignment of static arrays?
"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.
October 30, 2007
Re: Any chance of 128-bit alignment of static arrays?
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.
Top | Discussion index | About this forum | D home