Xref: utzoo comp.lang.c:26998 comp.lang.misc:4502
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!brunix!drc
From: drc@cs.brown.edu (David R. Chase)
Newsgroups: comp.lang.c,comp.lang.misc
Subject: Re: function calls
Message-ID: <33150@brunix.UUCP>
Date: 17 Mar 90 07:59:18 GMT
References: <29509@amdcad.AMD.COM> <12350@goofy.megatest.UUCP>
Sender: news@brunix.UUCP
Reply-To: drc@cs.brown.edu (David R. Chase)
Organization: none
Lines: 19

In article <12350@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes:
>What I would like to see is a register-set that acts as the cache for
>a virtual stack in a machine with true stack machine instructions. That
>would be my idea of a really good time, although it might put some graph
>colorers out of business, having no registers to allocate.

Not at all.  No doubt the "hardware stack" will be of finite size, and
if that is exceeded then some of it must be saved to memory.  In this
situation, you'll win if stack frames aren't so large, and one way to
do that is to allocate stack slots using algorithms very much like
those used to allocate registers.  Spilling won't occur, of course,
since you can have as many "registers" as are needed, but they don't
come for free.  Use fewer and (ignoring scheduling problems caused by
spurious dependences on reused registers) do better.

Hard life, isn't it?

David
(really in Menlo Park, CA)