🚀 go-pugleaf

Caution: about to put foot in mouth :-)

For the person who claims that stack-based architecture is not compatible
with pipelining, I have some questions, which may be naive.

Does not pipelining operate most efficiently when it is able to keep
chugging along without any branching?
Even when it is chugging along w/o branching, for how long can it go w/o
requiring that an operand be brought into a register, from the cache?
I would assume that the term load/store-architecture implies that cache
access is fairly frequent. (Ignoring the worse impact of a cache miss)

Your argument seems to rest on data-dependency.  However, I don't quite
understand how this presents more of a problem for stack-oriented design
than for register-oriented.  Do not compilers address this problem by
scheduling instruction issue so that instructions which are dependant on
previous results get placed after some other intermediate non-dependant
operation.  (I'm a little fuzzy on the details, here.)

H&P do state 2 advantages of stacks, and they are correct in claiming that lack
of random-access is a hassle to deal with. 
However, their table on page 92 seems to have some underlying assumptions,
some of which you also seem to hold:
	*CPU has either a stack or a register file, but not both.
		(Which I would consider an extremist notion.)
	*only a single-stack per CPU.
		(With 3, you could have 2 operand and 1 result stacks.)
	*many small chunks of data structures needing random access,
		rather than chunks being processed sequentially.
		(OK, only use stacks for those tasks at which they are good.)
	*Inflexibility in access is only a liability.

(I'm probably about to get athlete's mouth, here. :-) 
That inflexibility gives considerable predictability about which bytes would
next need to be brought from the MMU or cache and presented to the register
bus.  A bi-directional (i.e. reversible) circular queue of registers could be
used to implement parallel+interleaved access to slow memory, and would have
better access than ANY caching scheme.  Perhaps think of it as a cache with a
mere handful of tiny, interleaved pages, which have implied page addresses that
don't need to be checked for hit or miss, since they are guaranteed hits.

I am making the assumption of a multi-word-wide data path between the queue
and slow memory, so as to allow parallel accesses.  In other words, the banks
which are interleaved are several words wide.  The data-path between the queue
and the port where the stack presents itself to the register bus might only
need to have a width of one word, although it might need to operate at
register-transfer-level speed.

(The first hurdles to this sort of notion, is that if the queue resides on the
CPU, then there are not enough pins, but if it resides off the CPU chip, then
the pins have to be driven at toggle rates well over 100MHz.  These may be
hurdles, but innovative engineers will find ways to overcome the obstacles.)

Using a circular-queue would give at least the performance of a cache, without
the overhead.  In fact, it would probably beat a cache, in terms of latency.
Caches are used because you can't absolutely predict where the next memory
access will be, but you have a good idea that you will probably go back to
something you recently accessed.  As I said before, that inflexibility of
access for a stack gives considerable predictability about which data would be
accessed next.  (In case this is a clarifying point, I am talking about
bypassing the cache, but not bypassing the MMU.)

I'm not suggesting an architecture which is predominantly stack or register
oriented, but something which has a balance between them.  I don't think
that most conventional designs can be considered balanced.  I think that
hardware support for stacks has been allowed to slip by those who are
"innovation-impaired" (tm)  I think that to suggest that history has 
issued a verdict that register files have won out over stacks is actually
an admission of not knowing how to take full advantage of stacks.

For the register-oriented die-hards ;-) please consider this advantage of
increased efforts in stack design.  Every time you do a context switch or
any other sort of major branching, your beloved registers  :-P  get pushed
out to the stack.  Have you made that stack a nice place for your registers
to go through?  Now, the typical memory hierarchy
	REGISTERS<->CACHE<->DRAM<->DISK
has its optimization trying to improve the tendency of more frequently used
data to reside closer to the high-speed end.  But the word "tendency" clues
you in to the fact that this is statistical optimization for RANDOM accesses.
The cache works so hard at trying to optimize random accesses that it gets
in the way of predictable SEQUENTIAL accesses.  You die-hards do want your
beloved register contents to be handled as efficiently as possible, don't you?
If you treat the interface between your stack-operations and memory (i.e. 
through the cache) the same as your interface between register loads/stores,
then does it not come back to haunt you, when your register context must be
pushed onto the stack?  Why not have an additional hierarchy:
	STACKS<->INTERLEAVED_LIFO<->DRAM<->DISK
such that the result is:

         /->REGISTERS<->CACHE<-\
      ALU                       MMU<->DRAM<->DISK
         \->STACKS<---->QUEUE<-/

OK, show me the errors of my ways :-)
-Ken Cleary.

(Donning Flame-Proof Suit ;-)
(Feel free to let loose ;-)