System programming in D (Was: The God Language)

[Manu]

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?

This is a great example of why C is shit, and a good example of why I'm
interested in D at all...

On 29 December 2011 13:19, Vladimir Panteleev
<vladimir at thecybershadow.net>wrote:

> On Thursday, 29 December 2011 at 09:16:23 UTC, Walter Bright wrote:
>
>> Are you a ridiculous hacker? Inline x86 assembly that the compiler
>> actually understands in 32 AND 64 bit code, hex string literals like x"DE
>> ADB EEF" where spacing doesn't matter, the ability to set data alignment
>> cross-platform with type.alignof = 16, load your shellcode verbatim into a
>> string like so: auto str = import("shellcode.txt");
>>
>
> I would like to talk about this for a bit. Personally, I think D's system
> programming abilities are only half-way there. Note that I am not talking
> about use cases in high-level application code, but rather low-level,
> widely-used framework code, where every bit of performance matters (for
> example: memory copy routines, string builders, garbage collectors).
>
> In-line assembler as part of the language is certainly neat, and in fact
> coming from Delphi to C++ I was surprised to learn that C++ implementations
> adopted different syntax for asm blocks. However, compared to some C++
> compilers, it has severe limitations and is D's only trick in this alley.
>
> For one thing, there is no way to force the compiler to inline a function
> (like __forceinline / __attribute((always_inline)) ). This is fine for
> high-level code (where users are best left with PGO and "the compiler knows
> best"), but sucks if you need a guarantee that the function must be
> inlined. The guarantee isn't just about inlining heuristics, but also
> implementation capabilities. For example, some implementations might not be
> able to inline functions that use certain language features, and your
> code's performance could demand that such a short function must be inlined.
> One example of this is inlining functions containing asm blocks - IIRC DMD
> does not support this. The compiler should fail the build if it can't
> inline a function tagged with @forceinline, instead of shrugging it off and
> failing silently, forcing users to check the disassembly every time.
>
> You may have noticed that GCC has some ridiculously complicated assembler
> facilities. However, they also open the way to the possibilities of writing
> optimal code - for example, creating custom calling conventions, or
> inlining assembler functions without restricting the caller's register
> allocation with a predetermined calling convention. In contrast, DMD is
> very conservative when it comes to mixing D and assembler. One time I found
> that putting an asm block in a function turned what were single
> instructions into blocks of 6 instructions each.
>
> D's lacking in this area makes it impossible to create language features
> that are on the level of D's compiler built-ins. For example, I have tested
> three memcpy implementations recently, but none of them could beat DMD's
> standard array slice copy (despite that in release mode it compiles to a
> simple memcpy call). Why? Because the overhead of using a custom memcpy
> routine negated its performance gains.
>
> This might have been alleviated with the presence of sane macros, but no
> such luck. String mixins are not the answer: trying to translate
> macro-heavy C code to D using string mixins is string escape hell, and
> we're back to the level of shell scripts.
>
> We've discussed this topic on IRC recently. From what I understood, Andrei
> thinks improvements in this area are not "impactful" enough, which I find
> worrisome.
>
> Personally, I don't think D qualifies as a true "system programming
> language" in light of the above. It's more of a compiled language with
> pointers and assembler. Before you disagree with any of the above, first
> (for starters) I'd like to invite you to translate Daniel Vik's C memcpy
> implementation to D: http://www.danielvik.com/2010/**
> 02/fast-memcpy-in-c.html<http://www.danielvik.com/2010/02/fast-memcpy-in-c.html>. It doesn't even use inline assembler or compiler intrinsics.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120104/c64050d7/attachment-0001.html>