Re: Stack based machines

Philip Koopman <koopman@cmu.edu>
25 Mar 2000 02:43:33 -0500

          From comp.compilers

Related articles
[2 earlier articles]
Re: Stack based machines dvdeug@x8b4e53cd.dhcp.okstate.edu (2000-03-25)
Re: Stack based machines pieter@cs.kun.nl (Pieter Koopman) (2000-03-25)
Re: Stack based machines galexand@sietch.bloomington.in.us (2000-03-25)
Re: Stack based machines bonzini@my-deja.com (2000-03-25)
Re: Stack based machines gneuner@dyn.com (2000-03-25)
Re: Stack based machines dxj@mnsinc.com (Deepak Janardhanan) (2000-03-25)
Re: Stack based machines koopman@cmu.edu (Philip Koopman) (2000-03-25)
Re: Stack based machines Keith@wootten.demon.co.uk (Keith Wootten) (2000-03-28)
Re: Stack based machines bpaysan@mikron.de (Bernd Paysan) (2000-03-28)
Re: Stack based machines dxj@mnsinc.com (Deepak Janardhanan) (2000-03-28)
| List of all articles for this month |

From: Philip Koopman <koopman@cmu.edu>
Newsgroups: comp.compilers,comp.arch
Date: 25 Mar 2000 02:43:33 -0500
Organization: Carnegie Mellon University, ECE & ICES
References: 00-03-101 00-03-124
Keywords: architecture, performance

[The comp.compilers moderator wrote]:
>[There have been lots of stack architectures that kept the top of the
>stack in registers, but it's my impression that performance is worse
>than real registers. Registers hold common subexpression values and
>hot loop variables as well as expression temporaries, and stack
>caching doesn't easily get either of those. -John]


Stacks work pretty well if someone takes the trouble to write a
stack-scheduling compiler. The problem has always been that
register-based machines with whizzy compilers were compared with
idiot-simple stack code -- not a fair comparison. Similarly, most of
the old "stacks are worse than registers/memory" arguments were based
on small code snippets that didn't exploit reuse of on-stack
variables, or didn't use realistic instruction sets that permitted
nondestructive accesses to the top couple stack elements. The stack
machines I worked on a decade ago were optimized for cost/performance,
not just raw performance. (But they did pretty well at raw
performance too.)


I published a paper on a first cut at such an optimizing stack
compiler back in 1994; I've since moved on to other pursuits. See:
http://www.ices.cmu.edu/koopman/stack_compiler/index.html It's
suitable for stack architectures that keep the top 2 or 3 values in
registers, which is commonly the case.


-- Phil


Phil Koopman -- koopman@cmu.edu -- http://www.ices.cmu.edu/koopman


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.