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

[Fréderic DUBOIS <frederic.dubois@xxxxxxxxxxxxx>]

> -----Message d'origine-----
> De : Samuel Falvo [mailto:falvosa@xxxxxxxxx]
> Envoyé : ven. 27 juin 2003 17:26
> À : colorforth@xxxxxxxxxxxxxxxxxx
> Objet : RE: [colorforth] FS/Forth for DOS: crude performance test
> 
> 
> > 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.  :)
> 

You're mercyless... :) It comes both in a DOS and a stand alone version.

> > 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 

There's also IF. It's always interesting to disassemble the compiler output.

> 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.
> 

Probably.

> 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, 

an implementation using SI does:
DROP LODSW
DUP  MOV [SI],AX DEC SI DEC SI ( or something like that)
whereas with BP or AX as stack pointers that are swapped with SP to use
push/pop, DROP and DUP are equal:
DROP XCHG BP SP  POP AX XCHG BP SP
DUP XCHG BP SP PUSH AX XCHG BP SP
But that's not only about DUP and DROP, that's also about binary operators
also, they perform a kind of DROP
( they take 2 parameters and leave 1 result)



> > 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).
> 

A shortage in my brain. What I wanted to write is that if you don't care
enough about the size of the code you inline you may end-up with this kind
of implementation. However sometimes code grows faster than you think. An
inline string may send a THEN out of range if inline too much or too big
code chuncks.


> --
> Samuel A. Falvo II
> 


 Amicalement,
  Frederic


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