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

"Albert van der Horst" <albert@[EMAIL PROTECTED]
> wrote in message
news:jubg5r.hy7@[EMAIL PROTECTED]
> In article <flus86$366$1@[EMAIL PROTECTED]
>,
> Rod Pemberton <do_not_have@[EMAIL PROTECTED]
> wrote:
> >
> >"Stephen Pelc" <stephenXXX@[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!
>
> >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?
>

Dangerous in what way?  I'm not completely clear on which type of danger
you're asking about...

The stack state and stack pointer prior to the interrupt should be
restored
upon returning from the x86 interrupt.  Interrupts either a) use their own
stack or b) must reset the stack pointer if changed.  They shouldn't be
corrupting stack data that isn't theirs, but if they do, they must restore
it prior to returning from the interrupt or risk a crash...  (Was this
what
you were asking about?)  I don't see how this would be any different from
assembled C code, OS code, BIOS code.  In a typical x86 compiled C
application, there is only one stack.  The flow control information (stack
frame, program counter, instruction pointer, cpu flags, etc.) and local
variables are interleaved on the same stack.  This can lead to the well
known underflow/overflow buffer exploits.  (Or, was this what you were
asking about?)

FORTH, as I understand it, typically separates the data and tem****ary flow
control information by using two stacks: data, return.  As I understand
it,
the primary purpose of the return stack is to store the tem****ary flow
control information (return addresses).  This is much safer than a single
stack.  By using two stacks and not interleaving data and control flow
information, FORTH also eliminates the need for a stackframe required by
other languages.  I.e., no need for a compiler to copy data from where
it's
at on the stack to where it's needed on the stack - in FORTH it's already
there or can be moved quickly with stack operators.  I've recommended
separate stacks to some (insignificant) C people to eliminate buffer
exploits.  But, using two stacks does have some extra assembly overhead on
x86 - that I'm avoiding.

I also "see" a potential issue with the 1st and 2nd stack items, "top" and
"next", being in registers instead of on the stack. (Or, perhaps this was
what you were asking about?... :-)  They could be corrupted by other code
or
interrupts if care isn't taken to ensure they are preserved, or if care
isn't taken set them to registers which are known to be saved and
restored,
i.e., "callee-savee", by other code.


Rod Pemberton