2 ms·

I'm still in the camp of using computers our users tend to have. Also, self-compile times are strongly related to how much code there is in the compiler, not j

I'm still in the camp of using computers our users tend to have. Also, self-compile times are strongly related to how much code there is in the compiler, not just the compile speed. I also confess to being a bit jaded on this. I've been generating code from 8086 processors to the latest. Which instructions and combinations are faster is always flip-flopping around from chip to chip. So I leave it to the gdc/ldc compilers for the top shelf speed, and just try to make the code gen bulletproof and do a solid job. Working on the new AArch64 has been quite fun. I'll be doing a presentation on it later in the summer. My target machine is a Raspberry Pi, which is a great machine. Having the two code generators side by side also significantly increased the build times, because it's a lot more code being compiled.

AndyKelley 1y ago
Fair enough, and yeah I hear you on the compilation cost of all the targets. We don't have aarch64 yet but in addition to x86_64 we do have an LLVM backend, a C backend, a SPIR-V backend, WebAssembly backend, RISC-V backend, and sparc backend. All that plus the stuff I mentioned earlier in 15s on a modern laptop.
- WalterBright 1y ago
  I considered a C backend at one time, but C is not expressive enough. The generated code would be ugly. For example, exception handling. D's heavy reliance on common blocks in the object code is another issue. C doesn't support nested functions (static links). And so on. Never found a user who asked for that, either :-/
  - steveklabnik 1y ago
    Some users want a C backend, not for maintainability reasons, but for the ability to compile on platforms that have nothing but a C compiler. The maintainability or aesthetics of the C is irrelevant, it's like another intermediate representation.
    - AndyKelley 1y ago
      Can confirm, Zig's generated C is extremely ugly. We literally treat it as an object format [1]. The MSVC limitations are maddening, from how short string literals must be, to the complete lack of inline assembly when targeting x86_64. [1]: https://ziglang.org/documentation/0.14.1/std/#std.Target.ObjectFormat https://ziglang.org/documentation/0.14.1/std/#std.Target.Obj...
    - WalterBright 1y ago
      I bet it would be easier to write a code gen for such platforms than to wrassal generated C code and work around the endless problems. Anyhow, one of the curious features of D is its ability to translate C code to D code. Curious as it was never intentionally designed, it was discovered by one of our users. D has the ability to create a .di file from a .d file, which is analogous to writing a .h file from a .c file. When D gained the ability to compile C files, you just ask it to create a .di file, and voila! the C code translated to D!
      - steveklabnik 1y ago
        Maybe, I don’t use those platforms and so I don’t know from experience, I just know that’s why people asked us in Rust. I somehow missed that D has that! I try to read the forums now and again, but I should keep more active tabs on how stuff is going :)

AndyKelley 1y ago

Fair enough, and yeah I hear you on the compilation cost of all the targets. We don't have aarch64 yet but in addition to x86_64 we do have an LLVM backend, a C backend, a SPIR-V backend, WebAssembly backend, RISC-V backend, and sparc backend. All that plus the stuff I mentioned earlier in 15s on a modern laptop.

WalterBright 1y ago
I considered a C backend at one time, but C is not expressive enough. The generated code would be ugly. For example, exception handling. D's heavy reliance on common blocks in the object code is another issue. C doesn't support nested functions (static links). And so on. Never found a user who asked for that, either :-/
- steveklabnik 1y ago
  Some users want a C backend, not for maintainability reasons, but for the ability to compile on platforms that have nothing but a C compiler. The maintainability or aesthetics of the C is irrelevant, it's like another intermediate representation.
  - AndyKelley 1y ago
    Can confirm, Zig's generated C is extremely ugly. We literally treat it as an object format [1]. The MSVC limitations are maddening, from how short string literals must be, to the complete lack of inline assembly when targeting x86_64. [1]: https://ziglang.org/documentation/0.14.1/std/#std.Target.ObjectFormat https://ziglang.org/documentation/0.14.1/std/#std.Target.Obj...
  - WalterBright 1y ago
    I bet it would be easier to write a code gen for such platforms than to wrassal generated C code and work around the endless problems. Anyhow, one of the curious features of D is its ability to translate C code to D code. Curious as it was never intentionally designed, it was discovered by one of our users. D has the ability to create a .di file from a .d file, which is analogous to writing a .h file from a .c file. When D gained the ability to compile C files, you just ask it to create a .di file, and voila! the C code translated to D!
    - steveklabnik 1y ago
      Maybe, I don’t use those platforms and so I don’t know from experience, I just know that’s why people asked us in Rust. I somehow missed that D has that! I try to read the forums now and again, but I should keep more active tabs on how stuff is going :)