Cross Compiling vs Virtual Machines

Question

Clarification

When I mention cross compiling I mean from one language to another (think GWT), rather than from a host platform to a targeted platform.

Background

I am developing an Arabic programming language which I cross compiled to Java, this saved me the platform specific hassles. Now I had to put this on hold and turned to cross compiling to C for various reasons.

I want to develop a single library that would be replaced with an equivalent library of the system it's running on when compiled.

For example, if the programmer writes a GUI drawing function in the Arabic programming language and compiles, it would be cross compiled to win32 code if compiled under Windows, GTK+ under Gnome, Qt under KDE, etc. The same approach will be used for other libraries as well.

Question

Is it worth going through all this trouble to end up with a compiled executable or am I better off with a Virtual Machine approach? Advantages and disadvantages of picking either (from the language developer perspective rather than the programmer using the language)? Are there any other factors I have to consider?

Any reference links for further reading would be greatly appreciated :)

Answer 1

You should cross-compile to the language that best supports the assumptions and ideas underlying your language. If your language is garbage collected, all function calls are method calls, and doesn't let you work with addresses as data, then Java is the language to be compiling to.

There are compilers that compile Java code to native. So if you want your program to run natively, you can use those.

When you are ready to make your own full compiler for your language, then you can divorce yourself from Java or whatever it is you choose.

This basic approach has been used by a number of languages. Usually the target language is C because you can do low-level stuff in C that you can't do in any other language, it has mature optimizing compilers, and runs very fast natively. The way C's symbols, libraries and calling conventions work is also well understood and tends to be a rigorously defined and supported by several languages on any given platform. This allows the new language to have immediate access to a whole host of libraries written for C.

C++ started this way (the original compiler was called cfront), and I believe OCaml started this way too. I think if you dig a little you can find numerous other languages for which this is true.

But if you don't need Cs low-level features a lot of those arguments apply to Java as well. A number of newer languages (Scala, for example) use the JVM in this way.

Answer 2

I like @Omnifarious answer but I would emphasise instead that you must consider what tradeoffs you want to make. If you want high performance you may choose to cross compile to C or C++, if you want availability of libraries, again C or C++ is a decent choice. If you want language interoperability you might go with LLVM assembler, or JVM or .NET assembler.

So now, your actual question is: should you make the backend pluggable? I have to warn you that this is really really really hard to do. Lets look at some products that actually do it: the examplar is of course gcc. It is designed to support not only a wide range of input languages, but also generate code for a wide range of target CPUs: you can regard it is a cross compiler that generates various assembler languages.

The secret to making the back end pluggable is a suitable intermediate language which is simple enough to translate your input language to, and simple enough to translate into various back end languages, yet be strong enough to encode the input.

Basically the problem is: if you make your IL too abstract it locks in too much of your assumptions can can't be easily changed. If you make it too concrete it is too hard to translate to multiple back ends.

So I think you should consider doing this if, and only if, you have at least three potential back end target languages to act as use-cases to guide your design of the IL.