Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!dimacs.rutgers.edu!seismo!ukma!wuarchive!sdd.hp.com!hp-pcd!hpfcso!mjs
From: mjs@hpfcso.HP.COM (Marc Sabatella)
Newsgroups: comp.sys.hp
Subject: Re: HP9000 performance
Message-ID: <7370295@hpfcso.HP.COM>
Date: 31 Jan 91 17:43:19 GMT
References: <13092@sunquest.UUCP>
Organization: Hewlett-Packard, Fort Collins, CO, USA
Lines: 74

>    	">"  =  terry@venus.sunquest.com (Terry R. Friedrichsen)
>    	"&"  =  thoth@reef.cis.ufl.edu (Rob Forsman)
>    	"$"  =  bb@math.ufl.edu (Brian Bartholomew)

>    $ Our site has the most experience with 300 and 400 series, which are
>    $ Motorolla 68K based machines.  Note that the 200, 300, and 400 series
>    $ are all binary compatible, which tells me that the HP code is not
>    $ taking advantage of the opcode improvements of the later 68K's.

This is not true.  They are "upwards compatible" only.  For several releases
now the 300 compilers generate 68020/68030 specific code.  The opcode
improvements on the 68040 are minimal (move16 primarily) so we do not currently
emit 68040-specific code.  However, we have tuned the compilers to generate
code to best take advantage of the 68040 - instruction scheduling based on the
68040 pipeline architecture, avoiding address modes that are unduly expensive
on the 68040, etc.

Bottom line: current (ie, 7.40) compilers generate code to take full advantage
of the 68020/68030 opcodes, and are tuned to emit the best code possible for
the 68040.

    $ also that there are signifigant differences between the 400 and the
    $ 800 Operating Systems; the two OS's are subtly different, and appear
    $ to be generated by two teams in parallel instead of generated by a
    $ recompile (a'la Sun 3 and 4).

Starting with 7.0, most of the code is indeed just a recompile, with obvious
exception like code generators and some kernel code.

>    & HP-UX SUX.  Ugly.  Painful SysVR2 (not 3, not 4) variant.

A more diplomatic response: it is not BSD, so you may find switching awkward at
first.  If you are more used to System V, you should find it quite natural.

>    > C
>
>    & Screwy, arcane compiler flags to adjust STATIC tables in the various
>    & compiler passes.  Many programs (perl, X distribution, etc.) will not
>    & compile without fiddling with these switches.

These switches are gone.  The tables size themselves automatically now.

>    $ I suspect that the compiler supplied is a version of the
>    $ old AT&T portable C compiler; you might have much better luck with the
>    $ spiffy (and non-bundled) HP "fancy C compiler" product.  Better yet,
>    $ I'd suggest that you get GNU's gcc - it's free, and you get full
>    $ source.

gcc is indeed free, and you are welcome to use it.  Measurements show that the
HP compilers generate better code on most benchmarks we've tried on the 300,
and MUCH better on the 800.  HP's 300 compiler is based on pcc, but has been
worked on extensively - besides fixing bugs, we added ANSI C support, two
distinct optimizers, support for later Motorola processors, etc.  The 800
compiler is not pcc based.

>    > X11R4 from MIT
>
>    & "Cannot perform realloc".  We don't know where this is coming from, we
>    & are still working on it.  This basically disables all X toolkit
>    & programs; and is especially painful because (a) HP didn't give us dbx,
>    & and (b) gdb can't find any symbols, even though we compile it -g.

Try defining "MALLOC_0_RETURNS_NULL" when building X11R4.  MIT assumes
malloc(0) returns the current breakpoint, but not all malloc's behave this way,
so an #ifdef was added.

You would, of course, have no trouble debugging if you used HP's C compiler and
the supplied debugger xdb.

--------------
Marc Sabatella (marc@hpmonk.fc.hp.com)
Disclaimers:
	2 + 2 = 3, for suitably small values of 2
	Bill and Dave may not always agree with me