Re: I found a FORTH stack optimzer, but could use a better version.

On Jan 8, 8:13 am, Albert van der Horst <alb...@[EMAIL PROTECTED]
>
wrote:
> In article <flus86$36...@[EMAIL PROTECTED]
>,
>
>
>
> Rod Pemberton <do_not_h...@[EMAIL PROTECTED]
> wrote:
>
> >"Stephen Pelc" <stephen...@[EMAIL PROTECTED]
> wrote in message
> >news:478201e9.1788292609@[EMAIL PROTECTED]
> >> For Forth to Forth translation look at Timbre by Rob Chapman. Others
> >> have used it for host and embedded compilation.
>
> >Actually, you may have referred me to the works of the correct person. 
It
> >appears that Rob Chapman's "Stack Quarks" Sept. 15, 1995 are the
solution to
> >optimizing FORTH stack words for x86 assembly.  He defines six words:
>
> >  DIP DRIP NUP NIP TUCK TAKE
>
> >Each of these corresponds 1:1 to x86 assembly instructions, as the C
> >versions in "Script.3" shows, i.e., they correspond to mov, push, or
pop.
>
> Interesting idea!

Only if your data stack is the machine stack (SP or ESP). The NCC/STC
development version of Win32Forth uses the stack as the rstack, and
the data stack is emulated on EBP. The overhead is non-existent impact
to better performance, as PUSH/POP often take longer than explicit EBP
based operations. The downside is code size; PUSH and POP are very
short instructions. Not using the ESP based stack as a data stack also
allows calls to Windows APIs without requiring stack-switching or
explicitly stating the number of parameters to be passed. For
Win32Forth, with its dependence on lots of different API calls, that
simplifies things enormously.

>
> >NIP and TUCK appear to be the standard definitions.  DROP, DUP, SWAP,
OVER,
> >are defined in terms of the six.  I don't see definitions for ROT, or
-ROT.
> >From the article, it seems he has/had a Timbre script for converting
FORTH
> >stack instructions similar to the java app.  The results using that app
> >showed that DUP,DROP,OVER correspond 1:1 to x86 assembly, but that
SWAP, or
> >another stack ****ft instruction (ROT,-ROT,ROLL) was im****tant. 
Relocating
> >the physical stack from location 0 to 2 of the virtual stack does
wonders...
>
> Isn't that dangerous in the situation of the x86 where the stack is
> used by interrupts too?

No, the registers are saved/restored across interrupts. The x86 chip
also provides OS sup****t for floating point save; if a task doesn't
use the FP regs, then the OS can choose not to save them, reducing
task switch time.

It's quite common to buffer TOS in a register; Win32Forth (ITC) does
it for the top stack entry and Anton Ertl has a paper somewhere on his
site on the performance implications of caching none to several of the
stack entries. I seem to remember that more than 2 gave very little,
if any, performance advantage. There's also the downside of stack
underflow; it's more difficult to detect with stack entries in
registers, and for Win32Forth, caching one register simplifies the
interfacing to the Windows API. Caching lots of registers requires
more saves and restores across CALL boundaries.

>
>
>
>
>http://www.compusmart.ab.ca/rc/Timbre/ContentPages/Timbre/SQP/StackQu...
>
> >Oddly, I see no discussion of this paper or his FORTH words in the
archives
> >of c.l.f. (?!?!)  Or, on usenet in general...
>
> >Rod Pemberton
>
> Groetjes Albert
>
> --
> --
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- like all pyramid schemes -- ultimately falters.
> albert@[EMAIL PROTECTED]
 &=nhttp://home.hccnet.nl/a.w.m.van.der.horst

--
Regards
Alex McDonald