4 ms·

Given that C has raw pointers and inline assembly, what is D doing that it couldn't (easily?) express?

by Reelin 7y ago

simias 7y ago
Inline assembly is a compiler extension and not portable. Beyond that, sure you can do whatever you want in C if you're willing to mess with assembly and non-portable memory tricks but at this point you're better off writing your own native backend. The whole point of generating C instead of machine code is to leverage the existing compiler infrastructure to support a vast number of architectures and generate efficient code. If you just dump inline assembly in a C function or rely on opaque memory shenanigans the C compiler won't be able to meaningfully optimize your code and it probably won't be portable.
WalterBright 7y ago
1. cannot support anything but the C ABI 2. cannot support exception handling 3. cannot support types that C doesn't 4. stuck with C symbolic debug info, not your language's 5. cannot innovate with things like how strings are stored 6. many C compilers do not emit COMDATs 7. no thread local storage 8. chained to slow compilation speeds 9. stuck with trying to find a way to work around C compiler bugs 10. stuck with whatever C compiler the user has, i.e. one has to support multiple versions of multiple C compilers 11. C compiler can change, breaking your compiler The original C++ compiler, cfront, had a LOT of problems with these issues.
- Reelin 7y ago
  Thanks for taking the time to respond, compilers are always interesting to learn about! Point 7 was (finally!) addressed by C11. Points 6, 8, 9, 10, & 11 are all good ones that hadn't occurred to me. It seems like points 1, 4, & 5 could be worked around, but I can see where the added complexity would be unwelcome. On the whole, I can see why you made the decision you did. However, I don't buy points 2 (exception handling) and 3 (type support). Certainly C doesn't have these things built in, but appropriate code transformations seem to suffice in practice. For example, the CHICKEN Scheme to C compiler employs continuation-passing style [1] and Embeddable Common Lisp [2] manages to compile to C without (to my knowledge) breaking either its type system or its condition and restart [3] system. [1] https://wiki.call-cc.org/chicken-compilation-process https://wiki.call-cc.org/chicken-compilation-process [2] https://www.cliki.net/ECL https://www.cliki.net/ECL [3] http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html http://www.gigamonkeys.com/book/beyond-exception-handling-co...
  - WalterBright 7y ago
    2. yes, it can be done with setjmp/longjmp, but that's a terrible solution 3. if the C compiler doesn't support 80 bit reals (and D does), you're out of luck. I looked at the C code generated by C++ cfront. No thanks. The worst is, the C compiler vendor owns you, and they couldn't care less about you.

Given that C has raw pointers and inline assembly, what is D doing that it couldn't (easily?) express?

by Reelin 7y ago

Given that C has raw pointers and inline assembly, what is D doing that it couldn't (easily?) express?

Inline assembly is a compiler extension and not portable. Beyond that, sure you can do whatever you want in C if you're willing to mess with assembly and non-portable memory tricks but at this point you're better off writing your own native backend. The whole point of generating C instead of machine code is to leverage the existing compiler infrastructure to support a vast number of architectures and generate efficient code. If you just dump inline assembly in a C function or rely on opaque memory shenanigans the C compiler won't be able to meaningfully optimize your code and it probably won't be portable.

WalterBright 7y ago

1. cannot support anything but the C ABI 2. cannot support exception handling 3. cannot support types that C doesn't 4. stuck with C symbolic debug info, not your language's 5. cannot innovate with things like how strings are stored 6. many C compilers do not emit COMDATs 7. no thread local storage 8. chained to slow compilation speeds 9. stuck with trying to find a way to work around C compiler bugs 10. stuck with whatever C compiler the user has, i.e. one has to support multiple versions of multiple C compilers 11. C compiler can change, breaking your compiler The original C++ compiler, cfront, had a LOT of problems with these issues.

Reelin 7y ago
Thanks for taking the time to respond, compilers are always interesting to learn about! Point 7 was (finally!) addressed by C11. Points 6, 8, 9, 10, & 11 are all good ones that hadn't occurred to me. It seems like points 1, 4, & 5 could be worked around, but I can see where the added complexity would be unwelcome. On the whole, I can see why you made the decision you did. However, I don't buy points 2 (exception handling) and 3 (type support). Certainly C doesn't have these things built in, but appropriate code transformations seem to suffice in practice. For example, the CHICKEN Scheme to C compiler employs continuation-passing style [1] and Embeddable Common Lisp [2] manages to compile to C without (to my knowledge) breaking either its type system or its condition and restart [3] system. [1] https://wiki.call-cc.org/chicken-compilation-process https://wiki.call-cc.org/chicken-compilation-process [2] https://www.cliki.net/ECL https://www.cliki.net/ECL [3] http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html http://www.gigamonkeys.com/book/beyond-exception-handling-co...
- WalterBright 7y ago
  2. yes, it can be done with setjmp/longjmp, but that's a terrible solution 3. if the C compiler doesn't support 80 bit reals (and D does), you're out of luck. I looked at the C code generated by C++ cfront. No thanks. The worst is, the C compiler vendor owns you, and they couldn't care less about you.