Re: Compiler Construction - New to it and getting started.

torbenm@app-4.diku.dk (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
28 Feb 2005 19:47:47 -0500

          From comp.compilers

Related articles
Compiler Construction - New to it and getting started. NatLWalker@gmail.com (Nate the Capricious) (2005-02-11)
Re: Compiler Construction - New to it and getting started. napi@cs.indiana.edu (2005-02-12)
Re: Compiler Construction - New to it and getting started. torbenm@diku.dk (2005-02-16)
Re: Compiler Construction - New to it and getting started. touati@nospam-prism.uvsq.fr (TOUATI Sid) (2005-02-28)
Re: Compiler Construction - New to it and getting started. torbenm@app-4.diku.dk (2005-02-28)
Re: Compiler Construction - New to it and getting started. touati@prism.uvsq.fr (TOUATI Sid) (2005-03-01)
| List of all articles for this month |

From: torbenm@app-4.diku.dk (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
Newsgroups: comp.compilers
Date: 28 Feb 2005 19:47:47 -0500
Organization: Department of Computer Science, University of Copenhagen
References: 05-02-039 05-02-068 05-02-099
Keywords: optimize, courses
Posted-Date: 28 Feb 2005 19:47:47 EST

TOUATI Sid <touati@nospam-prism.uvsq.fr> writes:


> I would suggest Ocaml as a programming language for a clean compiler.
> But, if the compiler would do some backend or advanced code
> optimization, I think that Ocaml wouldn't be the best choice.
>
> As I tell to my students, compilation can be seen as a formal work
> when doing simple parsing&semantic analysis&simple code generation.
> Unfortunately, many code optimization techniques in the litterature
> are completely ad-hoc, and no formal description/model can be easily
> used. Such ad-hoc techniques require to "hack" a compiler or to use
> some "C" programming inside the compiler. While this is not the best
> thing for a compiler, this is actually the situation of (maybe) almost
> all optimizing compilers.


I don't agree. First of all, most optimization techniques are
formalized in some way (data-flow analysis, control-flow analysis,
pattern recognition, etc.) and, secondly, OCaml or SML can be used to
write ad-hoc code as well as C can. I would actually say they are even
better at this than C, as you don't have to worry so much about memory
allocation/deallocation in the compiler and you can often write fairly
advanced transformations as quick hacks by using pattern matching or
standard higher-order functions such as fold and map.


Where C may be a better option than OCaml or SML is bytecode
interpreters. Here, you may want to do bit-fiddling and stuff where
you treat the same data sometimes as pointers and sometimes as
integers. This is where C's lack of type enforcement can come in
handy.


                Torben


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.