Steamer16 stack machine lives!
- To: "MISC list" <MISC>
- Subject: Steamer16 stack machine lives!
- From: "Myron Plichota" <myron.plichota@xxxxxxxxxxxx>
- Date: Mon, 5 Feb 2001 14:30:31 -0500
Dear MISCers,
It gives me great pleasure to announce the successful
construction/testing/shakedown of the first Steamer16-based prototype
system. The shakedown was not a cakewalk due to transmission line phenomena
experienced on the hand-built circuit board, but it now seems solid enough
to do some serious development work for a startup venture I am involved
with. I still suspect a marginal data hold time problem during write cycles
to asynchronous SRAM, but I am not going to rush into a redesign or further
modifications of the prototype until more real-world experience has been
gained. It is running at the theoretical limit of 20 MHz which yields a
performance of 20 peak MIPs and 16.7 to 10 aggregate MIPs depending on the
particulars of the opcode mix in a given instruction packet.
The design was written in VHDL and fitted to the Cypress CY37128P84-125JC
CPLD.
I'd like to express thanks to those of you who encouraged me to see this
through, and in particular, for recent close support by my brother Vic.
I am extremely busy working on the R&D for the startup venture, but I will
reply ASAP to any inquiries from the readership.
Following is an excerpt from the Steamer16 documentation.
Myron Plichota
-------------------------------------------------------------------------
Programming model:
Steamer16 consists of a program counter (PC) and a 3-deep evaluation
stack. All instructions except "lit," operate on data already on the
stack. PC is cleared on reset. Stack entries are undefined until loaded
using "lit," instructions. There is no program status word.
Instruction encoding:
The PC addresses inline data or instruction packets, not individual
instructions. Five 3-bit instruction "slots" are packed left-justified
into each 16-bit instruction packet with the lsb a don't care. The most
significant slot in a packet is executed first. All instructions execute
identically in any slot. Inline data to satisfy any "lit," instructions
follows the packet itself.
Stack diagrams:
Stack diagrams are used to describe instruction behavior by showing the
inputs and results on the stack in a concise notation. The inputs are on
the left-hand side of the "--" before/after separator, the results are on
the right. The input list shows only the relevant stack entries. The
output list shows all three entries. The symbols x, y, and z, are used to
denote the original values of any surviving independent stack entries.
Instruction descriptions and opcode assignments:
NOP, {0} ( -- x y z) no operation
lit, {1} ( -- y z data) PC++ push data at PC, increment PC
@, {2} ( addr -- x y data) fetch data from addr
!, {3} ( data addr -- x x x) store data to addr
+, {4} ( n1 n2 -- x x n1+n2) add 2ND to TOP
AND, {5} ( n1 n2 -- x x n1&n2) and 2ND to TOP
XOR, {6} ( n1 n2 -- x x n1^n2) exclusive-or 2ND to TOP
zgo, {7} ( flg addr -- x x x) if flg equals 0 then jump to addr
else continue
Instruction timing:
First, an instruction fetch cycle is required to load the instruction
register with the packet of 5 instructions currently addressed by the
PC. Next, the instructions contained in the packet execute in 1 cycle
each. An exception is made when the remainder of a packet consists
entirely of NOPs or zgo, takes a jump. In either of these cases the
current packet is aborted and another instruction fetch cycle follows
immediately. Packets are fetched and executed in 6 cycles during
straight-ahead execution for an average of 1.2 cycles per instruction.
Any packet containing 4 trailing NOPs will execute in 2 cycles, i.e.
an instruction fetch cycle followed by execution of the first
instruction in the packet, whether it is a NOP or not.