System programming in D (Was: The God Language)

Manu turkeyman at gmail.com
Wed Jan 4 10:53:48 PST 2012


Oh, and virtual-by-default... completely unacceptable for a systems
language. most functions are NOT virtual, and finding the false-virtuals
while optimising will be extremely tedious and time consuming. Worse, if
libraries contain false virtuals, there's good chance I may not be able to
use said library on certain architectures (PPC, ARM in particular).
Terrible decision... completely contrary to modern hardware design and
trends. Why invent a 'new' language for 10 year old hardware?

On 4 January 2012 11:39, Manu <turkeyman at 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?
>
> 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/f47777ce/attachment-0001.html>


More information about the Digitalmars-d mailing list