home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!cbmvax!jesup
- From: jesup@cbmvax.commodore.com (Randell Jesup)
- Newsgroups: comp.arch
- Subject: Re: RTX and SC32
- Message-ID: <36797@cbmvax.commodore.com>
- Date: 8 Nov 92 00:51:57 GMT
- References: <17131@mindlink.bc.ca> <1992Nov4.191038.12063@news.arc.nasa.gov> <1dcvsmINNiop@uniwa.uwa.edu.au> <1992Nov6.131717.15715@walter.bellcore.com>
- Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
- Organization: Commodore, West Chester, PA
- Lines: 25
-
- mo@bellcore.com writes:
- >"Stacks always go in memory, and you always go to the stack."
-
- >What I have not seen in the literature (which doesn't mean it doesn't
- >exist, just that i haven't seen it) is a comparison of a stack machine
- >design with the equivalent complexity budget of modern RISC machines
- >to such modern processors. By complexity budget I mean one that spends
- >as much logic on cache and memory system complexity as the fast RISC
- >machines do. (including the related trickle-down complexity like
- >dealing with out-of-order completion in the pipe, if required)
-
- Actually, I would also count the register file (which, combined with
- the data cache, is the equivalent of the stack cache/data cache of a stack-
- based machine - and register files often eat up a lot of space and complexity
- on classical RISCs).
-
- It would be interesting to see if there are any good solutions; not
- many people have looked into it very seriously recently.
-
- --
- To be or not to be = 0xff
- -
- Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
- {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup
- Disclaimer: Nothing I say is anything other than my personal opinion.
-