Path: utzoo!attcan!uunet!husc6!bbn!rochester!pt.cs.cmu.edu!k.gp.cs.cmu.edu!lindsay
From: lindsay@k.gp.cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: typical programs
Message-ID: <1763@pt.cs.cmu.edu>
Date: 26 May 88 15:08:21 GMT
References: <1521@pt.cs.cmu.edu> <1532@pt.cs.cmu.edu> <476@pcrat.UUCP> <9561@sol.ARPA> <1658@pt.cs.cmu.edu> <1035@astroatc.UUCP>
Sender: netnews@pt.cs.cmu.edu
Organization: Carnegie-Mellon University, CS/RI
Lines: 25
Keywords:a=b

In article <1035@astroatc.UUCP> johnw@astroatc.UUCP (John F. Wardale) writes:
>People claim stack machines can give you fast execution and dense code.
>I have two arguments against this:
>1: Code Size
>	Several studies yield overwelming evidence that almost all code
>	takes on of these three forms:
>	1: a=b    2: a=a+b    3: a=b+c    (+ is an operation)
>
>	Stack based code gains NOTHING in these cases.  Mem-to-mem code wins!


A cautionary note. The studies said that the code TOOK THE FORM OF
	a=b+c
but they considered
	a[i] = b[i,j] + c[j]
to have had that form. So, any discussion should talk about addressing
modes, about loops, and about effects that architecture have on 
compiler optimizations.

I've been told that some stack machines essentially prevented common
subexpression elimination. (Where to put the temporary?) But, I assume
this wasn't a problem on the HP3000, which had (very limited) random access
down into the stack.
-- 
	Don		lindsay@k.gp.cs.cmu.edu    CMU Computer Science