Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site drivax.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!vax135!cornell!uw-beaver!tektronix!hplabs!amdahl!drivax!alan
From: alan@drivax.UUCP (Alan Fargusson)
Newsgroups: net.arch
Subject: Re: Stack architectures - why not?
Message-ID: <240@drivax.UUCP>
Date: Mon, 23-Sep-85 14:08:46 EDT
Article-I.D.: drivax.240
Posted: Mon Sep 23 14:08:46 1985
Date-Received: Thu, 26-Sep-85 08:16:27 EDT
References: <172@myriasa.UUCP> <12200021@orstcs.UUCP>
Organization: Digital Research, Monterey, CA
Lines: 54

> Stack architectures are beautiful -- to a point.  My major gripes with them
> are the following:
> 
> 1) A very heavy reliance on RPN.  Although routines can be written to get 
> around this, and some people actually like RPN, this is still a dubious 
> feature at best.  Algebraic and other forms of higher math don't work well
> in RPN, and (although I don't know about you) RPN makes logic notation far
> more confusing than it needs to be.  Since I use logic functions in a lot of
> situations, this is a hassle.  Even the If...Then structure is made more
> complex than necessary because of forcing it into RPN.
> 
> 2) Stack architectures and variables don't mix well.  Although it's not 
> impossible, dealing with stack frames to find variables and work with them,
> and using stack references for absolute variables is yet another hassle.
> 
> 3) Although this is somewhat Forth-specific, relying on the Jump rather than
> the Goto Subroutine.  Because the stack is being used for parameters, you
> can either (1) deal with unpleasant stack frames; (2) never use subroutines,
> with the inherent increase in execution time while addresses are being looked
> up and the overhead for faking a subroutine call; (3) use subroutines only
> for the very low level routines, and then you get stuck with all the 
> disadvantages of (1) and (2).

I worked with an HP3000 for several years and didn't find any of these things
to be a problem. Of course I mostly used high level languages, but I did write
some assembler also. Most compilers convert the algebraic notation to something
else, like RPN or FPN, anyway.

> 4) It is very difficult to use multiple dynamic data spaces on a stack machine.
> Again, it's not impossible, but stack machines are designed against it.
> 
> Note:  These opinions are based on writing a Forth for the 68000, where you can
> have all the stacks/heaps that you want; writing a Forth for the 6502, whcih
> has an unpleasant and unreliable indirect jump, thereby forcing self-modifiying
> code (which has it's place, but still); writing a Forth for the 6809, which
> has a two stacks (eliminating (3) above); and 6 years of programming 
> experience on most of the microprocessors running around and several larger
> machines.  I'm sorry, I'd far prefer a register architecture which works to
> either a memory architecture or a stack machine.
> 
> 				orstcs!richardt
> "What shall we do with a stack machine,
> 	Stack Machine, Stack Machine,
> Er-ly in the morning?"   <-- I consider Stack machines to be on about the level
> 					of a drunken sailor.

I don't quite follow your argument. You seem to be saying that since it was
hard to implement forth on a 6502 it must be hard to implement it on a stack
machine. I don't agree with that.
-- 

Alan Fargusson.

{ ihnp4, amdahl, mot }!drivax!alan


Brought to you by Super Global Mega Corp .com