[retroforth] Re: colorForth and Retro (split off of "read from stdin")
- From: "m g william" <mgbg25171@xxxxxxxxxxxxxxxx>
- To: <retroforth@xxxxxxxxxxxxx>
- Date: Fri, 20 Jan 2006 09:07:15 -0000
Charles
Thanks for responding.
I didn't mean to cut across Lasse's thread or bang on about colorForth on a
Retro list.
I thought I'd replied to you personally, as your email was from Charles
Childers, not the list.
My mistake so apologes to you and Lasse!
Thanks for the info. That helps put things in perspective.
Rgds Dean
----- Original Message -----
From: Charles Childers
To: RetroForth Mailing List
Sent: Friday, January 20, 2006 12:26 AM
Subject: [retroforth] colorForth and Retro (split off of "read from stdin")
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:
