[retroforth] Re: RetroForth 8.0
- From: "Ron Aaron" <ron@xxxxxxxxxxx>
- To: retroforth@xxxxxxxxxxxxx
- Date: Sun, 16 Jan 2005 11:37:25 -0800 (PST)
On Sat, January 15, 2005 12:06, Charles Childers said:
> * Block editor (including load/save of a blockfile under Linux)
I was interested in something similar for Reva. Do you have code we can look
at?
> * "Classic" Forth interpreter
What does this mean, in practical terms?
> The block editor and block words play a major role in 8.0; TIB is a
> block, PAD is a block, and you get a word ("offset") that returns the
> address the block buffer starts at. (You could use the block words to
> load a file here and eval the region rather than deal with actual
> blocks if you like)
Are you staying with the "traditional" 1k blocks? Considering we only run on
PC hardware where the underlying sector size is 4k, it might be nice to do
something like:
4k real blocks; first 2000 characters (25x80) code, next 2000 characters
'shadow', final 96 bytes of administrative information (dirty status, time of
update, whatever). The downside is that 2000 bytes of shadow might be
excessive; and it is impossible to easily jettison for a 'turnkey' solution.
> I removed does> for various reasons; there's a replacement called "does" in
> 8.0:
>
> : (foo) 10 + ;
> : foo create literal, does (foo) ;
>
> This encourages factoring a bit more without sacrificing flexibility
> as far as I can tell.
It requires one to add an extra word for the purpose of implementing the
'does'. This will be slower than executing the inline code, won't it?
> Optomizations: should the core inline any words that don't have to be
> inlined? I can inline simple stack words like swap drop dup nip
> easily, but should that be part of the core?
Reva will be doing that; but Reva will also be dropping support for less than
Pentium chips...
> Colors: should colors be part of the core system, or a loadable option?
Loadable
> Blocks: These will be part of the 8.0 core.
> Files: These will not be part of the 8.0 core.
This is a unique choice, for a hosted system. For a standalone system I would
expect it; but don't you think users will want to access the underlying OS'es
files from time to time?
> The optomizations are an important issue:
> they make the kernel binary larger, but can yield significant speed
> increases (inlining just swap, drop, and nip makes 8.0 faster on FIB
> that the latest Reva release).
Reva will attempt to do CPU-specific optimizations for certain key words.
Among other things, I will stop using 'lodsd' as it is slower than 'mov eax,
[esi]; add esi, 4' on Pentiums++.
Good issues, stuff I'm also considering as Reva progresses.
--
My GPG public key is at http://ronware.org/
fingerprint: 8130 734C 69A3 6542 0853 CB42 3ECF 9259 AD29 415D
Other related posts:
