Re: 970917 on mips-sgi-irix6.2, haifa disabled: many problems

Re: 970917 on mips-sgi-irix6.2, haifa disabled: many problems

[Mike Stump]

> Date: Fri, 26 Sep 1997 17:23:16 +0200 (MET DST)
> From: Kamil Iskra <kamil@dwd.interkom.pl>

> please explain what this "bytecode" stuff is all about? Sure, I know
> what a Java bytecode is, but this thing seems to be older than Java,
> so it's probably something completely different...

bytecode is a generic term for a technology that can be used to
describe many translation systems.  For example, the munched elisp
files (.elc) from emacs, can be called bytecode files (and is).  The
output from a Pascal P system compiler, can be so referred.  As can
some (most?) Java translators...  some C interpreters, the gcc
compiler (when generating bytecodes).  I suspect the perl and Tcl also
may have such systems, but not having reviewed the specifics of those,
I cannot say.

The qualities are generally, a binary instruction set that doesn't
exactly match the source language, but rather a simplification of it,
that is not a native binary format for the machine in question, whose
smallest element tends to be a byte (8 bits).  There is an interpreter
for byte codes that can execute the codes and give the desired
semantics of the program.  The advantages are generally smaller
binaries, portable binaries and the abstraction of all machines into a
single `virtual machine'.

Some people may put the further restriction that the byte code cannot
match any hardware implementation, as then all you have is a CPU
simulator; others may claim that all CPU simulators are byte code
interpreters.

bytecode as a technology despite that you may think Sun invented it
with Java is actually old, quite old.

You can read all the opcodes to get a sense of the machine that gcc
uses, by checking out bc-opcode.h from a gcc build directory.  If you
know rtl, it should be fairly unsurprising.

Re: 970917 on mips-sgi-irix6.2, haifa disabled: many problems

[Robert Lipe]

> >	Also, for cases (xcoff/elf, n32/64) where the compiler has
> >There aren't any mips ports that support both xcoff and elf
> I was thinking of SCO here, but actually, irix5 can do both coff

OpenServer generates both COFF and ELF.   Not xcoff and ELF.

I do think the same situation applies, though.   I build for cross-mips
and have to wait for about a billion cross libes to build that I don't
ever even use.


RJL

Re: 970917 on mips-sgi-irix6.2, haifa disabled: many problems

[Zack Weinberg]

On Tue, 30 Sep 1997 23:10:23 -0700, Jim Wilson wrote:
>	Also, for cases (xcoff/elf, n32/64) where the compiler has
>	multiple output backends, the configure switch should cut out the code 
>for
>	the undesired backends.
>
>There aren't any mips ports that support both xcoff and elf

I was thinking of SCO here, but actually, irix5 can do both coff
(ecoff) and elf, although I don't think it's important to support
that.

>I suspect that the irix6 port is the only mips workstation port that does
>multilibbing, and it does so for compatibility with the SGI C compiler which
>does essentially the same thing.  If anything, I would like to increase the
>list to include [o]32 in addition to n32/64, for even better compatibility.
>The o32 support isn't working though because of conflicts with the n32 support

*nod*  I would like to see o32 support too, but please keep defaulting
to N32.

>	I would however like to see some easy way to change the
>	default set of -m switches gcc uses.  SGI's compilers for
>	example read an envariable (SGI_ABI) anda file in /etc to
>	decide which ABI to default to.
>
>I disagree.  I think SGI's scheme is a serious mistake.  We have
>enough trouble getting people to report enough info to allow us to
>reproduce a problem.  Imagine how much trouble we would have if we
>also need them to report the contents of a file in /etc which they
>have never heard of.  There is a similar problem with envinronment
>variables, which people will set and then forget about.

OK, fair enough...

>	There's also a nice feature of Sun's compilers, the -native
>	switch, which means "tune code and issue instructions for the
>	chip I'm compiling on." This may be too hard to implement (how
>	do you know which chip you're on?) though.
>
>This does sound useful.
>
>On an SGI, `hinv' will reliably tell you what chip you are on.  Many other
>OS's also have some way to determine what chip you are on.  This could be
>determined at configure time if this is a native.

Configure time is too early for what I had in mind.  Suppose I install
egcs on my file server which provides /usr/local to many workstations
with slightly different versions of the same arch.  All the users want
to compile things and run them on their own boxes.  [This is close to
the environment I work in.]  Sun's -native will tune for the Sparc 10
here, the Ultra there, the ancient IPX in the corner, depending where
it's run.  Those are the semantics I'd like to see.

