Path: utzoo!attcan!uunet!zephyr.ens.tek.com!tekcrl!tekgvs!toma
From: toma@tekgvs.LABS.TEK.COM (Tom Almy)
Newsgroups: comp.lang.forth
Subject: Re: Forth on the Intel 80386
Message-ID: <6983@tekgvs.LABS.TEK.COM>
Date: 1 Mar 90 15:47:30 GMT
References: <584.UUL1.3#5129@willett.UUCP>
Reply-To: toma@tekgvs.LABS.TEK.COM (Tom Almy)
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 43

In article <584.UUL1.3#5129@willett.UUCP> ForthNet@willett.UUCP (ForthNet articles from GEnie) writes:
>Category 3,  Topic 7
>Message 29        Tue Feb 27, 1990
>D.RUFFER [Dennis]            at 23:30 EST
> 
>Re: PETE KOZIAR
>
> > The best reason for the inner interpreter on the 80x86 family is
> > because there's only really one stack, pointed to by S.  It makes
> > sense to use the fastest access for the most-used stack, namely,
> > the parameter stack.
>
>Has anyone done some real anaysis on this?  With every high level definition
>pushing something onto the return stack when it starts and popping it back off
>when it is done, it seems as if the return stack is used more than the
>parameter stack.

Well I did, some years ago. Until the 80386, all of the Intel processors did
best with direct threaded code. With the 80386 it appears to be a wash.
(Note that with the 68000 and 6502 processors, subroutine threading is a
decided win because the 68000 has multiple stacks and the 6502 has difficulty
with threaded code).

The parameter stack is used more than the return stack because most words
executed are primitive code words, and they do not use the return stack. With
subroutine threaded code, the primitives are reached by calls which puts the
return address at the top of the machine stack. This virtually necessitiates 
that the return stack be the machine stack. The BP register then has to be
used as the parameter stack pointer, and push/pop operations are performed
by swapping BP and SP before and after the stack references.

You can still win with subroutine threaded code in all these processors
by realizing that its not threaded code at all! If the compiler is
smart enough to generate inline code for the more common primitive 
operations (rather than CALLs) that a very significant performance gain
is achieved. The memory constraints on 8080s especially and 8086 real mode
to a lesser degree tends to make this memory hogging approach impractical,
but it makes a great deal of sense for 80386 processors running in protected
mode with lots of memory.

Tom Almy
toma@tekgvs.labs.tek.com
Standard Disclaimers Apply