home .. forth .. misc mail list archive ..

Steamer16 stack machine lives!


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.