Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!ub!uhura.cc.rochester.edu!rochester!pt.cs.cmu.edu!dsl.pitt.edu!pitt!willett!ForthNet
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: FORTH FOR 8-bit COMMODORE
Message-ID: <1782.UUL1.3#5129@willett.pgh.pa.us>
Date: 22 Sep 90 03:35:12 GMT
Organization: String, Scotch tape, and Paperclips.  (in Pgh, PA)
Lines: 27


 Date: 09-20-90 (10:42)              Number: 3809 (Echo)
   To: ALL                           Refer#: NONE
 From: CHARLIE HITSELBERGER            Read: (N/A)
 Subj: BLAZIN' FORTH FOR 64/128      Status: PUBLIC MESSAGE

 Ok, I've gotten together all of the source for Scott Ballantyne's PD
 compiler for the 64 and now it is time to make a few changes.  I've
 added in some rudimentary support for the RAM expansion and the 1581
 3.5" disk drive, but it sits on top of the dictionary instead of being
 imbedded in where the block i/o gets done.  Soon, soon..

 Anyway, I was thinking of doing something major league to the
 dictionary.  It is a linked list that traces back through the two byte
 pointers all the way to the last word.  The bigger the dictionary gets,
 the longer the average search takes.  This slows down compiles.  What if
 the FIND word were to Xor together all of the bytes of the word being
 searched for, then Xor the two nybbles of that, to get out a four-bit
 hash key.  Then it starts in that "thread" and searches backwards.  The
 hashing algorithm is very simple and could be easily implemented as a
 code word.  Anybody out there have any thoughts on this?  I know it is
 for the lowly 64, but the technique is generally applicable.

 Charlie
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp