Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!world!iecc!compilers-sender
From: ressler@cs.cornell.edu (Gene Ressler)
Newsgroups: comp.compilers
Subject: SPARC code generation references
Keywords: bibliography, SPARC, optimize
Message-ID: <91-05-100@comp.compilers>
Date: 24 May 91 19:54:45 GMT
Sender: compilers-sender@iecc.cambridge.ma.us
Reply-To: ressler@cs.cornell.edu (Gene Ressler)
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Lines: 109
Approved: compilers@iecc.cambridge.ma.us

A couple of months ago I posted asking for SPARC code gen references.  Sorry
for the delay.  Here are the non-redundant replies I received.  In fact our
need went away, so none of these have been thoroughly tested.  We've since
heard that the SUN manual mentioned in the first reply is good albeit scarce.
Someone here also reviewed the Oberon material suggested, finding it to be
useful, but certainly not a basic source.  There have also been posts in
response or otherwise related; they aren't repeated here.

Gene

-----

From mwb2c@euclid.acc.virginia.edu Thu Mar 21 02:09:31 1991

With regard to your post requesting SUN specific references for optimizing
code for a SPARC, have you seen the SPARC Architecture Manual which SUN
publishes (Version 8 is the most recent).  It's a good place to start and
includes a great deal of assistance to those writing software (Appendix D,
Software Considerations).  I just finished a code generator for the SUN IV
and found this manual REALLY useful.  It was rather difficult to get a hold
of however, since it was just published in December (and as of mid-January,
no one at SUN had any idea what it was).  If you want more information on who
to call, part #, etc., let me know.

-----

From larry@titan.tsd.arlut.utexas.edu Thu Mar 21 08:45:12 1991

Theere is a SPARC version of OBERON available via anonymous ftp at
129.132.101.33.  It discusses optomization on the SPARC and tricks they used
to beat the the native C compiler on the SPARC.  You might download their
documentation.

-----

From cargo@cherry.cray.com Thu Mar 21 09:50:24 1991

I note (in the recent BYTE) that there exists SPARC International, 535
Middlefield Road, Menlo Park, CA 94025, (415) 321-8692, Internet:
info@SPARC.COM.

-----

From pardo@cs.washington.edu Thu Mar 21 16:46:02 1991

I have heard that every existing SPARC predicts branches taken.

%T The SPARC Architecture Manual Version 8
%R Sun Microsystems Part Number 800-1399-12

Page 237: Fill delay slots, Space out fp instructions, make consecutive
instructions independent, avoid consecutive stores.

Page 287-294: Implemetation Characteristics for Fujitsu0, Cypress0, Cypress1,
BIT0, Matsushita0.

Look in back issues of comp.compilers -- sometime in the past 1-2 months
there was a brief analysis of ld vs. ldd performance.  It might have come
from the above manual.

The LSI logic windowed dataflow SPARC chip will perform immediate branches
(call) much better than indirect (jmpl) branches because it prefetches a long
way.  Conditional branches predicted as taken applies doubly here -- more
(dependence on) prefetching means higher penalties for mis-predicted
branches.  The LSI probably has a branch cache.

Cache size is an important consideration if you are e.g., unrolling loops.
Consult your manufacturer.

Non-leaf procedures can be optimized if non-leaf behavior is uncommon.  That
is,

      int
    foo (int *a, int *n)
    {
      if (*n == 0)
	reload (a, BUFSIZE);
      --*n;
      return (a[*n]);
    }

is compiled by all compilers I know of as:

    save
    test
    branch
    call
  norefill:
    sub
    index
    ret
    restore

or some such.  Faster on average is:

    test
    branch
    save	// moved
    call
    restore	// moved
  norefill:
    sub
    ret
    index

but harder to determine when it is profitable.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.