System programming in D (Was: The God Language)

[Artur Skawina]

On 01/04/12 10:39, Manu wrote:
> 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?

Some of these things are *already* in GDC... Probably not documented and tested enough [1], but they are there. So you /can/ have function declarations such as:

pragma(GNU_attribute, always_inline, flatten, hot) int fxx(int i) { ... }

Now, this wouldn't be that bad, if we had a preprocessor or some kind of macro facility. But as it is, writing portable code is too expensive. (I may need to add a cpp stage for D because of issues like this, haven't decided yet...)

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

There are more issues, that *will* be fixed in time, once (maybe even "if") D matures. A wiki page etc listing all the needed changes ("D next generation") would definitively be helpful. Not only to record what needs fixing, but also what to avoid. Could reduce the inevitable balkanization significantly.


Functions attributes seems like it could be an easy, backward compatible addition:

@attr(attributes...)

then define some obvious generic attributes like "inline" (which is (always|force)_inline, as it's the only one that makes sense), "noinline", "hot", "cold" etc. This lets you write "@attr(inline) int f(i){}" etc, but doesn't help the vendor specific attr case at all, unfortunately. [2]

artur

[1] Like the "target" "tune" (sub)attribute, which is not per function, but global (ie behaves as C #pragma). That might be a gcc bug though. Also, using gcc asm in a function makes the compiler generate worse code (triggered by the /first/ asm use, next ones within a function are free). 

[2] The problem is what do you do when you have a lot of function/methods that need to be inlined/flattened, have a different calling convention or otherwise need to be specially marked _and_ it needs to be done differently for different compilers?...