System programming in D (Was: The God Language)

[Manu]

On 5 January 2012 23:03, Sean Kelly <sean at invisibleduck.org> wrote:

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

Precisely. That's all I want :) .. formal definition of these concepts,
allowing GDC and co to feed that information through to the backend which
already supports these concepts :)


> 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?
>

I think there's a lot you're missing. Load/store patterns, register
allocation, parameter argument convention (ABI details), literals and
assignment, exception handling/error conditions, and alignment... The
actual working functional stuff could/would be done in a library, but even
then, if the opcode intrinsic names weren't standardised, it'd be an awful
mess behind the scenes aggregating all the different names/terminology from
each compiler implementation.

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

It's usually actually disruptive to the program around the inline asm block
if you are naming registers explicitly.. better to let the compiler assign
them, and intelligently flush values to the stack if it runs out of
registers.
AT&T asm syntax allows this, you define 'parameter' types using some silly
string, and then refer to %1, %2, %3 in place of registers in your asm
code, and it will perform the register assignment.
Most C compilers also don't allow program optimisation/rescheduling around
inline asm blocks, this makes them useless, and I'll bet GDC suffers the
same problem right now(...?)

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

Yup, so just standardise the names for these attributes and pass the info
through to GCC's back end... done :) ... Although I'm sure __forceinline
isn't so simple.


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

How so? Parameters are passed in a sequence of regs of the appropriate
type, to a point, at which stage they get put on the stack... is x64
somehow more complicated than that?
Multiple return values would use the exact same regs in reverse. There
should be no side effects, the calling function has already (or has the
caoability to) stored off any save regs in order to pass args in the first
place.

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


Fair call, but I don't have time to get involved in that level right now,
not by a long shot.
I'm just a potential customer trying to give it a fair go at this point...
;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120105/42a23e40/attachment-0001.html>