28 Feb
2000
28 Feb
'00
10:40 a.m.
On February 28, Shawn T. Rutledge wrote:
Do they still have performance advantages over less
specialized systems?
What kind of hardware modifications would optimize execution of Lisp?
Hmm...what processor instructions might one create to deal with a
language with more parens than actual code? ;)
-Dave McGuire
28 Feb
28 Feb
11:25 a.m.
On Mon, Feb 28, 2000 at 07:40:43PM -0500, Dave McGuire wrote:
On February 28, Shawn T. Rutledge wrote:
I doubt that is an issue... I've never written a lisp interpreter (wish
I'd had one of those CS classes where they do that) but I'd guess the
ASCII source code gets tokenized into some kind of tree structure which
is probably interpreted by doing a tree traversal, so the parens are all
gone by that point (they just tell it how to build the tree). But I can't
think of any hardware optimizations that help with trees, other than the
concept of a "stack", which is hardly a new one. Evidently there are some
though.
--
_______ http://www.bigfoot.com/~ecloud
(_ | |_) ecloud(a)bigfoot.com finger rutledge(a)cx47646-a.phnx1.az.home.com
__) | | \__________________________________________________________________
Join the ProcessTree Network: For-pay Internet distributed processing.
http://www.ProcessTree.com/?sponsor=5903
Do they still have performance advantages over
less specialized systems?
What kind of hardware modifications would optimize execution of Lisp?
Hmm...what processor instructions might one create to deal with a
language with more parens than actual code? ;) 
29 Feb
29 Feb
10:01 a.m.
One thing you can do to optimize a tokenizing interpreter is to
precalculate and store the goto and gosub destination and return
addresses. This way the interpreter does not have to start at line 0
searching sequentially through the tree for the destination for a gosub
but will just go there directly. Of course calculated destinations (ie:
10 if x then gosub x+x+1) totally ruin this system for that line of code.
Basic XE and Basic XL from OSS used this feature in thier "FAST" command
(a sort of post-tokenized address precompiler) to boost performance. --
-----------------------------------------------------------
Jeffrey S. Worley
Technical Services
Bits & Bytes Computer Services Inc.
1979B Hendersonville Road
Asheville, NC 28803
828-684-8953 - voice 0900-1700 five days
828-687-9284 - 24hr fax
Who is General Failure and why is he reading my hard disk?
Technoid(a)Cheta.net
-----------------------------------------------------------
9063
days inactive
9064
days old
2 comments
3 participants
participants (3)
-
mcguire＠neurotica.com -
rutledge＠cx47646-a.phnx1.az.home.com -
Technoid＠cheta.net