Re: Concatenative Hardware Redux (Another 16 Instruction Set)

Christopher Diggins <cdiggins@...> wrote:
> William Tanksley, Jr <wtanksleyjr@...> wrote:
> > Seriously, though, I do suspect that Chuck Moore has it right on this
> > one...

> Why?

> > Use instruction slots in a larger word size, and allow some of
> > the slots to encode alternate instructions.

This is what Chuck does. The reason I think he's got it right is that
16 instructions just isn't enough for a reasonable programming
platform, especially if you include specialized instructions (such as
your list manipulators). 32 instructions is PLENTY -- you'll wind up
with spares. And the specialized slots allow you to include
instructions whose only purpose is making decoding easy.

Right now you've got 4-bit instructions; I assume a 32-bit word size.
That means you load 8 instructions with every fetch. That's a _lot_ of
instructions that can run without any need for memory access... If you
change to 5-bit instructions you can fit 6 instructions, plus 2 bits
for something else. 6 instructions is still an awful lot, and now you
can include more useful instructions which will make your operations
much more powerful. Use those two leftover bits to allow 4 different
ways of interpreting the loaded instruction word: 00=literal (just
push it on the stack and load the next); 01=literal jump;
10=microloop; 11=literal call. (Or whatever encoding and instructions
you want.)

Microloop is amazingly powerful, and changes the way your instruction
set works. With it, you should consider adding instructions that use
iteration... For example, Chuck didn't have room on his chip for a
multiplier, but he did include a 'multiply step' instruction, which
with the uLOOP capability makes multiplication very simple. I don't
know what your chip might need... Perhaps a MergeSortStep instruction?

> > In the SeaForth, you have
> > an 18-bit word size with 3 5-bit instructions plus a trailing 3-bit
> > instruction... The trailing instruction is very useful for the uLOOP
> > instruction, which can only go there and which performs a 'decrement
> > and loop if not zero' without a destination (which means it'll repeat
> > the preceding words in the instruction).

> Sure but that is just one instruction. Overall, having 16
> instructions, means a much smaller chip with very very small power
> overhead. I'm not an expert in the domain of course, but I would like
> to know more about the trade-offs.

4 bits versus 5 bits is just what it looks like -- a 20% space
savings; that adds up FAST. The problem is that if the 16 instructions
you choose exclude commonly used ones, your programmers will not only
be annoyed, their programs will wind up taking MORE space, since they
have to use 2 or 3 opcodes to implement what could have been done with
1 5-bit opcode.

You're in an experimental design space, attempting to produce a
high-level microarchitecture (i.e. with instructions for a high-level
task, list manipulation). I think you'd be better served by
underconstraining your problem space: loosen up the constraint on the
"smallest possible instruction set" in order to give yourself elbow
room for "highest level instruction set". Don't give up on "smallest
possible"; just produce a working draft that is a bit big, and then
see if you can make it smaller later.

> - Christopher

\-Wm