Path: utzoo!attcan!uunet!wuarchive!udel!new
From: new@udel.EDU (Darren New)
Newsgroups: comp.arch
Subject: Re: It looks like he's at it again!
Message-ID: <24942@estelle.udel.EDU>
Date: 18 Jul 90 14:44:01 GMT
References: <2328@l.cc.purdue.edu> <1990Jul10.072443.4844@cs.UAlberta.CA> <37569@ucbvax.BERKELEY.EDU> <2358@l.cc.purdue.edu> <2518@sequent.cs.qmw.ac.uk>
Reply-To: new@ee.udel.edu (Darren New)
Organization: University of Delaware
Lines: 48

In article <2518@sequent.cs.qmw.ac.uk> eliot@cs.qmw.ac.uk (Eliot Miranda) writes:

[about how to define ASM macros and a sed script to mung the asm output from
 the GCC compiler full of inline assembler directives to make a threaded interpreter
 in C instead of ASM]

>The resulting system is as efficient a threaded code interpreter as one
>written entirely in assembler BUT
>On the sparc
>	The system is about 20,000 lines (including comments)
>	All but 13 lines are ordinary C code.

I would like to point out that the threaded interpreter of most forth-like
languages is on the order of 5-9 instructions on even simple CPUs.

>	12 lines are gcc-style global register variable declarations and

This is where C falls down.  If you use ANSI C instead of GCC, it gets
really inefficient. Also, these 12 lines have to get rewritten for
every CPU anyway, so it's not like it's portable anyway.

>	1 line defines JUMPNEXT (as above) with an asm statement.

Which also must be rewritten.

>	42 lines of sed-script in 3 files
>		9 lines strip prolog/epilog from threaded opcodes

Which are not there in assembler.

>		5 lines do a peephole optimization

Which undoubtably change from CPU to CPU and which does not need
to be done in assembler.

>		28 lines restore a global register stomped on by .div & .rem
And this is being done in SED?

Anyway, thanks for making my point so graphically. Clearly you are not
writing in C, but rather mostly C with assembler for the hard-in-C
parts. I never said that threaded interpreters were difficult in C, but
only the inner-interpreter part. Sure, the 20000 lines of routines are
in C and are probably even efficient. But doing something like a
reentrant threaded language on a 6502 under a DOS that fixes neither
upper nor lower bound of the memory is not something I would care to do
with GCC, SED, and so on.

			 -- Darren