Re: [stack] Concatenative Hardware

Hi Don,

I'm glad you like the idea. The current Cat implementation has over a
hundred built-in primitives, because I was obsessed with performance in the
early stages. This is no longer the case, so the design is a bit weird, some
parts are heavily optimized while others are extremely naive.

I do plan on writing an VM emulator for the instruction set once I get some
more feedback. I figure many people might have some insights to share, to
help reduce the development time. I want to make sure that I am not going
down a particularly boneheaded path.

Thanks,
Christopher

On 11/1/07, Don Groves <[email protected]> wrote:
>
>   Hi Christopher,
>
> I like this idea.
>
> Any thoughts of emulating this set and building Cat on that virtual
> machine (or is that already how Cat is implemented)? It seems to
> me that doing so would yield significant insights into the utility of
> your instruction set.
> --
> Don Groves
>
> On Nov 1, 2007, at 19:39 , Christopher Diggins wrote:
>
> > So I've been thinking about concatenative hardware lately. Here is a
> > single-stack
> > machine instruction set:
> >
> > 0: JZ (val fxn -> ) // jump to fxn if value is below zero
> > 1: CALL (fxn) // push return address and jump to fxn
> > 2: LTEQ (val val -> bool) // compare values
> > 3: AND (val val -> val) // perform bitwise and
> > 4: XOR (val val -> val) // perform XOR operation
> > 5: SHL (val val -> val) // shift-left
> > 6: DUP (a -> a a) // duplicate top-value
> > 7: QTE (val -> fxn) // create a thunk
> > 8: COMP (fxn fxn -> fxn) // compose two functions (append their
> > contents)
> > 9: POP (a -> ) // pop value from stack
> > 10: DIP (a fxn -> a) // applies function to below top of stack
> > 11: SWP (a b -> b a) // swap top two items
> >
> > So essentially we can use the data stack also as a return address
> > stack. This is a zero operand instruction set, so it is very compact
> > and can be implemented efficiently, but it takes a lot of instructions
> > to do simple things (e.g. accessing items deep in the stack).
> >
> > The "dip" instruction is so important I'm tempted to include variants:
> >
> > 12: DIP2 : (a b fxn -> a b)
> > 13: DIP3 : (a b c fxn -> a b c)
> > 14: DIP4 : (a b c d fxn -> a b c d)
> > 15: open for suggestions
> >
> > Of course "DIP" can be implemented as "SWP QTE COMP CALL", but I'm
> > concerned about performance. The "DIP" is one of the most frequent
> > instructions in my code.
> >
> > Anyway, hopefully this makes sense to my fellow concatenators. I'd
> > love to hear thoughts and suggestions. I'm pretty naive when it comes
> > to hardware.
> >
> > - Christopher
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
> 
>


[Non-text portions of this message have been removed]