From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: Re: [9fans] plan or side effect
From: forsyth@caldo.demon.co.uk
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20020301113801.8833D19995@mail.cse.psu.edu>
Date: Fri,  1 Mar 2002 11:35:39 +0000
Topicbox-Message-UUID: 5d583678-eaca-11e9-9e20-41e7f4b1d025

Given the results of (say) that integer benchmark run that
was shown here earlier, my inclination would have been
to compare the object code to find out where and how
the difference arose, rather than speculating that -O999 had
a lot to do with it.  Certainly I've found in the past, especially
with such microbenchmarks, that small things often count
for a lot.  As a simple example, one code generator I wrote
didn't do as well on a particular sequence as another compiler,
even though in some ways the code I generated was better;
it turned out that the difference was whether parts of the
loop were aligned on cache boundaries.   Sometimes particular
instructions or instruction sequences that are logically identical
differ markedly in speed.

As to the repeated assertion that 8c (actually there's a larger family than that)
isn't used because of the licence or the code quality, I can observe
that I do not use 8c to compile hosted Inferno on anything other
than Plan 9, and to my certain knowledge it is for neither reason.
It's simply that [8qk]c does not produce code that is easily compatible
with the hosting system.   Unlike GCC, the compiler does not
produce assembly language that can be assembled by the host assembler.
The compiler is part of a larger suite that includes a linker that is designed
to work with the compiler.  The compiler produces a binary file
but that is not object code, let alone object code in the obscure
Windows and Unix formats.  The linker converts only that binary representation
to an executable format.  You can't link the compiler's output
binary with a host linker.   Conversely, the linker
does not know how to read host object files.   It would be very hard
work to make it do so (in general), especially with ghastly, subtle
instruction encodings as on x86 and 680x0.   It operates with
a binary representation from the compiler that's set at a higher level
than raw machine code with relocation bits.   Indeed, there is
no relocation information in it.   Consequently, the linker cannot
link with the system's existing libraries.

Of course, the linker could take its current input and produce
executable images for the hosting operating system.  This is limiting
unless you've got the source for all the libraries (and they are written
in reasonable C), since you will probably not be able to do graphics
(eg, under Windows).   The linker does this is in a small way
on every platform, where it produces an executable image that
is sufficient disguise for this or that bootstrap program to accept it
(and even that's not easy).

I took a stab at using the suite years ago on AIX and RS6000, partly because
I wanted a platform to test the powerpc compiler suite.   At the time,
there was no documentation  I could find that adequately described
the AIX COFF format and dynamic linking conventions
so that I could generate it.  This is, by the way, often true
on other platforms.  IBM (at the time)
was not particularly helpful; not obstructive, just unhelpful.
I wasted time guessing and finally gave up, wrote a powerpc interpreter,
and used that until my BeBox turned up.
I was able to use AIX as a cross-compiling environment, though,
for another target system,
because the compilers require no special configuration for that:
just compile them on the new host.

Thus, the best reason not to use the Plan9 suite has nothing to do
with licences or code quality: it's that it's typically quite impractical.
If I could use them more generally, I certainly would.