Re: [stack] Concatenative Hardware Redux (Another 16 Instruction Set)

Christopher Diggins <[email protected]> wrote:
> William Tanksley, Jr <[email protected]> wrote:
> > A fascinating goal, and one which to my knowledge has not been
> > attempted together with a high-level instruction set.

> I think the distinction between "high-level" and "low-level" is
> artificial, and rooted to firmly on the naivete of our predecessors.
> If we ignore it, we can come up with something new and interesting.

Well then, "special purpose" versus "general purpose". Either way, IMO
interesting.

> > > However, to be completely honest, the more I experiment with the
> > > instruction set, the more I think that I would prefer to work with a
> > > 255-instruction set (ala JVML).

> > Completely incompatible with the goal of minimal hardware

> Not at all, it depends on what you do with these instructions. I
> should clarify that I really mean "1-byte" operators. The core
> instructions would be few, and many of the bits would be flags.

Ah, this is how I handled the 8-bit instructions I was required to use
during my processor design class (UCSD). I encoded only a few fields
in the instruction word, and the rest I ran as raw input directly to
the needed components of the processor. Saved a few transistors, at
the cost of vastly larger code size (but I was competing against
students designing accumulator machines, so they had the same code
size problems).

> Consider:
> and then with a bit flag to represent "dip"
> and another bit flag to represent "dup"
> and another bit flag to represent "swap"
> Hopefully this illustrates what I have in mind.

I think it does. I'm sure you haven't settled on any meanings for bits
yet, and those are just the first examples that pop to mind. (Note
that deep stack effects are a _very_ bad idea, so being able to easily
add dups will make your instructions VERY slow. In fact, these are
_very_ bad choices, because it's not clear how those appendage
instructions will be ordered... If I turn on both the dip AND swap
bit, which one happens first?) But I'm sure you'll put the effort
needed into designing this when and if you decide to.

> > -- and do
> > you actually have anything close to 256 opcodes?
> It's quite easy to come up with a whole bunch of opcodes.

No doubt. Useful and coherent ones? That's another matter.

> > Wouldn't retreating to 5-bit instructions make more sense
> > initially?

> The simplicity of the design has less to do with the number of
> instructions, than it does with the organization and kind of
> instructions. 4-bit instructions is an interesting challenge, because
> it is so darn small. 5-bit instructions has already been done and I

Again, I don't recommend taking on 2 "interesting challenges" in the
same problem. Small instruction set is cool; high-level instructions
is cool. Both together? Too many constraints. Solve one, THEN solve
the other.

> believe would be hard to port to other architectures efficiently.

I don't understand the "hard to port" objection at all. Clarify? How
can a microarchitecture need to be ported to another architecture?

> 8-bit instructions is easy to port and emulate. I consider emulation
> very important, because a practical virtual machine would be run on
> many different kinds of chips and software.

Well, that's certainly an important design constraint. Software can
handle muxing a LOT better than hardware can (of course, software has
a MUCH harder time of handling predecoded instructions). 8-bit VM
instructions make a lot more sense than 8-bit hardware instructions.

> - Christopher

-Wm