System programming in D (Was: The God Language)

[Sean Kelly]

On Jan 5, 2012, at 12:36 PM, Manu wrote:

> On 5 January 2012 21:41, Sean Kelly <sean at invisibleduck.org> wrote:
> On Jan 5, 2012, at 10:02 AM, Manu wrote:
> >
> > That said, this is just one of numerous issues myself and the OP raised. I don't know why this one became the most popular for discussion... my suspicion is that is because this is the easiest of my complaints to dismiss and shut down ;)
> 
> It's also about the only language change among the issues you mentioned.  Most of the others are QOI issues for compiler vendors.  What I've been curious about is if you really have a need for the performance that would be granted by these features, or if this is more of an idealistic issue.
> 
> I think they are all language requests. They could be implemented by 3rd party compilers, but these things are certainly nice to standardise in the language, or you end up with C, which is a mess I'm trying to escape.

It's a grey area I suppose.  Half of the features you list don't change the language, they simply allow the compiler to make optimizations it otherwise couldn't.  I suppose the D way would be to make them '@' prefixed and provide some means for having the compiler ignore them if it didn't recognize them.  This wouldn't fragment the language so much as make generated code more efficient on supporting platforms.


> Of the topics been discussed:
>   * vector type - I can't be expected to write a game without using the vector hardware... I'd rather use a portable standardised type than a GDC extension. Why the resistance? I haven't heard any good arguments against, other than some murmurings about float[4] as the official syntax, which I gave detailed arguments against.

Could a vector type be defined in the library?  Aside from alignment, there doesn't seem to be anything that requires compiler support.  Or am I missing something?


>   * inline asm supporting pseudo regs - As an extension of using the vector hardware, I'll need inline asm, and inline assembly without pseudo regs is pretty useless... it's mandatory that the compiler shedule the register allocation otherwise inline asm will most likely be an un-optimisation. If D had pseudo regs in its inline assembler, it would make it REALLY attractive for embedded systems programmers.

This would certainly be nice.  When I drop into ASM I generally could care less about which actual register I use.  I just want to call something specific.


>     In lieu of that, I need to use opcode intrinsics instead, which I believe GDC exposes, but again, I'm done with C and versioning (#ifdef-ing) every compiler I intend to use. Why not standardise these things? At least put the intrinsics in the standard lib...
> 
>   * __restrict - Not a deal breaker, but console game dev industry uses this all the time. There are countless articles on the topic (many are private or on console vendor forums). If this is not standardised in the language, GDC will still expose it I'm sure, fragmenting the language.
> 
>   * __forceinline - I'd rather have a proper keyword than using tricks like mixins and stuff as have been discussed. The reason for this is debugging. Code is not-inlined in debug builds, looks&feels like normal code, can still evaluate, and step like regular code... and guarantee that it inlines properly when optimised. This just saves time; no frills debugging.

I'd say these are QOI issues, as above.


>   * multiple return values - This is a purely idealistic feature request, but would lead to some really nice optimisations while retaining very tidy code if implemented properly. Other languages support this, it's a nice modern feature... why not have it in D?

I can see the ABI rules for this getting really complicated, much like how parameter passing rules on x64 are insanely complex compared to x32.  But I agree that it would be a nice feature to have.


> I couldn't release the games I do without efficient use of vector hardware and __restrict used in appropriate places. I use them every day, and I wouldn't begin a project in D without knowing that these features are supported, or are definitely coming to the language.

I know it's a major time commitment, but the best way to realize any new feature quickly is to create a pull request.  Feature proposals have a way of being lost if they never extend beyond this newsgroup.