Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!bbn!rochester!crowl
From: crowl@cs.rochester.edu (Lawrence Crowl)
Newsgroups: comp.arch
Subject: Re: RISC vs CISC on Low-End Processors
Keywords: RISC, real-time
Message-ID: <10074@sol.ARPA>
Date: 26 May 88 19:12:23 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>
Reply-To: crowl@cs.rochester.edu (Lawrence Crowl)
Organization: U of Rochester, CS Dept, Rochester, NY
Lines: 40

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:  (From "The Case Against Stack-Oriented 
>Instruction Sets" G. Myers @ IBM (SIGCA-August 77) and other stuff.)

The proposal for stack machines was in the context of low-end processors.  One
key feature of such a machine are that there is a low bandwidth to memory.

>Code Size: Several studies yield overwelming evidence that almost all code
>    takes on of these three forms: a=b  a=a+b  a=b+c  (+ is an operation)

You forgot a[i] and p->a which are compiled as expressions but do often appear 
in the "overwelming evidence" cited above.  I think that the Burroughs stack
machines compiled to half the size of their contemporaries.

>Speed (pipelining / scheduling): Since all the operands and results share 2 or
>    3 entries on the stack, it's very hard to have any parallelism.  With a
>    register machine you have lots of registers to avoid these conflicts.  In
>    other words register machines encourage scheduling; stack machines prevent
>    it.

The pipelining is moot when the memory bandwidth to the processor is low
enough so that the processor has spare time to process instructions.  Remember,
the processor is feeding off relatively slow memory.  Instruction scheduling
would only mean that the processor spent a larger fraction of its time waiting
on memory.  Hardly worth the effort.

>Scientific advances in SW and HW have provided us better ways of doing things,
>these ways just happen to NOT be very compatable with stack architectures.
>(The Model T [car] was good in it's day, but they're not used much any more.)

Advances have provided us with ALTERNATIVES, each more suited to certain
environments and technologies.  The stack machine was proposed in the context
of an environment different from that which you are evaluating it.  "Better"
is relative.

-- 
  Lawrence Crowl		716-275-9499	University of Rochester
		      crowl@cs.rochester.edu	Computer Science Department
...!{allegra,decvax,rutgers}!rochester!crowl	Rochester, New York,  14627