SPARC code generation for compiler course

mackey@cse.ucsc.edu (Wesley Mackey )
Fri, 10 Dec 1993 02:55:04 GMT

          From comp.compilers

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)
Sparc Architecture lou@central.cis.upenn.edu (1993-12-14)
Summary of Information Available on Sparc-family processors kelvin@cs.iastate.edu (1993-12-14)
Re: SPARC code generation for compiler course salomon@silver.cs.umanitoba.ca (1993-12-15)
[4 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers,comp.arch
From: mackey@cse.ucsc.edu (Wesley Mackey )
Keywords: architecture, courses, sparc, question
Organization: University of California, Santa Cruz (CE/CIS Boards)
Date: Fri, 10 Dec 1993 02:55:04 GMT

I'm teaching a course in code generation next quarter and am looking for
SPARC documention which is more student oriented than the hardware
manuals. They give a complete and exhaustive treatment of the instruction
set whereas I need a more cookbook approach along with an architectural
description that can be passed out to students without expecting them to
read for hours and hours. Students are at a level where they have used
flex and bison in a course on scanning and parsing.


Also, is there any documentation about %global and %floating register
conventions? I've seen a reference to a SPARC ABI, but nothing complete.
Specifically, are they caller-preserved or callee-preserved? Use of the
%o, %l, %i regs are obvious from the architecture. Any detailed
description of the memory stack frame conventions? We will likely be
using gcc libraries and assembling with gas or the gcc option which calls
gas.


A preferable source would be in electronic form with no copyright or a
GNU-style copyright. *.tex or flat ASCII would be best, but we can
certainly handle postscript.


Wesley Mackey
mackey@cse.ucsc.edu
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.