[retroforth] colorForth and Retro (split off of "read from stdin")
- From: Charles Childers <charles.childers@xxxxxxxxx>
- To: RetroForth Mailing List <retroforth@xxxxxxxxxxxxx>
- Date: Thu, 19 Jan 2006 19:26:54 -0500
Hi Dean,
I started a new thread since this is a bit off-topic for the "read from
stdin" thread.
> Hi Charles
> You've done a lot of work on Retro since I last saw it.
> Since I read that Retro was designed for learning rather than performance,
> I'm forced to lean towards colorForth.
> Version control, documentation etc is not upto your standard. Consequently
I
> waste a lot of time.
Since 8.0 Retro haas aimed a bit more towards being complete enough for
useful programs to be written while still being easily learnable.I have made
some headway on improving performance with inlining and selective
optimizations.
> My PowerBasic app is going well now so I do at least have a design and can
> start looking at porting.
Cool.
> I'm very interested in the structural differences, that affect run
> performance, between colorForth and Retro and
> wonder if you have ever benchmarked colorForth against c.
I regret that I can't presently run colorForth. I've used it under an
emulator (VMware Player), but that doesn't give me a solid enough basis for
testing performance. From what I do know of colorForth, I doubt if it's as
fast as optimized C. Then again, colorForth is its own OS, so maybe it can
run the code faster given that it doesn't have to deal with the C calling
conventions.
Retro's internal structure is different than colorForth. The first
noticeable difference is that colorForth (from what I understand) makes use
of preparsed source; Retro parses the source during the interpretation time.
A second difference would be the dictionary model. Retro now uses one
dictionary and word classes to define the actions (somewhat equivilent to
colors) of each word. colorForth uses two dictionaries to store the two
classes of words that exist. (Retro has five primary classes in 9.0). The
structure of the dictionaries also differs.
What is the same is the register model. Like colorForth, Retro uses ESI as
the stack pointer, with EAX caching the TOS. This makes porting primitives
between colorForth and Retro pretty easy.
Note concerning the performance of Retro:
With the upcoming 9.0 release, I've made a few steps towards improving
performance. My benchmarks are really rather limited; all I have presently
is a recursive fib and a test of the startup speed. In a test run on my vps
server (http://www.rx-core.org), I obtained the following results (average
of 5 runs). All times are in seconds:
Startup time:
8.2.5 0.004
9.0 0.005
Recursive FIB (40 fib), rounded to the nearest .250:
8.2.5 13.500 Takes 71 bytes when compiled
9.0 7.500 Takes 63 bytes when compiled
I do have a more optimal version of the word "literal" that improves the
recursive fib when used. The definition is:
:: c: dup $B8 1, , ; is literal
With this, the recursive fib takes about 3.1 seconds. If performance is a
must, you might look at Reva (http://ronware.org/reva), which is similar to
RetroForth, but significantly faster. HelFORTH (
http://maschenwerk.de/HelFORTH) is also generally faster.
> I tried to assemble some of the stuff from Tim Neitz site using NASM. I
> couldn't. I liked the idea of this
> 'cos its similar to FASM apparently.
> The only thing I can assemble is the 800X600AGP non-DMA colorForth.
>
> I can run color.com of both Jeff and Chucks site but can't assemble them
> from the 3 asm files. Shouldn't
> there be a .blk file some where for these?
I regret that I can't be of much help here. Chuck's colorForth uses MASM,
which isn't freely redistributable. I believe that you are expected to
extract the blocks from the color.com file. Then again, I'm not a colorForth
expert by any means! You might ask in #c4th on irc.freenode.net where those
who are sometimes hang out.
> Keep up the good work and good luck to you.
Thank you
> Rgds Dean
--
Charles R. Childers
http://www.retroforth.org
--
Charles R. Childers
http://www.retroforth.org
Other related posts:
