Data Stack

The data (or parameter) stack is similar to the return stack at its core, but with much more involved. Whereas the return stack is a strict FILO system, the data stack holds items which may need to be shuffled to allow access to them. Because the 0-Operand Design Model feeds the top of the stack (TOS) and the next item on the stack (NOS) to the ALU, the TOS is actually a separrate register. The output of the ALU (usually) is assumed to be placed in TOS once its computation is complete. Also, the ability to easily transfer both elements is a benefit in this design.

To further streamline operations, an additional 'hidden' register (Temp) is included. This will be used to assist in data transfers within the stack itself and is not accessable to the rest of the system. - =Electric Design= The electric design is fairly straightforward. There are three registers but one of them has a memory bank attached, with its own address space. The heart of the stack memory is this RAM bank, 256 elements deep. The data input is separate from the output so one does not interferre with the other. The RAM is controlled is similarly to a latch in that the output will always be active and will update its value only on command. To the system it looks like another register. The sequencer ensures that the output is always re-read whenever the pointer is altered, to keep this 'register' updated. When the RAM bank is read this way it is actually the second value on the stack (NOS) that is being read. The TOS is an additional 1-element RAM module (the basic register) that may be read and written with either the NOS register, the local TEMP register or other external sources such as the ALU. The TEMP register can be read or written with either the TOS or the NOS and that's all. These three are tightly tied with direct 'enables' between each one, for each direction. Again, the dual ported nature of the RAM helps with these connections. There is a local counter, or Stack Pointer, for this memory and this is effectively another (8 bit) register but it is not accessible to other parts of the system or software. The only functions that the pointer section knows, is to increment or decrement the pointer by 1 or 2 and reset outputs to 0 if possible - necessary???. It is not even meant to be read by the system. That makes this machine incompatible with standard Forth systems. However, for debug purposes, the pointer is made to be read into TOS and this function is 'secretly' available to the system. But it remains unable to write to the pointer. (Hey, I can't even properly reset it! - right?)



=Physical Layout= There being three registers as the basis of this stack design, these registers are arranged in a rough circle with each other, the stack counter and the control lines (sequencer). This tower is vertical by data size wih the biggest digits at the top, per project standard.

=Sequencer Design= The stack sequencer must be programmed to control all the signals with proper timing to execute the specified instructions. Other routines may make calls on the stack. For example, the TOS may be copied into any GP register and this would be initiated by the sequencer in the Register Bank.

All hardware controls are listed below: There are 6 enable control lines : As develoment continues, it may be found that some of these enables may be permanently activated. Other 'enables' required by the system and for flexibility may be included as well. Some possibilities are:
 * A Hex command input to control the stack pointer  [2-bits: -2, -1, +1, +2]
 * A Hex command input to R/W the stack RAM (NOS)  [2-bits: Idle, Read, Write]
 * A Bin input to latch TOS
 * A Bin input to latch Temp
 * TOS_to_NOS
 * NOS_to_TOS
 * TOS_to_Temp
 * Temp_to_TOS
 * NOS_to_Temp
 * Temp_to_NOS
 * TOS_to_D.Bus
 * D.Bus_to_TOS
 * NOS_to_D.Bus
 * D.Bus_to_NOS

Here's the schematic of the stack without the sequencer.



=Machine Codes/Instructions= The following list of instructions will be implemented. Some of these are to satisfy the Design Model while some are included for completeness or to provide additional useful instructions. For descriptions of these instructions, see Instruction Set. For the complete sequencer definitions see Instruction Sequences.


 * 0 - Idle
 * 1 - Push
 * 2 - Drop
 * 3 - SWAP
 * 4 - NIP
 * 5 - Over
 * 6 - Dup
 * 7 - Pick(0-15)
 * 8 - >R  Write TOS to TOR
 * 9 - R>  Latch TOS from TOR
 * A - >A  Write TOS to A-bus
 * B - A>  Latch TOS from A-bus
 * C - >Bus  Write TOS to the general data bus
 * D - Bus>  Latch TOS from the general data bus
 * E - >NOS  Write NOS to the general data bus
 * F - NOS>  Latch NOS from the general data bus

These are the 'higher level' routines. Some 'lower level' routines may also be mapped into this sequencer, or be included in others. These may include:
 * Inc_SP  Increment the Stack Pointer
 * Dec_SP  Decrement the Stack Pointer
 * SP!  Write (latch) TOS to Stack_Pointer ???
 * SP@  Latch Stack_Pointer to TOS ???

- - - - Do I really need access to these in the instruction set itself? - - - - Can the 'output' instructions be combined into one? This module does not need to know where its data are going. Just the they need to be steady in due time.

These routines must be used with care, so the stack does not become confused. Any direct stack manipulation instructions should only be included in this sequencer for similar reasons. - Notes This design may use a small, fast adder in the stack memory access circuitry. This would allow the software to read deeper stack elements without ANY stack manipulation but at the cost of a more complex instruction set. The element accessed this way is not consumed by the read so if that is expected, the stack will still need to be massaged to remove the item. (?)