Path: utzoo!attcan!uunet!willett!ForthNet
From: ForthNet@willett.UUCP (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Forth Engines / Harris
Message-ID: <1047.UUL1.3#5129@willett.UUCP>
Date: 1 Jun 90 03:45:19 GMT
Organization: Latest link in the ForthNet chain.  (Pgh, PA)
Lines: 51


 Date: 05-28-90 (03:39)              Number: 3290 (Echo)
   To: PETE KOZIAR                   Refer#: NONE
 From: JONAH THOMAS                    Read: NO
 Subj: N'S T'S AND G'S               Status: PUBLIC MESSAGE

   Yes, if you make the stack picture be the name of the Forth stack
 word, you do have the problem of remembering which words are present.
 I'd say that's potentially a problem with any Forth, if you switch back
 and forth much you won't remember whether NIP and TUCK are present.
   Different machines will prefer different primitives, sure.  But that
 comes with the territory.  You can optimise for one machine and still
 have code that can be emulated on another, slower.  The traditional
 wisdom is that there's no point trying to optimise Forth code for speed,
 because if you need speed you can code inner loops (or whatever needs to
 be fastest) in assembly.  That will get you more than piddling around
 with using ROT SWAP versus >R SWAP R> .  But what do you do with the
 RTX?  If you're going to optimise an inner loop, you're optimising it in
 Forth, more or less.
   But the RTX2000 isn't really a Forth machine.  It's just one of the
 closest things that's come along so far.  If you work it so the things
 you need bubble up on the stack just exactly when you need them, then
 they don't cost you anything at all in time.  But if what you need
 happens to get buried in the stack, it takes a lot longer to get it than
 it would to get it out of a variable.  The RTX doesn't optimise for
 Forth, it's its own thing, that happens to fit Forth pretty well.  But
 when you look at its primitives and explain them in Forth, some of them
 make no sense.  For example, there's a primitive that gets listed as
 SWAP DROP DUP @ SWAP .  What it does is simple, it gets the number at
 the TOS address, and puts that number in NOS, leaving TOS and SOS alone.
 Forth didn't include anything like that, because usually you'd rather
 have the number from memory on TOS where you can use it, and its old
 address just gets in the way.  But the RTX gives you the chance to add
 or subtract a number up to 32 from the address on TOS, still within the
 same 2 cycles!  So some memory operations get real efficient, you can
 get a bunch of fields from a record very quickly.
   Anyway, I figure if you need to optimise, why not get a language that
 makes it as easy as possible?  If you don't care about making it fast or
 small, you can always write sloppy.  If you do need tight fast code,
 it's easier if you know which words are primitives and how they fit
 together.  It isn't hard to make an optimising compiler if the
 programmer gives it easy jobs to do.
   The idea of making stack words look like their operations isn't new.
 Doneil Hoekman wrote an article about it in FD January, 1986.  He made a
 STACK word that interpreted a stack diagram on the spot.  It was slow
 but very flexible.

 NET/Mail : The MATRIX (5 Nodes/1.2 Gig) Birmingham, AL (205) 323-2016  
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu