Re: fixing the c++/f77 circular dependency

Re: fixing the c++/f77 circular dependency

[Doug Evans]

   From: Alexandre Oliva <oliva@dcc.unicamp.br>
   Date: 21 Aug 1997 01:27:55 -0300

   > You could add a --enable-lang=foo [or some such] option,
   > so while LANGUAGES=x is gone, the ability to only build a few
   > is not.

   I'd rather have all languages enabled by default (as it is now), and
   configuring --without-g77, --without-g++ (is this a valid identifier,
   by the way?), etc would selectively disable them.  I could provide a
   patch for that, if you agree with it.

When I proposed and wrote a patch for --{with,without}-lang [over two
years ago] it was suggested that --{enable,disable} was more appropriate.

As for the behaviour, what's the default, etc. etc.
I don't have a strong opinion.  I realize it's reasonable
to want the default to be to install all languages.

Re: Ultrasparc addition for sparc.md (fwd)

[Jeffrey A Law]

  In message <Pine.GSO.3.96.970820232743.17387B-100000@drabble>you write:
  > 
  > Hi, All,
  > 
  > i don't know is it good idea or not to
  > forward message from gcc2 list but here it is...
A good number of us are still on gcc2, and I for one am trying
to safe interesting stuff posted to gcc2.  This counts as
interesting stuff :-)

Cygnus also has an archive of gcc2 stuff, so nothing's ever
really lost.

Jeff

Re: f/runtime/Makefile.in: mclock_.o left out of libU77

[Jeffrey A Law]

  In message <199708210305.WAA28627@mercury.xraylith.wisc.edu>you write:
  > Was there a reason to leave mclock out of libU77? If not, here's a patch
  > to f/runtime/Makefile.in:
None I can think of -- I've installed the change.

Craig -- if there's a reason we should not include this change, let
me know and I'll remove it.

Jeff

mdbench for g77 & f2c+gcc

[Oleg Krivosheev]

Hi, All

i've benchmarked g77 and f2c+gcc
using mdbench on Ultrasparc II / 200Mhz
and Pentium/133Mhz/256k cache.

g77 and gcc were build from egcs-ss-970814.tar.gz sources
with Haifa scheduler plus
Bernd Schmidt haifa patch plus
Christian ultra patch plus
Jim Wilson patch.

All numbers are averaged over five runs.
ultra and P133 both had zero load.

1. Ultra II/200 mhz

jor-el ~/work/Project/tmp$ fpversion
 A SPARC-based CPU is available.
 CPU's clock rate appears to be approximately 200.2 MHz.
 Kernel says CPU's clock rate is 200.0 MHz.
 Kernel says main memory's clock rate is 100.0 MHz.

 Sun-4 floating-point controller version 0 found.
 An UltraSPARC chip is available.
 FPU's frequency appears to be approximately 201.5 MHz.

 Use "-xtarget=ultra -xcache=16/32/1:1024/64/1" code-generation option.
 

g77 -O6 -funroll-all-loops -fomit-frame-pointer -ffast-math
-fstrength-reduce -fthread-jumps -mcpu=ultrasparc -mtune=ultrasparc
mdbnch.f

17.56 sec

not bad, huh!!! official data are

Sun Ultra 2 (200Mhz), Solaris 2.5.1, SC4.0 FORTRAN [^] ........ 15.7 s+
24Apr96

my own result with sun f77 4.2 is 16.5 sec

g77 is only ~10% slower !


f2c -A mdbnch.f

gcc -O6 -funroll-all-loops -fomit-frame-pointer -ffast-math
-fstrength-reduce -fthread-jumps -mcpu=ultrasparc -mtune=ultrasparc
mdbnch.c -lf2c -lm

25.70 sec

2. Intel P133/60ns EDO 32M/256K cache, Triton2 HX board 
   with agressive BIOS settings, Debian/hamm Linux
   with glibc 2

g77 -O6 -malign-double -funroll-all-loops -fomit-frame-pointer -ffast-math
-fstrength-reduce -fthread-jumps -mcpu=i586 mdbnch.f
 
59.58 sec

f2c -A mdbnch.f

gcc -O6 -malign-double -funroll-all-loops -fomit-frame-pointer -ffast-math
-fstrength-reduce -fthread-jumps -mcpu=i586 mdbnch.c 
-lf2c

62.89 sec

closest result here is

Pentium 586 200MHz, 256k cache, Win95, MS PwrStatn 4.0, -G5 -Ox 46.7 s
08Nov96

well, not bad either


NOTE!!! if i'll add -mno-ieee-fp option i'll get
aroung 53.5 sec for g77 and 56 sec for f2c+gcc
but first table will be wrong - some kind of numeric
instability diverges K.E. really fast.
Is it some known bug ?

in both cases g77 is a bit faster. I don't know
what is the cause of such big difference on Ultra

cheers

OK

Ultrasparc addition for sparc.md (fwd)

[Oleg Krivosheev]

Hi, All,

i don't know is it good idea or not to
forward message from gcc2 list but here it is...

OK

ps maybe someone knowledgeable will systematically
forward essential messages from/to gcc2?


