Re: F21/P21 "improvements"?

[fox@xxxxxxxxxxxxxxxxxxx (Jeff Fox)]

Dear MISC readers:

Mark wrote:
>	I have looked at the instruction set for the F21 and found that for a class
>of problems relating to vectors, it is not clear to me how to easily handle
>3 memory addresses for doing X op Y -> Z.  The A and R registers can perform
>as two of the address registers.  I propose (at the expense of using some of
>the unused opcodes in the base 32) that a second address register B that is
>logically stacked below A, but which has access to memory might be useful.
>The additional instructions would be @B+ and !B+.  The A instruction would
>be modified to push the current value of A into B and pop T into A.  The A!
>instruction would be modified to push the current value of A into T and pop
>B into A with B remaining unchanged.  I don't claim to fully understand the
>architecture and I may be missing something.  I also understand that adding
>something to a "Minimal" instruction set seems odd.  I hope this isn't an
>old idea from before I started monitoring this list.

It is in fact a pretty old idea.  On the list of instruction set and
architecture changes that I made over the years I got some in the
P20 to P21 phase and the P21 to F21 phase.  One of my proposed
enhancements was some variation of the address stack.  that is, make
the A register a stack if only a couple deep and a way to pop and
push it.  A similar variation would be a B addressing register.
The register also could function as fast storage.  

There is the subtile problem that instructions are decoded as to
whether they are memory access instructions in parallel to the
first instruction decoding to determine when and if instruction
pre-fetch will be possible.  A bit determines if instructions
are memory access or not memory access.  There is the 32 
instruction (5 bit) issue (although the same 5 bits could have
different meanings in different slots but ... ) and the issue
that B! would not be a memory access and !B and !B+ would and
they all have to be fit into the instruction set.

Other than that it seems like a reasonable variation to consider.
Chuck has shyed away from it saying that it doesn't appear at
the top of his list for CPU enhancements.

I think enhancements to coprocessors are more in order as the
CPU is already pretty tweaked.  The big bottleneck is the
memory interface and the video bandwidth could be signifigantly
decreased with some enhancements to that processor.  When testing
of the Analog and serial/network coprocessors on this prototype
are complete we will now more about potential improvements to those
circuits.  Other than the thermal fix for the CPU I am mainly
interested in any easy enhancments to I/O coprocessors or to an
I/O coprocessor modifaction to suit a particular problem.

Even at .8u we have been getting 500Mips internally.  We have
only been getting a maximum of half the memory bandwidth to
do that and often a quarter or an eight of that much memory
bandwidth available to the CPU.  Going to .35u the CPU should
be a bit faster and even more in need of a faster memory 
interface.  We all know that memories are a lot faster now than
they were when F21 was designed.  The advantage of optimization
there is that it works across all instructions in the CPU and
with all the I/O coprocessors as well.

Changing to a different type of memory would require a different
pinout and most likely more pins.  more pins is not much of an
issue at this point.  we could still go to a smaller package
with more pins that the current 68pin package.  

Chuck has been working on doing board layout in OKAD so that he
can design the chip fit right up to the right kind of memory 
chips and connect on a one layer board.  He is trying to save
a buck or two on the circuit board.  This is an issue.  When
you get a chip really cheap then every other little component
becomes more important to the overall price and needing extra
layers costs more in production parts.

Jeff Fox