C as a Portable Intermediate Language | Hacker News Reader

C as a Portable Intermediate Language

cybertiggyr.com

38 pointsgnosis14 comments

He might have considered citing any of the myriad academic projects that did exactly this (the brain-dead obvious cite would be Cfront and ObjC, but there are better examples in the literature).

One of the reasons this approach isn't more popular is that it limits what you can do at runtime in ways a virtual machine doesn't; C (and the basic blocks emitted by a C compiler) are very hard† to work with, whereas VM instructions almost by definition aren't.

† But not impossible; see, for instance, Dynamo/RIO.

To be fair, Objective-C doesn't use C as an intermediate language, it actually is a strict superset of C, and only the objc calls end up being "translated" to C for the runtime to execute.

Nowadays, and the last 2.5 decades, yes, but originally it used to use C as an intermediate language.

> but there are better examples in the literature

For quite a long time, GHC's main codegen backend was via C.

Pretty light on information.

For a better, somewhat Scheme-specific intro, check out http://matt.might.net/articles/compiling-scheme-to-c/ .

For an ML-flavored one, "No Assembly Required: Compiling Standard ML to C" by Tarditi et al (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.7...), and its bibliography.

That's it. There's no magic. You compile L to native code via C.

This is how Squeak is portable across so many different platforms. (Altered to suit a dynamic language.) The VM is implemented in a statically-compiled Smalltalk subset which is emitted as C. I understand that Rubinius uses this trick as well.

GHC (Haskell) compiles to a Haskell program modelling C--, a subset of C. From there, it is rendered as actual C and compiled using GCC.

I believe there's more recently an option involving LLVM, though I'm not sure if this replaces the C-- step or is an alternative to GCC.

Man, it is really hard to google for '-f-via-c.'

I believe that it has been deprecated now that the LLVM backend is more mature. I'm not 100% sure, though.

EDIT: found it! http://www.haskell.org/ghc/docs/7.0.1/html/users_guide/relea... (in the 1.5.6 section)

> The registerised via-C backend, and the -fvia-C flag, have been deprecated. The poor floating-point performance in the x86 native code generator has now been fixed, so we don't believe there is still any reason to use the via-C backend.

-fvia-c was not the main mode of operation even in 6.x, it had an NCG long before the LLVM backend.

C-- isn't a strict subset of C; it changes a lot, but it takes the idea of a C subset as its starting point and then makes a wide swath of changes as needed. It's also designed to be non-portable (apparently to make sure that architecture-dependent optimizations can be performed if necessary), although from my limited experience with the specification I doubt it'd be hard to write semi-portable C-- and modify it as necessary at the loss of some optimizations.

This article seems out of date given the existence of llvm.

Out of date not just as a suggestion, but in the very specific sense that it was exactly what people did before LLVM and co.

Article is from 2002, updated 2006.

Doesn't HIPHOP use this approach though?

A similar one, it compiles down to C++.

Reply on news.ycombinator.com