On Fri, 28 Jan 2005 16:06:15 -0800 (PST), Ron Aaron <ron@xxxxxxxxxxx> wrote: > > On Fri, January 28, 2005 15:50, Chris Walton said: > > On Fri, 28 Jan 2005 09:55:33 -0800 (PST), Ron Aaron <ron@xxxxxxxxxxx > > > wrote: > >> On Fri, January 28, 2005 9:05, Helmar Wodtke said: > >> > >> > Well, very good. I want to explain what I mean with "self-reflective". > >> > >> Yes, for turnkey it's a good thing. > >> > >> I was going to add a field which says explicitly how big the word is so > >> that > >> 'see' could actually work correctly in all cases. > >> > >> > I use in HelFORTH a strategy that makes it possible to clone the FORTH > >> core in > >> > it's own segment. This is fine to play with :) You can start one system > >> that > >> > >> I need to do something like that for Reva... > >> > >> > I'm currently a little bit back from this idea. I used it some years ago > >> for a > >> > >> I was considering hashing. But the regular lookup is quite fast enough for > >> my > >> purposes. But when I have a 'real' app on Reva, then I will know if it's > >> fast > >> enough. > > > > It wouldnt be worth the effort, memory, or overhead, because you're > > never gonna have more than a few hundred of items in it anyway, > > compared to gforth or win32forth or quest32 that have thousands. > > Another possibility is to use an array of entries. Traversal then only > involves something like > mov edx, [ebx+4*ecx] > inside a loop (so ecx is decrememented automatically). Then each iteration is > looking at the previous entry in the array of entries. > > Hmm. That means the dictionary entries would look like: > dd xt > dd ptr-to-name > > and somewhere else > ptr-to-name: db len, name > > I wonder if this would be faster or more efficient than the linked list? It should be. Colorforth does it like this. > -- > My GPG public key is at http://ronware.org/ > fingerprint: 8130 734C 69A3 6542 0853 CB42 3ECF 9259 AD29 415D > > -- I F34R N0N3 F0R F0RTH SH4LL GUID3 M3