Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: $Revision: 1.6.2.16 $; site pbear.UUCP
Path: utzoo!linus!decvax!cca!pbear!peterb
From: peterb@pbear.UUCP
Newsgroups: net.arch
Subject: Re: What I miss in micro-processors (fai
Message-ID: <600010@pbear.UUCP>
Date: Wed, 11-Sep-85 20:31:00 EDT
Article-I.D.: pbear.600010
Posted: Wed Sep 11 20:31:00 1985
Date-Received: Sun, 15-Sep-85 04:43:44 EDT
References: <796@kuling.UUCP>
Lines: 92
Nf-ID: #R:kuling:-79600:pbear:600010:000:4887
Nf-From: pbear!peterb    Sep 11 20:31:00 1985


/* Written 11:48 am  Sep  5, 1985 by myriasa!cg in pbear:net.arch */

>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).

Yes that's true, but the speed of that "simple-to-generate" code is quite
expensive. No matter how you cut it, you still have to optimize the code
no matter how fast the hardware is since someone is going to want a faster
and cheaper version of the same thing.

>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?

A PURE stack environment has no static variable space, so it is quite
expensive to access variables ACROSS stack frames by following static links,
or by using a display to access a constant address variable. Also on
procedure calls, the hardware has to spend a bit of bus bandwidth and time
building up the display to keep the static scope of the program intact.
There are ways around it by having two types of procedures: those that call
others, and those that are "leafs"(don't call any others). For the ones that
don't call, there is no need to set up a new stack frame since the last on
is still usable.

Also PURE stack environments have no registers, so much of the time is
spent accessing the top of stack.

Also in a pure stack environment, IO has a real problem since there are no
addresses, or if there are, there is no way to fix them are compile time.

>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.

No, you don't need that many, 8 would do just fine. Look at the HP RPN
calculators. They only have a 4 deep stack, and can do quite a bit with it.

>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).

See above, Also you can keep one in reserve and suspend execution until
stack space is available. It would actually be simpler to put a cached MMU
in between the memory and the processor. Then when you fault, you can switch
tasks with only two register changes (stack pointer and program pointer) and
two page swaps (one for code, other for TOS). Then fault in the other
information.

>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.)

More registers are expensive in operation costs. As above it gets real
complex to force the flush of this huge register set or time to writes
at idle bus times (which would then take up the real esate that the
registers sit on). So if you use huge register sets, you pay in complexity
and cost of operation.

The RISC arguement is that in simplifying the instruction, the speed of the
system can be increased.

>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).

arrghhh, again, have the stack be pointing into a datazone with fixed
addresses. this way the static data can be at one end(like floating and
string constants), and the stack grow in from the other. Also the address
of a variable is then simply a true address, with no pain.

Peter Barada
{ihnp4!inmet|{harvard|cca}!ima}!pbear!peterb