Xref: utzoo gnu.gcc:1987 comp.arch:18246
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!boulder!grunwald
From: grunwald@foobar.colorado.edu (Dirk Grunwald)
Newsgroups: gnu.gcc,comp.arch
Subject: single register window sparc
Message-ID: <26509@boulder.Colorado.EDU>
Date: 19 Sep 90 02:29:34 GMT
Sender: news@boulder.Colorado.EDU
Reply-To: grunwald@foobar.colorado.edu
Distribution: gnu
Organization: University of Colorado at Boulder
Lines: 27


me 'n the boys was sittin' round today wondering how anyone was going
multiport a SPARC register file enough to make a superscalar SPARC
machine.  Only way we could think of was to get bigger silicon or
reduce the number of windows.  The current crop of SPARC
implementations don't fare well on the CPI count, and superscalar
would appear to be the logical step (unless they're not doing
something that everyone else is doing).

So we got to wondering just how much measurable advantage the register
windows have. Granted, we've read the RISC I/II papers and Stankovics
register-windows-are-good-for-lisp-but-only-by-10% paper, but it would
seem easy to change 'gcc' to use a single register window and avoid
register save/restore traps.

In particular applications, e.g., a threads package, this might save a
lot of context saving time, since, although you still need to invoke a
window flushing trap (unless you compile everything with the new
compiler), the trap probably won't do anything.

So, has anyone changed the tm-sparc.h file in gcc to do this? Have you
run comparison benchmarks w.r.t. full windowing sparc? If I'm correct,
you *should* be still able to call library routines and the like; only
new code would not use register windows.

Dirk Grunwald -- Univ. of Colorado at Boulder	(grunwald@foobar.colorado.edu)
						(grunwald@boulder.colorado.edu)