[stack] Re: Concatenative Hardware

--- In [email protected], "Christopher Diggins"
<cdiggins@...> wrote:
>
> On 11/2/07, pml060912 <pml540114@...> wrote:
.
.
.
> > Maybe I'm missing a layer of sophistication hidden within the
> > capabilities of one of these instructions (COMP, maybe?), but doesn't
> > that restrict the virtual machine to the capabilities of a pure single
> > stack machine?
> 
> QTE and COMP allows you to treat function like stacks, by adding data
> to them, which you can accesss later by calling CALL. So
> computationally it is a multi-stack machine.

Could you describe their behaviour a bit more?
.
.
.
> > > to do simple things (e.g. accessing items deep in the stack).
> >
> > For what it's worth, I contributed the original versions of the high
> > level PICK and ROLL used in Ting's Eforth. They work using recursion
> > and the return stack for temporary storage. That approach doesn't use
> > many instructions in the code or many different opcodes, but it does
> > use a lot of cycles to get very deep.
> 
> What are the stack effects of PICK and ROLL? (I don't really know
> FORTH that well).
> 
> I wonder if PICK and ROLL would be a better choice than DIP, QTE,
COMP, etc.

They provide means of accessing items arbitrarily deep in the stack,
e.g. 7 PICK puts a copy of the 7th item on top and 7 ROLL moves the
7th item to the top withe higher ones each moving down one, a
generalised DUP and a generalised SWAP. But they don't do the other stuff.

However, my personal taste would be to separate the different kinds of
functionality during the research phase anyway, at least until I found
the combinations that seemed to come up the way you found with the DIP
generalisations. That would mean, say, using PICK and I rather than a
generalised DIP.