== Quote from Manu ([email protected])'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
