Path: utzoo!attcan!uunet!samsung!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!a.gp.cs.cmu.edu!koopman
From: koopman@a.gp.cs.cmu.edu (Philip Koopman)
Newsgroups: comp.lang.forth
Subject: Re: ANS FORTH/PICK and ROLL
Summary: implications for hardware
Message-ID: <7011@pt.cs.cmu.edu>
Date: 17 Nov 89 12:33:35 GMT
References: <8911170645.AA20490@jade.berkeley.edu>
Organization: Carnegie-Mellon University, CS/RI
Lines: 27

Support for PICK and ROLL vary wildly on stack hardware.
On some machines, they can get pretty nasty, if the machine
only supports access to the top of the stack.  It turns out
that microcode works really well for PICK and ROLL, because
you can twiddle with the stack pointers without worrying
about an interrupt trashing the stack within a single opcode.
(Of course, you can disable interrupts in other systems explicitly).

The real problem is that most machines have limited on-chip stack
size, with spilling or paging into program memory.  If you PICK
or ROLL something that has been spilled into program memory, you
can have a real problem!  This means that PICK and ROLL either
have to be used only with programs that are guaranteed not to
spill to program memory, or, PICK and ROLL flush all buffers
to program memory before starting operation.  Other compromises
or schemes are certainly possible, but this illustrates the
key elements of the problem.

I used to use PICK and ROLL a lot, because you get deep stacks
working with 32-bit and 64-bit quantities on a 16-bit Forth.
Now that I use 32-bit systems, I use them much less frequently.

  Phil Koopman                koopman@greyhound.ece.cmu.edu   Arpanet
  2525A Wexford Run Rd.
  Wexford, PA  15090
Senior Scientist at Harris Semiconductor.
I don't speak for them, and they don't speak for me.