On 5 January 2012 23:03, Sean Kelly <sean@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.