On 4 January 2012 09:39, Manu <turkey...@gmail.com> wrote: > This conversation has meandered into one very specific branch, but I just > want to add my 2c to the OP. > I agree, I want D to be a useful systems language too. These are my issues > to that end: > > * __forceinline ... I wasn't aware this didn't exist... and yes, despite > all this discussion, I still depend on this all the time. People are talking > about implementing forceinline by immitating macros using mixins... crazy? > Here's a solid reason I avoid mixins or procedurally generated code (and the > preprocessor in C for that matter, in favour of __forceinline): YOU CAN > DEBUG IT. In an inline function, the code exists in the source file, just > like any other function, you can STEP THE DEBUGGER through it, and inspect > the values easily. This is an underrated requirement. I would waste hours on > many days if I couldn't do this. I would only ever use string mixins for the > most obscure uses, preferring inline functions for the sake of debugging 99% > of the time. > > * vector type ... D has exactly no way to tell the compiler to allocate > 128bit vector registers, load/store, and pass then to/from functions. That > is MOST of the register memory on virtually every modern processor, and D > can't address it... wtf? > > * inline assembler needs pseudo registers ... The inline assembler is > pretty crap, immitating C which is out-dated. Registers in assembly code > should barely ever be addressed directly, they should only be addressed by > TYPE, allowing the compiler to allocate available registers (and/or manage > storing the the stack where required) as with any other code. Inline > assembly without pseudo-registers is almost always an un-optimisation, and > this is also the reason why almost all C programmers use hardware opcode > intrinsics instead of inline assembly. There is no way without using > intrinsics in C to allow the compiler to perform optimal register > allocation, and this is still true for D, and in my opinion, just plain > broken. > > * __restrict ... I've said this before, but not being able to hint that the > compiler ignore possible pointer aliasing is a big performance problem, > especially when interacting with C libs. > > * multiple return values (in registers) ... (just because I opened a topic > about it before) This saves memory accesses in common cases where i want to > return (x, y), or (retVal, errorCode) for instance. > > 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? > 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? >
Code that gdc emits is incompatible with the standard D compiler, if that's what you want to call it, and any vendor extensions won't contribute to that being more of the case. Regardless, there is little reason to want to use a forced inline with gdc. Just like in c++ when you define all methods in the class definition, gdc considers all methods as candidates for inlining. Similarly, when -inline is passed, the same is also done for normal functions that are considered inlinable by the frontend. These functions marked as inline are treated in the same way as a function declared 'inline' in C or C++, and will be treated as such by the backend. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';