Xref: utzoo comp.lang.c:27066 comp.lang.misc:4531
Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dogie.macc.wisc.edu!decwrl!amdcad!nucleus!tim
From: tim@nucleus.amd.com (Tim Olson)
Newsgroups: comp.lang.c,comp.lang.misc
Subject: Re: function calls
Message-ID: <29552@amdcad.AMD.COM>
Date: 19 Mar 90 15:48:27 GMT
References: <29509@amdcad.AMD.COM> <12350@goofy.megatest.UUCP>
Sender: news@amdcad.AMD.COM
Reply-To: tim@amd.com (Tim Olson)
Organization: Advanced Micro Devices, Inc., Austin, Texas
Lines: 15
Summary:
Expires:
Sender:
Followup-To:

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. Does anybody
| know if such a scheme was proposed for SPARC, and if so, why it was
| rejected? Seems like such a win, and not all that big a step
| beyond the register-window approach.

This was the approach used in the AT&T CRISP processor.


	-- Tim Olson
	Advanced Micro Devices
	(tim@amd.com)