Re: Is Assembler Language essential in compiler construction?

"Bartc" <bartc@freeuk.com> writes:


> I've tried targetting C and it was completely unsatisfactory.


Hmmm, as a professional compiler writer, I would have to say my mileage
varied. I've worked on compilers that have 1) targeted real hardware
(either with or without assembly language), 2) targeted idealized VMs,
and 3) targeted C.


Each one has there strengths, but if I were writing a new compiler I
would either target a well-known VM like the JVM or C as first choice.
Inside, I would probably use my own IL (intermediate language) to
describe semantics in a convenient way for my language, but I wouldn't
go directly from that to a machine specific description unless
low-level optimization was important. However, stylized-C is a pretty
good assembly language.


The most recent compiler I wrote is a case in point. We translated
Verilog into an internal IL, worked on that, and output C/C++ code
that we handed to both Microsoft and Gnu. The first cut performance
was sufficient tht we never considered low-level issues. We instead
spent our time optimizing hard things that were Verilog specific where
we could get 10x rather than 10% kind of speedups.


> First, there are a number of extra hoops to jump through in order to
> generate C source code (syntax, formatting, creating suitable names
> when your language uses namespaces perhaps).


If you are spending your time formatting, you are misusing C as an
assmebly language. As for suitable names, you have to have names in
assembly language too, use the same ones. You shouldn't spend much
time reading that C, nor should anyone else.


> Then, to implement certain features of your language might involve
> using casting and other tricks in the generated C when it's datatypes,
> and using a lot of gotos and labels when it's syntax.


Just use the same types and control structures you would use at
assembly level. You are using C, only so you don't have to deal with
certain low-level details that may vary from machine to machine. A
world where all computers are the VAX (to borrow an old saying).


> Then you make the discovery that you can use casting and gotos for
> nearly *all* your language constructs, meaning most features of C are
> not needed: typedefs, control statements, even types: char arrays will
> do nicely; in fact probably a single char array at each scope level
> would work, so not even variables are needed!. Functions are still
> needed, but only just.


Yes, so what? It is still a simple world, and that's the point. C is
a simpler language than most assemblers with less warts and wrinkles.
If your world looks like a char (byte) array, that's nice. Mine looks
like a bunch of "word sized" integers, same difference.


> So you end up with a target language which is a travesty of C, and
> while it might be portable, won't compile to great code because the
> structure the C compiler depends on is missing. (And there's the
> headache of converting errors/line numbers in C source back to your
> original code.)


Not a travesty of C, real honest pure, C is the world's assembler, C.
You don't expect "great code" out of the compiler, you may even have
turned the optimizer off because your 4MB in a single C source file
stresses the n**2 algorithms therein and five-hour compile times are
too long. Competent code will get you quite far and the compiler your
are using as a base probably has more low-level tricks implemented
than you could have in a resonable period of time.


You don't expect errors in the C source and try to relate them back to
the users code. You wouldn't report internal assembly language errors
(as user errors) either--those are bugs in your compiler. However, a
few #line directives go a long way in getting the code to line up in
an approximate way for the cases where you are still debugging the
compiler.


Unless you are working on an established product, time-to-market for
something reaonable is everything. You can get a lot better compiler
a lot faster and easier if you target C or the JVM or something
simliar where you've left the "hard" part to someone else, someone who
has already done that work in advance.


Just my opinions,
-Chris


******************************************************************************
Chris Clark Internet: christopher.f.clark@compiler-resources.com
Compiler Resources, Inc. or: compres@world.std.com
23 Bailey Rd Web Site: http://world.std.com/~compres
Berlin, MA 01503 voice: (508) 435-5016
USA fax: (978) 838-0263 (24 hours)
------------------------------------------------------------------------------

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