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!yale!pbear!peterb
From: peterb@pbear.UUCP
Newsgroups: net.arch
Subject: Re: Re: Stack architectures - why not?
Message-ID: <600011@pbear.UUCP>
Date: Wed, 9-Oct-85 22:21:00 EDT
Article-I.D.: pbear.600011
Posted: Wed Oct  9 22:21:00 1985
Date-Received: Sat, 12-Oct-85 06:25:49 EDT
References: <806@nmtvax.UUCP>
Lines: 45
Nf-ID: #R:nmtvax:-80600:pbear:600011:000:2276
Nf-From: pbear!peterb    Oct  9 22:21:00 1985


/* Written  2:55 pm  Oct  8, 1985 by nmtvax!blaine in pbear:net.arch */
/* ---------- "Re: Stack architectures - why not?" ---------- */
In article <1260> cg.myriasa.UUCP (Chris Grey) writes:
>> 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?
>
>
>The essential thing to remember is that a stack instruction set does not
>need to imply a stack processor design.

	True, I wrote a compiler for a simple stack machine based around a
modula-2 syntax, for the 8088 chip that has no "general" registers, and I
found it rather easy to implement code that runs just about as fast as it's
comperable C-code. (Both running under PC/IX) All I did was to keep the top
two stack operands in registers (TOS in AX, next TOS in CX where possible).
Then map operands into registers backwards using an optimizer to cut down on
redundant MOV instructions.

	With this philosophy, much of the drudgery of the 8088 architecture
is removed from the user standpoint, and even the compiler need not know if
it, just the code selection/generation/optimization phases.

	My simple optimizer was a peephole optimizer for register
utilization that ran until it could not optimize further, (or by an option,
stop at a percentage of optimization).

	My next step is to modify the compiler to produce parse trees
that make logical expressions easier to use by implementing the operations
as tree operations rather than stack operations as used by much of the past.
Also a register mask set will be propagated throughout the tree making the
allocation of appropriate registers quite straight forward. The pass for
register allocation/utilization can follow most if not all of the code
optimizations based upon code reordering, and subexpresssion collections.

	I've been ramblin, but I would like to see if there is interest in a
newsgroup for compiler subjects(probably called net.compiler) that would
cover the more "black magic" topics of register allocation, LR parser error
recovery, Stack machine to non-stack machine mapping, etc...

	Mail me some ideas, and I'll rehash to the net.

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