On 9/21/2011 3:55 PM, Manu wrote:
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.
D doesn't have __restrict. I'm going to argue that it is unnecessary. AFAIK,
__restrict is most used in writing vector operations. D, on the other hand, has
a dedicated vector operation syntax:
a[] += b[] * c;
where a[] and b[] are required to not be overlapping, hence enabling
parallelization of the operation.
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?
D does have some intrinsics, like sin() and cos(). They tend to get added on a
strictly as-needed basis, not a speculative one.
D has no current intention to replace the inline assembler with intrinsics.
As for custom intrinsics, Don Clugston wrote an amazing piece of demonstration D
code a while back that would take a string representing a floating point
expression, and would literally compile it (using Compile Time Function
Execution) and produce a string literal of inline asm functions, which were then
compiled by the inline assembler.
So yes, it is entirely possible and practical for end users to write custom
intrinsics.
Is the D assembler a macro assembler?
No. It's what-you-write-is-what-you-get.
(ie, assigns registers
automatically and manage loads/stores intelligently?)
No. It's intended to be a low level assembler for those who want to precisely
control things.
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.
I enjoy writing x86 inline assembler :-)
Are there PowerPC or ARM examples anywhere?
The intention is for other CPU targets to employ the syntax used in their
respective CPU manual datasheets.
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?
The language supports it now (see the aforementioned vector syntax), it's just
that the vector code gen isn't done (currently it is just implemented using loops).
Is it possible in D currently to pass vectors to functions by value
in registers? Without an intrinsic vector type, it would seem
impossible.
Vectors (statically dimensioned arrays) are currently passed by value (unlike C
or C++).
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.
Yes, I agree.
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?
Your C++ vector code should be amenable to translation to D, so that effort of
yours isn't lost, except that it'd have to be in inline asm rather than intrinsics.
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.
I don't know much about GDC's capabilities.