---------- Forwarded message ----------
Date: Wed, 20 Aug 1997 14:00:27 +0200
From: Christian Kuehnke <Christian.Kuehnke@arbi.Informatik.UNI-OLDENBURG.DE>
To: gcc2@cygnus.COM
Subject: Ultrasparc addition for sparc.md

Hello,
here are first results of my experimnts (see comment at the end):

--- sparc.md.orig	Tue Aug 19 00:45:02 1997
+++ sparc.md	Tue Aug 19 00:45:02 1997
@@ -272,6 +272,43 @@
 ;; The multiply unit has a latency of 5.
 (define_function_unit "tsc701_mul" 1 0
   (and (eq_attr "type" "imul")		(eq_attr "cpu" "tsc701")) 5 5)
+
+;; ----- The UltraSPARC-1 scheduling
+;; The Ultrasparc can issue 1 - 4 insns per cycle; here we assume
+;; four insns/cycle, and hence multiply all costs by four.
+
+;; Memory delivers its result in three cycles to IU, three cycles to FP
+(define_function_unit "memory" 1 0
+  (and (eq_attr "type" "load,fpload")   (eq_attr "cpu" "ultrasparc")) 12 4)
+(define_function_unit "memory" 1 0
+  (and (eq_attr "type" "store,fpstore") (eq_attr "cpu" "ultrasparc"))  4 4)
+(define_function_unit "ieu" 1 0
+  (and (eq_attr "type" "ialu")          (eq_attr "cpu" "ultrasparc"))  1 2)
+(define_function_unit "ieu" 1 0
+  (and (eq_attr "type" "shift")         (eq_attr "cpu" "ultrasparc"))  1 4)
+(define_function_unit "ieu" 1 0
+  (and (eq_attr "type" "cmove")         (eq_attr "cpu" "ultrasparc"))  8 4)
+
+;; Timings; throughput/latency
+;; ?? FADD     1/3    add/sub, format conv, compar, abs, neg
+;; ?? FMUL     1/3
+;; ?? FDIVs    1/12
+;; ?? FDIVd    1/22
+;; ?? FSQRTs   1/12
+;; ?? FSQRTd   1/22
+
+(define_function_unit "fp" 1 0
+  (and (eq_attr "type" "fp")       (eq_attr "cpu" "ultrasparc")) 12 2)
+(define_function_unit "fp" 1 0
+  (and (eq_attr "type" "fpcmp")    (eq_attr "cpu" "ultrasparc"))  8 2)
+(define_function_unit "fp" 1 0
+  (and (eq_attr "type" "fpmul")    (eq_attr "cpu" "ultrasparc")) 12 2)
+(define_function_unit "fp" 1 0
+  (and (eq_attr "type" "fpdivs")   (eq_attr "cpu" "ultrasparc")) 48 2)
+(define_function_unit "fp" 1 0
+  (and (eq_attr "type" "fpdivd")   (eq_attr "cpu" "ultrasparc")) 88 2)
+(define_function_unit "fp" 1 0
+  (and (eq_attr "type" "fpsqrt")   (eq_attr "cpu" "ultrasparc")) 48 2)
 \f
 ;; Compare instructions.
 ;; This controls RTL generation and register allocation.
--- sparc.h.orig	Tue Aug 19 00:45:06 1997
+++ sparc.h	Tue Aug 19 00:45:06 1997
@@ -2707,7 +2707,7 @@
 
 #define RTX_COSTS(X,CODE,OUTER_CODE)			\
   case MULT:						\
-    return (TARGET_V8 || TARGET_SPARCLITE || TARGET_V9) \
+    return (TARGET_V8 || TARGET_SPARCLITE)              \
 	? COSTS_N_INSNS (5) : COSTS_N_INSNS (25);	\
   case DIV:						\
   case UDIV:						\


As David S. Miller recently commented, it is rather difficult to
accurately describe the UltraSPARC pipeline for gcc.

- UltraSPARC can issue up to 4 insns/cycle.
- Out of these 4
  * two can be ALU and/or branch (branch can only be in the first three)
    -     of which only one can be a shift
    - and of which only one can be a condition-code-setting op
  * one can be a load/store
  * two can be fp ops.
- Integer multiplication entirely stalls the pipeline for 4 up to
  18 (SMUL), 19 (UMUL), 34 (64-bit MULX) cycles, depending on the
  operands, hence my modification in sparc.h, could even be more
  aggressive about it (increase COSTS_N_INSNS).

With the floating point benchmark David Miller posted some days ago,
the results are as follows (on an Ultra 1/140):

gcc -O2 -mcpu=supersparc			12.35s
gcc -O2 -mcpu=cypress				12.68s
gcc -O2 -mcpu=ultrasparc			9.80s
cc -xO3 -xtarget=ultra1/140 -xarch=v8plus	8.75s
[Another commercial compiler]			9.80s

*HOWEVER*, when tested with other programs not using floating point,
the -mcpu=supersparc wins slightly over -mcpu=ultrasparc or is on par.

Any measurements or corrections or improvements are welcome.

Christian

-- 
Christian.Kuehnke@Informatik.Uni-Oldenburg.DE   | Tel.: +49 441 592 652  (home)
                                                | Tel.: +49 441 798 2978 (work)
                                                | Fax : +49 441 798 2980 (work)