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 Brought to you by Super Global Mega Corp .com