System programming in D (Was: The God Language)

[Iain Buclaw]

On 4 January 2012 09:39, Manu <turkeyman at gmail.com> wrote:
> This conversation has meandered into one very specific branch, but I just
> want to add my 2c to the OP.
> I agree, I want D to be a useful systems language too. These are my issues
> to that end:
>
>  * __forceinline ... I wasn't aware this didn't exist... and yes, despite
> all this discussion, I still depend on this all the time. People are talking
> about implementing forceinline by immitating macros using mixins... crazy?
> Here's a solid reason I avoid mixins or procedurally generated code (and the
> preprocessor in C for that matter, in favour of __forceinline): YOU CAN
> DEBUG IT. In an inline function, the code exists in the source file, just
> like any other function, you can STEP THE DEBUGGER through it, and inspect
> the values easily. This is an underrated requirement. I would waste hours on
> many days if I couldn't do this. I would only ever use string mixins for the
> most obscure uses, preferring inline functions for the sake of debugging 99%
> of the time.
>
>  * vector type ... D has exactly no way to tell the compiler to allocate
> 128bit vector registers, load/store, and pass then to/from functions. That
> is MOST of the register memory on virtually every modern processor, and D
> can't address it... wtf?
>
>  * inline assembler needs pseudo registers ... The inline assembler is
> pretty crap, immitating C which is out-dated. Registers in assembly code
> should barely ever be addressed directly, they should only be addressed by
> TYPE, allowing the compiler to allocate available registers (and/or manage
> storing the the stack where required) as with any other code. Inline
> assembly without pseudo-registers is almost always an un-optimisation, and
> this is also the reason why almost all C programmers use hardware opcode
> intrinsics instead of inline assembly. There is no way without using
> intrinsics in C to allow the compiler to perform optimal register
> allocation, and this is still true for D, and in my opinion, just plain
> broken.
>
>  * __restrict ... I've said this before, but not being able to hint that the
> compiler ignore possible pointer aliasing is a big performance problem,
> especially when interacting with C libs.
>
>  * multiple return values (in registers) ... (just because I opened a topic
> about it before) This saves memory accesses in common cases where i want to
> return (x, y), or (retVal, errorCode) for instance.
>
> Walter made an argument "The same goes for all those language extensions you
> mentioned. Those are not part of Standard C. They are vendor extensions.
> Does that mean that C is not actually a systems language? No."
> This is absurd... are you saying that you expect Iain to add these things to
> GDC to that people can use them, and then create incompatible D code with
> the 'standard' compiler?
> Why would you intentionally fragment the compiler support of language
> features rather than just making trivial (but important) features that
> people do use part of the language?
>

Code that gdc emits is incompatible with the standard D compiler, if
that's what you want to call it, and any vendor extensions won't
contribute to that being more of the case.

Regardless, there is little reason to want to use a forced inline with
gdc.  Just like in c++ when you define all methods in the class
definition, gdc considers all methods as candidates for inlining.
Similarly, when -inline is passed, the same is also done for normal
functions that are considered inlinable by the frontend.  These
functions marked as inline are treated in the same way as a function
declared 'inline' in C or C++, and will be treated as such by the
backend.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';