Re: [stack] Concatenative Hardware

Not boneheaded at all , imho.  Forth hardware has been around for a  
long time.
With the ubiquity of Java, I'm expecting to see JVM hardware someday  
also.

Lately, I've been re-reading the ideas behind Ralph Griswold's Icon  
language.
Icon has higher level semantics than most programming languages and some
excellent underlying ideas, such as generators, which implement  
laziness.

I'm planning on including generators in my experimental concatenative  
language
as well as other Icon ideas. For example, [1 2 ...] is a lazy list of  
positive integers.
The ellipsis is a generator which unconses the next integer and  
produces [2 3 ...],
[3 4 ...], etc.

Icon can be found at http://www.cs.arizona.edu/icon/ for those  
interested.
--
Don



On Nov 1, 2007, at 19:22 , Christopher Diggins wrote:

> 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]
>
>
>
>
> Yahoo! Groups Links
>
>
>
>