Re: Compiler project needed

anton@mips.complang.tuwien.ac.at (Anton Ertl)
6 Mar 2000 00:26:02 -0500

          From comp.compilers

Related articles
[6 earlier articles]
Re: Compiler project needed sasulzer@seanet.com (Stephen Sulzer) (2000-02-23)
Re: Compiler project needed jkahrs@castor.atlas.de (Juergen Kahrs) (2000-02-23)
Re: Compiler project needed danwang+news@cs.princeton.edu (Daniel C. Wang) (2000-02-27)
Re: Compiler project needed dvdeug@x8b4e53cd.dhcp.okstate.edu (2000-02-27)
Re: Compiler project needed srineet@email.com (Srineet) (2000-02-27)
Re: Compiler project needed franck.pissotte@online.fr (Franck Pissotte) (2000-02-28)
Re: Compiler project needed anton@mips.complang.tuwien.ac.at (2000-03-06)
Re: Compiler project needed nr@labrador.eecs.harvard.edu (2000-03-06)
Re: Compiler project needed peter.r.wilson@boeing.com (Peter Wilson) (2000-03-06)
Re: Compiler project needed rkrayhawk@aol.com (2000-03-06)
Re: Compiler project needed escargo@mirage.skypoint.com (2000-03-06)
| List of all articles for this month |

From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.compilers
Date: 6 Mar 2000 00:26:02 -0500
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 00-02-112 00-02-122 00-02-132
Keywords: practice

  "Daniel C. Wang" <danwang+news@cs.princeton.edu> writes:
>I think, a better approach would be some sort of "runtime system/VM
>generator" which would take some sort of high-level description of a
>VM/runtime system and spit out ugly C code, which may for example take
>advantage of different architecture/OS features.
>
>Ideally, the input to the runtime system/VM generator would be
>something very close to an operational semantics for the bytecode,
>which could act also as a formal specification of the semantics of the
>language itself.


Well, Gforth (http://www.complang.tuwien.ac.at/forth/gforth/) has
something like this. It takes a specification of an instruction for a
stack-based VM, e.g.,


+ n1 n2 -- n core plus
n = n1+n2;


Here "+" is the Forth name of the VM instruction, "n1 n2 -- n" is the
stack effect, "core" and "plus" are mainly for documentation purposes
("plus" is also used as name in the generated C code, since "+" won't
do), and the rest is the operational semantics (actually a C code
fragment).


From this the generator (prims2x.fs) creates the following (ugly, as
required:-) C code:


I_plus: /* + ( n1 n2 -- n ) */
/* */
NAME("+")
{
DEF_CA
Cell n1;
Cell n2;
Cell n;
NEXT_P0;
n1 = (Cell) sp[1];
n2 = (Cell) TOS;
sp += 1;
{
#line 559 "/a5/anton/gforth/prim"
n = n1+n2;
}
NEXT_P1;
TOS = (Cell)n;
NEXT_P2;
}


And from this GCC generates a threaded-code interpreter that is pretty
close to optimal on most platforms.


The generator and the wrapper for the generated code is currently
specific to threaded code (and thus GCC) and Gforth (e.g., it
generates various type declarations depending on Forth conventions for
naming stack elements (in the example above, everything starting with
"n" is a "Cell"), but it should be easy to generalize.


- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html


Post a followup to this message

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