Compiler Design

Started by
14 comments, last by flangazor 19 years, 5 months ago
I'm currently making compiler, and I am wondering, which language to I compile to? I've been wondering whether I should compile directly to machine code, assembly code, or something portable like C/C++. I can't decide whether to trade off speed for portability or vice versa. Any comments to sway me in either/both directions would be appreciated.
Advertisement
Compiling to C:
Benefits: portable; easier to debug through output examination; FFI shouldn't be dificult and can use C libraries in the code (e.g. GMP for bignums).
Problems: limited to C way of doing things (call/cc and anonymous functions may be irritating to implement)

Compiling to Lisp or Scheme:
Benefits: Powerful abstraction to transmute the code into just about anything else using macros; lots of powerful features exist (bignums, call/cc, macros). Portability between machines within a single Lisp platform is easy. Very easy to debug compiler output.
Problems: Seems esoteric and inconsistent FFI between different implementations. Portability between Lisp platforms may be difficult. Good chance that you don't even know Lisp or Scheme.

Compiling to Assembly:
Benefits: Powerful in the sense that you can do anything you like with your registers or memory.
Problems: Not portable. Not well optimized unless you limit your language to allow for optimizations that the 30 years of C compiler optimizations have missed out on. Labour intensive. Hard to debug.

Variants on Assembly:
Java Byte Code: Like Assembly but more portable and rich API.
MSIL: Like Assembly but useable with .Net which has a rich API and is somewhat portable (depending on your faith in Mono/Rotor/.Gnu.

Compiling to Machine code:
Benefits: None.
Problems: Waste of time; use assembly if you think you would like "down to the metal" approach.

How many machines do you use? Who do you want to help you with this project? What is the goal of the project?
Err, I don't see how anyone can answer that when we don't know why you're making a compiler. :D

Is it just to learn how it works? Or to be able to compile programs written in your cool homemade language? Or to compete with GCC?

Normally, you make a compiler because you want to get your code from language A to language B. Asking what language to compile to doesn't really make much sense as far as I can see... :)
Without having a better idea of your objectives, writing a front-end for gcc might be a better approach. This gives you the portability of gcc and minimizes the amount of work you need to do to produce a rather high quality compiler. It lets you focus on your language rather than on the mechanics of compiling code.

- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
If you are doing it to learn, you should compile it to your own intermediate language that is similar to an assembly language. Then, should you decide to design another new language, you will be able to keep half of your old code and only need to write new scanners and parsers for it. Everything else will remain pretty much unchanged.
Lucas Henekswww.ionforge.com
Quote:Original post by flangazor
Variants on Assembly:
Java Byte Code: Like Assembly but more portable and rich API.
MSIL: Like Assembly but useable with .Net which has a rich API and is somewhat portable (depending on your faith in Mono/Rotor/.Gnu.


You could also invent your own VM :) (No really good reason to, though, of course - except maybe if your language is really special purpose and/or not Turing-complete, in which case maybe you can cook up something more efficient.)

Of course, as the other posters said, it depends on what you're trying to get out of this. :)
Yes. Various VM bytecodes have been mentioned here.
Thanks, everyone. I've decided to go with compiling through C++ at the moment, with the option of compiling to assembly or some other low level language added later.

It's a Befunge compiler. No! stop. Don't run away yet..

Quote:
Original post by Spoonster:
Is it just to learn how it works? Or to be able to compile programs written in your cool homemade language? Or to compete with GCC?

It's a mixture of the first two. I would like to learn more about all aspects of compilers, so I figure I should take it one step at a time and learn different aspects of compiling at different times. That's another reason why I should compile to a high level language at the moment.

I was considering assembly for the optimisation, mainly because I can do what I want, and since Befunge is such a weird language, I suspect it could be optimised quite well.

Quote:
Original post by Spoonster
Normally, you make a compiler because you want to get your code from language A to language B.

Language A is Befunge, Language B is machine code. I'm just asking which intermediate compilation steps I should take.

Quote:
Original post by Zahlman
You could also invent your own VM :) (No really good reason to, though, of course - except maybe if your language is really special purpose and/or not Turing-complete, in which case maybe you can cook up something more efficient.)

Funny you should mention that.. I had thought of making Fungenix, a unix-type kernel with a 2D virtual machine. Can't really think how that could possibly work though.

Befunge is Turing complete, and most definately special purpose..
looking at Befunge, a gammaplex compiler would be cool
http://www.student.kuleuven.ac.be/~m0216922/gammaplex/Manual.html
I've made the compiler. It compiles to C++. Currently it doesn't optimize the code much, unless the code is not self modifying in which case the instructions can be hard coded.
The output code is messy, but cool. Full of GOTOs.

Gammaplex...
Who invented this?
I can see Tron3k on the gammaplex tag-board.

Anyway, I think I'll stick to Befunge for the moment.

Someday, I'll get round to making a Befunge-98 compiler/interpreter, and Befunge-98 is extremely cool. (Currently it's Befunge-93).

I don't know if this makes me insane, or just stupid... But I'm planning a Befunge-to-Intercal compiler... Possibly even TriIntercal or QuadIntercal, or Pe... You get the idea.

This topic is closed to new replies.

Advertisement