[retroforth] Re: Reva 5.0.0.6 released
- From: "Ron Aaron" <ron@xxxxxxxxxxx>
- To: retroforth@xxxxxxxxxxxxx
- Date: Fri, 28 Jan 2005 16:06:15 -0800 (PST)
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?
--
My GPG public key is at http://ronware.org/
fingerprint: 8130 734C 69A3 6542 0853 CB42 3ECF 9259 AD29 415D
Other related posts:
