Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site myriasa.UUCP
Path: utzoo!linus!decvax!harpo!whuxlm!whuxl!houxm!ihnp4!alberta!myriasb!myriasa!cg
From: cg@myriasa.UUCP (Chris Gray)
Newsgroups: net.arch
Subject: Stack architectures - why not?
Message-ID: <172@myriasa.UUCP>
Date: Thu, 5-Sep-85 11:48:37 EDT
Article-I.D.: myriasa.172
Posted: Thu Sep  5 11:48:37 1985
Date-Received: Thu, 12-Sep-85 22:44:18 EDT
References: <796@kuling.UUCP>
Organization: Myrias Research, Edmonton
Lines: 46
Keywords: Stack architectures

First, keep in mind that I'm a compiler writer by trade, so I like the
idea of a pure stack architecture because it's so easy to generate code
for (I did it for a machine I designed and emulated).

I've been told by a couple of people who are normally well informed that
a pure stack architecture just isn't practical. They have NOT been able
to convince me of this. Anybody out there want to try?

You say that a stack machine spends far too much time accessing the stack
in memory. Easy - have the top, say, 100 values of the stack in on-board
registers.

You say the large register set requires too much flushing on a task
switch (or redundant stores if you do it in the background). Simple -
don't flush it so much; have about 4 of them, with control over the
flushing policies that are to be used. One can be reserved for the
supervisor, and is only flushed if there is no bus activity at all. Also,
when the on-board top-of-stack is close to being full (90%?), the far top
end of it can be written out (NOT flushed) during any idle bus cycles.
The remaining top-of-stacks are used for user tasks (it may be better
to have more of them, but smaller - depends on how often you task switch
and on how many tasks you plan on having). They still need not be write-
through, but would want the same "write on nearly full" policy. The stack
sets for non-active user tasks can be written out whenever convenient,
probably in LRU order (the goal would be to have an clean one (all modified
values written out) when one is needed for another task).

All those registers won't fit on available chip real-estate. Well, given
that all of your normal registers and most of your addressing modes go
away, there should be lots of space. (This very similar to the RISC
argument that gives you lots of room for registers when you simplify
the instruction set.)

You can't take the address of one of the stack elements (at least not
without a lot of support hardware). Fine. I'm quite willing to have the
compiler allocate some variables in non-stack storage. I'm even willing
to have to explicitly tell the compiler which ones (sort of the inverse of
the way 'register' is treated in C). This may mean having two stacks - one
for "small" variables and one for those whose address is needed. Again,
I say fine. The same holds for variables shared between tasks ('volatile'
in the new C).

There are lots more considerations (e.g. interaction with VM), but this
should give you lots to shoot at. What obvious things am I missing?

		Chris Gray    {...,ihnp4}!alberta!myrias!cg