System programming in D (Was: The God Language)

[Iain Buclaw]

On 5 January 2012 20:36, Manu <turkeyman at gmail.com> 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.
>
> 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.
>

I dabbled with vector types, none of the vector builtins are hashed
out to GDC because it really does require that vector be a unique type
from a normal array.

>   * 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.
>     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...
>

This is only possible using GDC extended asm - which is really GCC asm
but encapsulated in {} instead of ();

>   * __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.
>

I don't think D enforces any sort of aliasing rules, but it would be
nice to turn on strict aliasing though...

>   * __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.
>

__forceinline still won't be a guarantee though.


-- 
Iain Buclaw

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