Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!JATO.JPL.NASA.GOV!earle
From: earle@JATO.JPL.NASA.GOV (Greg Earle - Sun Software Support)
Newsgroups: gnu.gcc
Subject: Porting gcc to the new Sun SPARCstation 1 and SPARCstation 300 series
Message-ID: <8905030323.AA27122@jato.Jpl.Nasa.Gov>
Date: 3 May 89 03:23:07 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 27


For anyone (FSF, whomever) considering porting gcc to the new SPARC-based
Sun workstations that we just released (SPARCstation-1 a.k.a. Sun-4/60; and
the SPARCstation/SPARCserver 300 series, a.k.a. Sun-4/330, Sun-4/370, and 390)
you may be interested in the following fact:

The Sun-4/260 has a write-back cache, and thus it is not bothered by any
back-to-back writes done by a program.

On the other hand, the new SPARCstation machines have a write-through cache.
Both write buffers are only one write deep.  On the SPARCstation-1, it is
32 bits deep; on the SPARCstation/SPARCserver 300 series, it is 64 bits deep.
Because of this, back-to-back writes can tie up the memory bus.

Sun's next version of the FORTRAN compiler was modified to know about this.
I don't believe the C compiler was, however.  Given this knowledge, if it is
possible to modify the SPARC version of gcc to know about this somehow, I
hope that this provides enough information to be able to work around this
somehow.  I don't know enough about compiler technology to know how one would
recognize a back-to-back write taking place in code generation; I hope someone
out there does.

	- Greg Earle
	  Sun Microsystems, Inc.
	  JPL on-site Software Support
	  earle@Sun.COM
	  earle@mahendo.JPL.NASA.GOV	(Guest)