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

[Iain Buclaw]

== Quote from Manu (turkeyman at gmail.com)'s article
> 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?

The DMD compiler has some basic intrinsics, other compilers build upon this using
their own backends. ie: GCC has hundreds of builtins, including some target
builtins where intrinsic types are mappable to D types (__float80 ->.real).

> 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 would imagine it should now be possible to use GCC vector builtins with the GDC
compiler. Given that I manage to get round to turning these routines on though. :~)

> 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.

Someone has recently confirmed D working just fine on the Alpha platform.  For D2,
your biggest showstopper is the runtime library.  There are many gaps to fill to
port druntime to your preferred architecture.

Regards