home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.arch:10469 comp.lang.forth:3451
- Newsgroups: comp.arch,comp.lang.forth
- Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!elroy.jpl.nasa.gov!swrinde!ringer!news
- From: braker@ennex1.eng.utsa.edu (Jim Brakefield)
- Subject: Re: What's wrong with stack machines?
- Message-ID: <1992Nov6.182326.12025@ringer.cs.utsa.edu>
- Keywords: register allocation, stack cache
- Sender: news@ringer.cs.utsa.edu
- Nntp-Posting-Host: ennex1.eng.utsa.edu
- Organization: Univ of Texas at San Antonio
- References: <1992Nov6.094639.28441@email.tuwien.ac.at>
- Date: Fri, 6 Nov 1992 18:23:26 GMT
- Lines: 21
-
- In article <1992Nov6.094639.28441@email.tuwien.ac.at>
- anton@mips.complang.tuwien.ac.at (Anton Martin Ertl) writes:
- > |> The problem is that there hasn't been enough work done on stack
- languages.
- >
- > Or on stack machines.
- >
- There is a perspective on RISC/register based architectures and CISC
- and/or stack based machines. It is: when and how do you do register
- allocation. On a RISC machine the compiler does it. On a stack machine
- the hardware does it on-the-fly, i.e., a particular data value or variable
- gets allocated to a specific hardware register during execution. Thus
- the debate reduces to something similar to the virtual memory debate of
- 10 years ago: Is hardware memory management efficient enough to displace
- programmer memory management? (notice the context for virtual memory
- debate was ram <-> disk I/O, for stack machines it is registers <-> ram
- I/O).
-
- James C. Brakefield
- braker@ennex1.eng.utsa.edu
- signal space >> address space >> symbol space
-