Related articles |
---|
SPARC code generation for compiler course mackey@cse.ucsc.edu (1993-12-10) |
Re: SPARC code generation for compiler course salomon@silver.cs.umanitoba.ca (1993-12-13) |
Re: SPARC code generation for compiler course chase@Think.COM (1993-12-13) |
Re: SPARC code generation for compiler course markt@harlequin.co.uk (1993-12-14) |
Re: SPARC code generation for compiler course salomon@silver.cs.umanitoba.ca (1993-12-15) |
Re: SPARC code generation for compiler course pardo@cs.washington.edu (1993-12-16) |
Re: SPARC code generation for compiler course nickh@harlequin.co.uk (1993-12-16) |
Re: SPARC code generation for compiler course chase@Think.COM (1993-12-16) |
Re: SPARC code generation for compiler course pardo@cs.washington.edu (1993-12-17) |
Newsgroups: | comp.compilers,comp.arch |
From: | salomon@silver.cs.umanitoba.ca (Daniel J. Salomon) |
Keywords: | architecture, courses, sparc |
Organization: | Computer Science, University of Manitoba, Winnipeg, Canada |
References: | 93-12-040 93-12-053 |
Date: | Wed, 15 Dec 1993 18:18:43 GMT |
I wrote:
> One important point is not to use the program stack for temporaries.
> The SPARC expects the stack structure to be consistent at all times so
> it can save overflow register windows properly.
Many readers have misinterpreted this statement. What I was actually
warning against was using the top of the stack for expression evaluation,
like in a real stack machine. Some of my students were doing this and
always getting their stack values clobbered by register saves. The top of
the stack must be kept ready to to hold saved registers. You can still,
of course, use the stack for holding local variables, as long as they are
only semi-dynamic.
--
Daniel J. Salomon -- salomon@cs.UManitoba.CA
Dept. of Computer Science / University of Manitoba
Winnipeg, Manitoba, Canada R3T 2N2 / (204) 474-8687
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.