4 ms·

Just out of curiosity, what would be a great intermediate language to transpile to (as of intermediate language)?

deleted 7y ago
[deleted]
jcranmer 7y ago
Of ones I'm a familiar with, LLVM IR is probably the best, although it has other issues of its own (in particular, floating point is done even worse than C). I'm not aware of any language which is going to beat a retargeting compiler's processor-agnostic IR. But even the "better C" languages tend to not really attempt to expand C structurally. The changes amount to fixing the egregious semantics (fixed-size types, no int-promotion, define signed overflow, etc.), add vector types and other operators, maybe tweak ABI a little bit, and add a whole lot of syntactic sugar. And those languages that explore beyond C's limited structural repertoire do so at the cost of C's specificity. That said, ever since the last time someone asked me this kind of question, I've been trying to design a portable assembly language.
- StreamBright 7y ago
  Interesting. I need to look into LLVM IR a bit more to understand this subject better. >> I've been trying to design a portable assembly language. Couldn't something like Forth fulfill this role?
- aw1621107 7y ago
  > in particular, floating point is done even worse than C Do you mind expanding on this or pointing me to places where I can read more?
  - jcranmer 7y ago
    There is a hidden floating-point environment that affects, and is affected by, every single floating-point instruction. Predominantly, this is rounding mode control, sticky bits, and exception control (does overflow cause a SIGFPE?), although most processors have some form of flushing denormals or treating them as 0s, which isn't in IEEE 754. LLVM's floating point instructions assume that there is no floating point environment [1]. And there's no real facility to indicate that floating point instructions might be affected. To remedy this, they've been working on adding constrained floating point intrinsics. [1] More specifically, that the environment is set up to the default rounding mode (round-nearest), all exceptions are masked, and no one will ever care about sticky bits.
    - brandmeyer 7y ago
      Is GIMPLE any worse or better in this regards?
      - jcranmer 7y ago
        I don't have much experience with GCC innards, but after doing a quick test [1], it seems GCC is as bad as clang in terms of not supporting STDC FENV_ACCESS, so I suspect the answer is that it's pretty much the same. It looks like the only major compiler that actually supports IEEE 754 correctly is icc. MSVC, gcc, and clang all optimize floating-point operations without considering if the dynamic environment is the same. [1] https://godbolt.org/z/x2ERVM https://godbolt.org/z/x2ERVM
mhh__ 7y ago
Firstly the programming language itself, then something like LLVM IR. This is an answer to a slightly different question but rewriting into the same language (i.e. C++ to C++ then LLVM) can make debugging much simpler and implementing features and specific optimizations much more feasible if you don't have control over the backend. IR's should be terse, simple and dumb. I'm not sure any "real" programming language fits that.
ufo 7y ago
In practice I think it is hard to beat C in this regard. You can go pretty far if you are willing adapt to its quirks! And while C doesn't always allow for the best optimization (such as returning multiple values via registers), the workarounds often are still pretty fast. On a more theoretical level there has been some research on what a better intermediate language would look like. One project I found interesting was Mu VM, which offers some niceties for compiling languages with a garbage collector. https://microvm.github.io/ https://microvm.github.io/

deleted 7y ago

[deleted]

Of ones I'm a familiar with, LLVM IR is probably the best, although it has other issues of its own (in particular, floating point is done even worse than C). I'm not aware of any language which is going to beat a retargeting compiler's processor-agnostic IR. But even the "better C" languages tend to not really attempt to expand C structurally. The changes amount to fixing the egregious semantics (fixed-size types, no int-promotion, define signed overflow, etc.), add vector types and other operators, maybe tweak ABI a little bit, and add a whole lot of syntactic sugar. And those languages that explore beyond C's limited structural repertoire do so at the cost of C's specificity. That said, ever since the last time someone asked me this kind of question, I've been trying to design a portable assembly language.

StreamBright 7y ago
Interesting. I need to look into LLVM IR a bit more to understand this subject better. >> I've been trying to design a portable assembly language. Couldn't something like Forth fulfill this role?
aw1621107 7y ago
> in particular, floating point is done even worse than C Do you mind expanding on this or pointing me to places where I can read more?
- jcranmer 7y ago
  There is a hidden floating-point environment that affects, and is affected by, every single floating-point instruction. Predominantly, this is rounding mode control, sticky bits, and exception control (does overflow cause a SIGFPE?), although most processors have some form of flushing denormals or treating them as 0s, which isn't in IEEE 754. LLVM's floating point instructions assume that there is no floating point environment [1]. And there's no real facility to indicate that floating point instructions might be affected. To remedy this, they've been working on adding constrained floating point intrinsics. [1] More specifically, that the environment is set up to the default rounding mode (round-nearest), all exceptions are masked, and no one will ever care about sticky bits.
  - brandmeyer 7y ago
    Is GIMPLE any worse or better in this regards?
    - jcranmer 7y ago
      I don't have much experience with GCC innards, but after doing a quick test [1], it seems GCC is as bad as clang in terms of not supporting STDC FENV_ACCESS, so I suspect the answer is that it's pretty much the same. It looks like the only major compiler that actually supports IEEE 754 correctly is icc. MSVC, gcc, and clang all optimize floating-point operations without considering if the dynamic environment is the same. [1] https://godbolt.org/z/x2ERVM https://godbolt.org/z/x2ERVM

mhh__ 7y ago

Firstly the programming language itself, then something like LLVM IR. This is an answer to a slightly different question but rewriting into the same language (i.e. C++ to C++ then LLVM) can make debugging much simpler and implementing features and specific optimizations much more feasible if you don't have control over the backend. IR's should be terse, simple and dumb. I'm not sure any "real" programming language fits that.

ufo 7y ago

In practice I think it is hard to beat C in this regard. You can go pretty far if you are willing adapt to its quirks! And while C doesn't always allow for the best optimization (such as returning multiple values via registers), the workarounds often are still pretty fast. On a more theoretical level there has been some research on what a better intermediate language would look like. One project I found interesting was Mu VM, which offers some niceties for compiling languages with a garbage collector. https://microvm.github.io/ https://microvm.github.io/