5 ms·

I would be more interested in learning how to write a transpiler... As long as I can compile a language in C, it removes a lot of work.

by jokoon 9y ago

pjmlp 9y ago
That is just a compiler whose backend generates code in another language instead of machine code.
- jokoon 9y ago
  Well I find it more interesting... Also C compilers can do a lot of micro optimizations that are not trivial, so compiling something to C or maybe LLIR seems like a better choice.
  - pjmlp 9y ago
    That is usually a fallacy, that only looks simple as first step. The first issue is the impedance mismatch between the original language semantics and what is possible to represent in C. Two examples are tail calls and continuations, that are hard to get right at C level, either requiring compiler extensions, longjmp/setjmp tricks, or a little bit of assembly. Then there is the whole issue with undefined behaviour in C, introducing bugs that didn't exist on the original code. Even if the generated code is clean today regarding UB, you cannot ensure that a new C compiler version won't be introducing such issues. Having said this, there are languages like Eiffel and Nim, whose main backend relies on C compilers, instead of compiling directly to pure native code. Skipping Objective-C and C++ here, because although they started as C pre-processors, their code was to be an extension to C and so their semantics also imply C semantics. Compiling to some kind of IR, like LLIR is more sane. Then you can do whatever you want with it, generate code in another programming language, machine code, or a plain interpreter for bootstrapping purposes.
    - zakk 9y ago
      I agree with most of your points, but... > Even if the generated code is clean today regarding UB, you cannot ensure that a new C compiler version won't be introducing such issues. This is not correct. Undefined behaviour is specified in the standard, and a good compiler-to-C will always generate UB-free code.
      - pjmlp 9y ago
        The standard specifies all known cases, the list is not exhaustive from all possible C implementations.
        zakk 9y ago
        I am sorry but I don't understand... The standard specifies what is UB, and the implementations must behave accordingly to be standard-compliant. If your code avoids UB behavior as specified by the standard it will run in the same way when compiled with any standard-compliant compiler.
        pjmlp 9y ago
        Compiler optimization is a tricky business, where every vendor does all they can to beat the benchmarks game. What gets documented on the standard is what compiler vendors that bother to seat at ANSI C meetings agree to document as such. By no means does the standard forbid compiler vendors to take advantage of situations not yet documented as such. Eventually new cases of UB might get added to the standard. The current set of about 200 scenarios of UB in C11 weren't all there in C89. Another example, is that you can have code that is perfectly valid, UB free, but thanks to PGO and code re-writting rules on the optimizer stage, gets rewritten with UB side effects at a later stage in the optimizer pipeline.

I would be more interested in learning how to write a transpiler... As long as I can compile a language in C, it removes a lot of work.

by jokoon 9y ago

I would be more interested in learning how to write a transpiler... As long as I can compile a language in C, it removes a lot of work.

pjmlp 9y ago

That is just a compiler whose backend generates code in another language instead of machine code.

jokoon 9y ago
Well I find it more interesting... Also C compilers can do a lot of micro optimizations that are not trivial, so compiling something to C or maybe LLIR seems like a better choice.
- pjmlp 9y ago
  That is usually a fallacy, that only looks simple as first step. The first issue is the impedance mismatch between the original language semantics and what is possible to represent in C. Two examples are tail calls and continuations, that are hard to get right at C level, either requiring compiler extensions, longjmp/setjmp tricks, or a little bit of assembly. Then there is the whole issue with undefined behaviour in C, introducing bugs that didn't exist on the original code. Even if the generated code is clean today regarding UB, you cannot ensure that a new C compiler version won't be introducing such issues. Having said this, there are languages like Eiffel and Nim, whose main backend relies on C compilers, instead of compiling directly to pure native code. Skipping Objective-C and C++ here, because although they started as C pre-processors, their code was to be an extension to C and so their semantics also imply C semantics. Compiling to some kind of IR, like LLIR is more sane. Then you can do whatever you want with it, generate code in another programming language, machine code, or a plain interpreter for bootstrapping purposes.
  - zakk 9y ago
    I agree with most of your points, but... > Even if the generated code is clean today regarding UB, you cannot ensure that a new C compiler version won't be introducing such issues. This is not correct. Undefined behaviour is specified in the standard, and a good compiler-to-C will always generate UB-free code.
    - pjmlp 9y ago
      The standard specifies all known cases, the list is not exhaustive from all possible C implementations.
      - zakk 9y ago
        I am sorry but I don't understand... The standard specifies what is UB, and the implementations must behave accordingly to be standard-compliant. If your code avoids UB behavior as specified by the standard it will run in the same way when compiled with any standard-compliant compiler.
        pjmlp 9y ago
        Compiler optimization is a tricky business, where every vendor does all they can to beat the benchmarks game. What gets documented on the standard is what compiler vendors that bother to seat at ANSI C meetings agree to document as such. By no means does the standard forbid compiler vendors to take advantage of situations not yet documented as such. Eventually new cases of UB might get added to the standard. The current set of about 200 scenarios of UB in C11 weren't all there in C89. Another example, is that you can have code that is perfectly valid, UB free, but thanks to PGO and code re-writting rules on the optimizer stage, gets rewritten with UB side effects at a later stage in the optimizer pipeline.