RE: [colorforth] FS/Forth for DOS: crude performance test

[Samuel Falvo <falvosa@xxxxxxxxx>]

> It is DOS and stand-alone. You make a floppy from a desktop computer and
> boot your laptop with it.

If it's stand alone, then it doesn't run under DOS.  :)

> I believe the technique I uses is slightly superior to the ones using SI or
> DI as data stack pointer, because it balances the load of managing it
> through all the primitives whereas with SI or DI you got to make a trade-off
> between, so to say, DUP and DROP.

I thought about peephole optimizing the XCHG BP,SP instruction sequences,
actually.  I didn't bother putting it in because most of my Forth primitives
are called as subroutines, and because literals are relatively rare in my Forth
environment.  Hence, the amount of compiler complexity it introduced wasn't
worth it.  Therefore, for my DOS Forth environment, using SI would have both
been easier and faster.

When designing the Linux version of FS/Forth (and possibly the next version for
DOS), I'm going to inline as many primitives as it makes sense to.  SI and BP
will probably be about the same speed in run-time performance.  Actually, BP
will still be slightly slower, because of the requirement to XCHG before making
the next subroutine call, and XCHG again before the next primitive.  But
all-in-all, the performances should be about the same.

I truely don't understand what you mean by 'balance load of managing it through
all primitives.'  When using BP for the data stack pointer, my primitives are
literally peppered with XCHG BP,SP, push or pop, XCHG BP,SP.  These sequences
are quite often 100% equivalent to the code that would have been generated by a
DUP or DROP primitive.

> the way I must warn you that size may matter. For instance, if you're
> implementing IFs with straightforward JZ like I did, then you should take
> care about jump ranges. If you're implementing IF using:
> JNC L1
> JMP L2
> L1:
> Then you pay twice. So take care. I think it's a bit dangerous to start with
> "that's good enough" than "that's the best for me" at this level.

I don't know of a single Forth system that works like this -- not a single one.
 Mine certainly do not.  128 bytes is a lot of code for a Forth system to pack
between an IF and an ELSE or THEN.  The only time I can ever see the
possibility of exceeding 128 bytes is when you have screen-sized definitions,
which is of course not proper style for Forth (ANY Forth, not just
MachineForths).

--
Samuel A. Falvo II


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com