[Q] Multiple front ends, single back end...

Orlando Llanes <a010111t@bc.seflin.org>
31 Oct 2000 14:44:34 -0500

          From comp.compilers

Related articles
[Q] Multiple front ends, single back end... a010111t@bc.seflin.org (Orlando Llanes) (2000-10-31)
Re: [Q] Multiple front ends, single back end... smoleski@surakware.com (Sebastian Moleski) (2000-11-01)
Re: [Q] Multiple front ends, single back end... jparis11@home.com (Jean Pariseau) (2000-11-07)
| List of all articles for this month |
From: Orlando Llanes <a010111t@bc.seflin.org>
Newsgroups: comp.compilers
Date: 31 Oct 2000 14:44:34 -0500
Organization: Compilers Central
Keywords: UNCOL, design, comment
Posted-Date: 31 Oct 2000 14:44:34 EST

        I'm writing a script language and interpreter which will support
multiple front ends with a single back end. The primary intent is to
provide a language that can easily be typed and read. The secondary intent
is to create an interpreter that leaves a small footprint in memory. The
final intent is speed, both in parsing and execution.
        There are three ways to support multiple front ends; 1) writing
Lex/Yacc type tools, 2) OO/modular programming interface, and 3) writing
language translators.
        1) Lex/Yacc are good in theory, but they have a major learning curve.
Lex/Yacc tools also produce a lot of code which significantly increases
the size of the executeable. Also, programming these tools would be
extremely difficult (for me at least).
        2) OO/modular programming would define a base class that works on
anything that can be generalized. A scanner/parser/"compiler" would be in
one class, a symbol table in another (which would be used by the
compiler), and then a seperate class would function as the virtual
machine. The base scanner's behavior could be modified through a small
table (256 element array of character codes) and switches (4 to 6 Boolean
variables, or a "bit mapped" integer) rather than overriding code since
returning EOLN, strings, numbers, and identifiers are fairly consistant
across languages. With the exception of required functions for the VM and
maybe math expressions, parsing would be left up to the programmer. The
compiler would serve as a back end with functions to produce the VM
"executeable" (opcodes, data, etc).
        3) Writing a language translator means parsing another language and
converting it into the "native" language.


        Are there any other ways I haven't thought of to support multiple
front ends? What do you think of methods 2 and 3?


See ya!
Orlando Llanes
[I don't know of any easy way to write compiler front ends for nontrivial
languages. -John]


Post a followup to this message

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