Any chance of 128-bit alignment of static arrays?

[Jarrett Billingsley]

"Dan" <murpsoft at hotmail.com> wrote in message 
news:fg61am$2p80$1 at 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.