C as an intermediate language (2012) • Hacker News Board

Re: C as an intermediate language (2012)

#11

Post by limmeau » Wed, Jul 17, 2013, 1:14 PM UTC

lmm wrote: post #10

octo_t wrote: post #3

There's a lot of extra stuff you get with targeting C: being able to write the run time in C very easily. For example its a lot easier to write your entire OO system in C in a few hundred lines, and keeping that easily debuggable is a massive time saver.

Wouldn't that be even easier if you used LLVM IR, as you'd then be able to write your runtime in any language that LLVM supports?

Advantage of writing it in C: You can prototype an example client of your runtime in C before your code generator is working.

Re: C as an intermediate language (2012)

#12

Post by lmm » Wed, Jul 17, 2013, 1:25 PM UTC

limmeau wrote: post #11

lmm wrote: post #10

Earlier quoted context omitted.

Wouldn't that be even easier if you used LLVM IR, as you'd then be able to write your runtime in any language that LLVM supports?

Advantage of writing it in C: You can prototype an example client of your runtime in C before your code generator is working.

Again, why couldn't you do that with LLVM IR?

Re: C as an intermediate language (2012)

#13

Post by tikhonj » Wed, Jul 17, 2013, 1:38 PM UTC

If you want to use C as intermediate language, you may be interested in the CIL project[1]. It stands for "C intermediate language"--might be relevant :P.

Fundamentally, CIL is a nice subset of C wrapped up into a nicely usable API. The idea is to shave off as many of C's inconsistent sharp edges as possible. You won't have to worry about quirks in the syntax or odd behavior because you have a nice high-level, curated API for generating C code.

It's designed to have a clean semantics, and semantics are very important. (Or so I maintain.)

[1]: http://www.cs.berkeley.edu/~necula/cil/

Re: C as an intermediate language (2012)

#14

Post by __alexs » Wed, Jul 17, 2013, 1:56 PM UTC

lmm wrote: post #10

octo_t wrote: post #3

There's a lot of extra stuff you get with targeting C: being able to write the run time in C very easily. For example its a lot easier to write your entire OO system in C in a few hundred lines, and keeping that easily debuggable is a massive time saver.

Wouldn't that be even easier if you used LLVM IR, as you'd then be able to write your runtime in any language that LLVM supports?

In C you can write you run-time in any language that C can link to. Which is rather a lot of languages, and isn't tied to any particular compiler.

Re: C as an intermediate language (2012)

#15

Post by Roboprog » Wed, Jul 17, 2013, 1:57 PM UTC

I worked at a company ("Morada Corp") in the early 90s that did just that for ... RPG II!

We took the code from IBM minicomputers and compiled it into C on many, many platforms (back when there were a few more unices, as well as OS/2 and VAX/VMS kicking around).

I only did a little maintenance on the compiler front end checker, though. I mostly worked on some supplemental tokenizers/runtimes for data file browser language and a DB/form DDL.

Anyway, GCC made a nice target to hit a large number of systems. (alas, Borland C on DOS at the time tended to choke on larger generated subroutines, being 16 bit w/out "huge" pointer support and all)

Re: C as an intermediate language (2012)

#16

Post by luikore » Wed, Jul 17, 2013, 2:00 PM UTC

lmm wrote: post #12

limmeau wrote: post #11

Earlier quoted context omitted.

Advantage of writing it in C: You can prototype an example client of your runtime in C before your code generator is working.

Again, why couldn't you do that with LLVM IR?

LLVM IR is designed for machine, not human, it's too verbose, and requires SSA form. A normal person can't easily reason the logic in such verbose language. Plus people are more familiar with C.

Re: C as an intermediate language (2012)

#17

Post by Roboprog » Wed, Jul 17, 2013, 2:26 PM UTC

pjmlp wrote: post #2

For anyone wanting to read about C as intermediate language, Compiler Design in C (1990) http://www.amazon.com/Compiler-Design-C-Prentice-Hall-softwa... EDIT: Adding some extra remarks I think might also be interesting to share. Another approach, that I really like, is to output bytecodes that are mapped directly to macros in typical macro assemblers like NASM/MASM/TASM. Those macro assemblers provide very powerful m…

C: AKA "portable assembler" :-)

Re: C as an intermediate language (2012)

#18

Post by chalst » Wed, Jul 17, 2013, 2:52 PM UTC

An intermediate language (or representation) is the internal representation of code used for program transformation and reasoning about the code. This is not what the story is talking about - all the benefits are about the object representation (the compiler emits C code), and the presented compiler does not distinguish between the intermediate representation and the object representation; it does not need to, as it does no optimisations. There's nothing innovative about emitting C code from a compiler - it used to be more common than it is now.

There has been a little bit of research done on writing optimising compilers that use source-code-like intermediate representations: the Janus project from the 1990s springs to mind.

Re: C as an intermediate language (2012)

#19

Post by lmm » Wed, Jul 17, 2013, 3:02 PM UTC

luikore wrote: post #16

lmm wrote: post #12

Earlier quoted context omitted.

Again, why couldn't you do that with LLVM IR?

LLVM IR is designed for machine, not human, it's too verbose, and requires SSA form. A normal person can't easily reason the logic in such verbose language. Plus people are more familiar with C.

Sure, but you can write your runtime test code in C - or any other language with an LLVM compiler.

Re: C as an intermediate language (2012)

#20

Post by rayiner » Wed, Jul 17, 2013, 3:03 PM UTC

lmm wrote: post #10

octo_t wrote: post #3

There's a lot of extra stuff you get with targeting C: being able to write the run time in C very easily. For example its a lot easier to write your entire OO system in C in a few hundred lines, and keeping that easily debuggable is a massive time saver.

Wouldn't that be even easier if you used LLVM IR, as you'd then be able to write your runtime in any language that LLVM supports?

You lose a lot of things the C compiler does for you by targeting LLVM directly. A big one is debug info. The C compiler will emit debug information for you, and with some line directives, as shown in the article, or maybe scripts, you can get minimally usable source-level debugging without having to generate your own debug info.