BigEd wrote:
The two instructions can safely be hit by an interrupt, if the ordering is right: for a push, first adjust the stack pointer, and then write the value. For a pop, read the value, and then adjust the stack pointer.
That is a great observation. When considering the order of the operations, I did not consider this effect.
However, I think the issue at hand is interrupts. I think that interrupts are a good solution for some situations, but in many instances, they are a source of many problems. As you pointed out, my example regarding using critical sections to protect the push / pop operations is not adversely affected by interrupts.
So let's take it a bit further. Let's suppose interrupt handling was to be added to the VIPER. What changes would be required to the architecture? Would those changes require additional instructions and registers to be added?
As I see the architecture, 30+ years into its future, I am pleasantly surprised by the power of the architecture. At first glance, three 32-bit registers, a 20-bit program counter, a single-bit status bit does seem to be a bit constraining. Given that there is no restriction that the destination register of an indexed addressing mode instruction cannot be the index register itself, the VIPER can easily implement indirect addressing. It would require two instructions: (1) instruction to load the pointer, and (2) the second to load the operand. However, the level of indirection does not have to end there. The number of pointer loads that can be performed is essentially unlimited. One thing this type of operation is useful for is for following the STATIC LINK to locate a local variable of an enclosing function as is common with Pascal. Another use for this capability would be to walk function tables, linked lists, etc.
As I've been trying to understand the instruction set, I've been relating the VIPER instruction format to 6502/65C02/M65C02A instructions and capabilities. With the exception of the PSW and the automatic setting of the NVZC bits during various instructions, I've not found that the missing "functionality" cannot be duplicated by very short instruction sequences. Stack operations are easily performed in two instructions, which appears to be consistent with what you guys found sufficient for the OPC machines.
As I find more of these nuggets in the VIPER instruction format, I am beginning to think that the VIPER was a victim of the available technology and available budget at the time of its introduction. The small, structured ASIC technology used in the first generation implementation limited its performance because a HW multiplier was not included. When compared performance to a VAX11/730, it was found to perform its assigned function well, but did not provide adequate margin to support additional functions.
I think this analysis was a bit of an apples versus oranges comparisons. Furthermore, I have serious doubts about whether regulatory agencies would look favorably on a safety-critical product that may be expected to take on additional functions during its life-cycle. Perhaps the reviewers were pointing that, at that moment, the VAX11 showed more promise to allow future products to integrate more functions into a single processor than did the VIPER. However, we all know what happened to the VAX, and that microprocessors have consistently improved their performance with every succeeding generation.
Another aspect of the review was that the reviewers wanted to use floating point arithmetic, and did not particularly care for the fixed point arithmetic required with the VIPER. In fact, the report I read on this subject indicates that the fixed point arithmetic used by VIPER exhibited results with lower variance than the floating point results of the minicomputer to which it was being compared for all but two of the parameters examined. Floating point arithmetic allows programmers greater freedom from detailed analysis compared to fixed point arithmetic. In my view of floating point, this is a point that does not receive a lot of attention. To make fixed point work correctly and reliably, greater understanding of the process is required. The additional time required for this is time well spent. Invariably there will be software bugs, so for safety-critical SW, I would like to know that the developers really understood the problem they were working on.