eliot@cs.qmw.ac.uk (Eliot Miranda) (07/19/90)
In article <24942@estelle.udel.EDU> new@ee.udel.edu (Darren New) writes: > >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. Xo 5-9 seems far too much overhead X8-) Xo A fast direct threaded "interpreter" can be implemented by putting an indirect jump at the end of each threaded opcode routine instead of a return/call pair. That's what I've done. On the mc68k its 2 instructions on sparc its three. I suspect that on a pdp-11 its 1. See "An Architectural Trail to Threaded-Code Systems" by P.M. Kogge in Computer, March 1982. > >> 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. Yes, but I have to rewrite ONLY 12 lines. Increasingly, C compilers are providing support for global registers. GCC does, the Amsterdam comany ACE's compiler does. Acorn's ARM C compiler does. > >> 1 line defines JUMPNEXT (as above) with an asm statement. > >Which also must be rewritten. So far I have to rewrite 13 lines per architecture/compiler/assembler tuple. This is at least two orders of magnitude less than the ammount of graphics & input related code that needs top be rewritten. > >> 42 lines of sed-script in 3 files >> 9 lines strip prolog/epilog from threaded opcodes > >Which are not there in assembler. In assembler I have to rewrite at least all my macros; much more work. >> 5 lines do a peephole optimization > >Which undoubtably change from CPU to CPU and which does not need >to be done in assembler. And are optional (as are all optimizations). > >> 28 lines restore a global register stomped on by .div & .rem >And this is being done in SED? Much quicker than awk :-) >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. My points are that a) the 20000 lines in C are much easier to write,port,maintain & understand than the equivalent amount of assembler. b) the speed you might have gained from using assembler can be had in C if you use the right tools. The scheme can be simple and portable. > 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 Hmm. I must admit the 6502 + DOS pair doesn't turn me on either. -- Eliot Miranda email: eliot@cs.qmw.ac.uk Dept of Computer Science Tel: 071 975 5220 (+44 71 975 5220) Queen Mary Westfield College ARPA: eliot%cs.qmw.ac.uk@nsfnet-relay.ac.uk Mile End Road UUCP: eliot@qmw-cs.uucp LONDON E1 4NS