__restrict, architecture intrinsics vs asm, consoles, and other stuff

[Manu]

Hello D community.

I've been reading a lot about D lately. I have known it existed for
ages, but for some reason never even took a moment to look into it.
The more I looked into it, the more I realise, this is the language
I want. C(/C++) has been ruined, far beyond salvation. D seems to be
the reboot that it desperately needs.

Anyway, I work in the games industry, 10 years in cross platform
console games at major studios. Sadly, I don't think Microsoft,
Sony, Nintendo, Apple, Google (...maybe google) will support D any
time soon, but I've started some after-hours game projects to test D
in a some real gamedev environments.

So far I have these (critical) questions.

Pointer aliasing... C implementations uses a non-standard __restrict
keyword to state that a given pointer will not be aliased by any
other pointer. This is critical in some pieces of code to eliminate
redundant loads and stores, particularly important on RISC
architectures like PPC.
How does D address pointer aliasing? I can't imagine the compiler
has any way to detect that pointer aliasing is not possible in
certain cases, many cases are just far too complicated. Is there a
keyword? Or plans? This is critical for realtime performance.

C implementations often use compiler intrinsics to implement
architecture provided functionality rather than inline asm, the
reason is that the intrinsics allow the compiler to generate better
code with knowledge of the context. Inline asm can't really be
transformed appropriately to suit the context in some situations,
whereas intrinsics operate differently, and run vendor specific
logic to produce the code more intelligently.
How does D address this? What options/possibilities are available to
the language? Hooks for vendors to implement intrinsics for custom
hardware?
Is the D assembler a macro assembler? (ie, assigns registers
automatically and manage loads/stores intelligently?) I haven't seen
any non-x86 examples of the D assembler, and I think it's fair to
say that x86 is the single most unnecessary architecture to write
inline assembly that exists. Are there PowerPC or ARM examples
anywhere?

As an extension from that, why is there no hardware vector support
in the language? Surely a primitive vector4 type would be a sensible
thing to have?
Is it possible in D currently to pass vectors to functions by value
in registers? Without an intrinsic vector type, it would seem
impossible.
In addition to that, writing a custom Vector4 class to make use of
VMX, SSE, ARM VFP, PSP VFPU, MIPS 'Vector Units', SH4 DR regs, etc,
wrapping functions around inline asm blocks is always clumsy and far
from optimal. The compiler (code generator and probably the
optimiser) needs to understand the concepts of vectors to make good
use of the hardware.
How can I do this in a nice way in D? I'm long sick of writing
unsightly vector classes in C++, but fortunately using vendor
specific compiler intrinsics usually leads to decent code
generation. I can currently imagine an equally ugly (possibly worse)
hardware vector library in D, if it's even possible. But perhaps
I've missed something here?

I'd love to try out D on some console systems. Fortunately there are
some great home-brew scenes available for a bunch of slightly older
consoles; PSP/PS2 (MIPS), XBox1 (embedded x86), GameCube/Wii (PPC),
Dreamcast (SH4). They all have GCC compilers maintained by the
community. How difficult will it be to make GDC work with those
toolchains? Sadly I know nothing about configuring GCC, so sadly I
can't really help here.

What about Android (or iPhone, but apple's 'x-code policy' prevents
that)? I'd REALLY love to write an android project in D... the
toolchain is GCC, I see no reason why it shouldn't be possible to
write an android app if an appropriate toolchain was available?

Sorry it's a bit long, thanks for reading this far!
I'm looking forward to a brighter future writing lots of D code :P
But I need to know basically all these questions are addressed
before I could consider it for serious commercial game dev.