On SGIs there's getinvent(3) to tell you about the hardware, no
special privileges needed.  On Suns you need to grovel through
/dev/kmem (or that's how prtconf does it anyway) which means you have
to be setgid.  The Sun compilers cheat and read the output of
prtconf.

>PS I am started looking into the remaining c-torture failure, but got
>distracted by other work so I haven't finished it yet.  irix6 has a strange
>structure passing/return convention, and this support was accidentally broken
>by this change:

Unfortunately as of 970924 any attempt to run the testsuite results in
a system hang somwhere in c-torture/execute.  This is IRIX's fault,
not egcs's (bug in exec()) but if there's anything the execute tests
are doing that might tickle kernel bugs...

zw

Re: 970917 on mips-sgi-irix6.2, haifa disabled: many problems

[Jim Wilson]

	Also, for cases (xcoff/elf, n32/64) where the compiler has
	multiple output backends, the configure switch should cut out the code for
	the undesired backends.

There aren't any mips ports that support both xcoff and elf

I suspect that the irix6 port is the only mips workstation port that does
multilibbing, and it does so for compatibility with the SGI C compiler which
does essentially the same thing.  If anything, I would like to increase the
list to include [o]32 in addition to n32/64, for even better compatibility.
The o32 support isn't working though because of conflicts with the n32 support.

The extra support in the compiler itself is trivial.  The only real cost here
is the size of the libraries, which are compiled once for each multilib.

	I would
	however like to see some easy way to change the default set of -m switches
	gcc uses.  SGI's compilers for example read an envariable (SGI_ABI) and a
	file in /etc to decide which ABI to default to. 

I disagree.  I think SGI's scheme is a serious mistake.  We have enough trouble
getting people to report enough info to allow us to reproduce a problem.
Imagine how much trouble we would have if we also need them to report the
contents of a file in /etc which they have never heard of.  There is a similar
problem with envinronment variables, which people will set and then forget
about.

This will also cause trouble for people trying to port programs from one
SGI machine to another.  A program that compiles fine on one machine may
fail miserably on another, just because a file in /etc that you didn't know
was there caused the C compiler to behave differently, or because the
person compiling it had set the SGI_ABI environment variable differently.
Makes me shudder to think of it.  I hardwired `cc -32' into the irix6
configuration to try to avoid this problem.

In any case, if you really want to fiddle with the defaults, there is already
a way to do this: you can modify the specs file.  If you do this though, you
had better remember to mention this in all bug reports, otherwise you will
get confused answers because we won't be able to reproduce your problems.

	There's also a nice feature
	of Sun's compilers, the -native switch, which means "tune code and issue
	instructions for the chip I'm compiling on." This may be too hard to
	implement (how do you know which chip you're on?) though.

This does sound useful.

On an SGI, `hinv' will reliably tell you what chip you are on.  Many other
OS's also have some way to determine what chip you are on.  This could be
determined at configure time if this is a native.  If this is a cross, you
have to specify the target explicitly anyways, so we could rely on the user
to optionally specify it.

It would take some work to implement this though, as practically every port
would be affected.

Jim

PS I am started looking into the remaining c-torture failure, but got
distracted by other work so I haven't finished it yet.  irix6 has a strange
structure passing/return convention, and this support was accidentally broken
by this change:

Mon Jul 28 11:22:16 1997  Jason Merrill  <jason@yorick.cygnus.com>

	* stor-layout.c (layout_type): Fix ancient code to match ancient
	comment.  Use mode of field for one-field structs.

Re: 970917 on mips-sgi-irix6.2, haifa disabled: many problems

[Richard Henderson]

> There's also a nice feature
> of Sun's compilers, the -native switch, which means "tune code and issue
> instructions for the chip I'm compiling on." This may be too hard to
> implement (how do you know which chip you're on?) though.

It is highly operating system dependant, but there is usually a 
relatively simple way.


r~

Re: 970917 on mips-sgi-irix6.2, haifa disabled: many problems

[Zack Weinberg]

On Sun, 28 Sep 1997 01:45:31 -0600, Jeffrey A Law wrote:
>
>  [Along the same lines, It Would Be Nice if
>  > one could disable various of the multilib targets; for example, I can't us
>e
>  > -mabi=64 code on this beast and would just as soon save the space.]
>You might be interested in --disable-multilib -- it's a configure
>option that simply disables multilibs.
>
>If you come up with a scheme to improve multilib, submit it.  We're
>more than open to schemes to improve multilib.

Well, what I was thinking of was a finer-grained version of
--disable-multilib.  How about --enable-multilib=LIST to say, I want this,
this, and this?  Also, for cases (xcoff/elf, n32/64) where the compiler has
multiple output backends, the configure switch should cut out the code for
the undesired backends.

One could take this to its logical conclusion, and ask for compile time
switches to exclude all but one chip subarchitecture (e.g. you have a farm
of identical computers, and you never want to compile for any other subarch)
but I think this would be overkill; subarchitectures don't bloat the
compiler enough to be worth the hassle of #ifdef'ing them all.  I would
however like to see some easy way to change the default set of -m switches
gcc uses.  SGI's compilers for example read an envariable (SGI_ABI) and a
file in /etc to decide which ABI to default to.  There's also a nice feature
of Sun's compilers, the -native switch, which means "tune code and issue
instructions for the chip I'm compiling on." This may be too hard to
implement (how do you know which chip you're on?) though.

zw

Re: 970917 on mips-sgi-irix6.2, haifa disabled: many problems

[Kamil Iskra]

[Cross-posted from egcs-bugs]

On Tue, 23 Sep 1997, Jeffrey A Law wrote:

>   > 7) It would be nice if the bytecode stuff could be turned off.
> We're seriously considering just removing it.  It's a poor design,
> poor implementation and nobody's ever used it for anything.

Could you, or somebody else, please explain what this "bytecode" stuff is
all about? Sure, I know what a Java bytecode is, but this thing seems to
be older than Java, so it's probably something completely different...

/ Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 1.6 GB, 18 MB RAM \
| iskra@student.uci.agh.edu.pl  kiskra@ernie.icslab.agh.edu.pl |
| http://student.uci.agh.edu.pl/~iskra                         |
\ PGP public key available via Finger or WWW                   /