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

[Walter Bright]

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.