🚀 go-pugleaf

>>>>> On 12 Oct 93 19:56:18 GMT, charliew@sunshine.LABS.TEK.COM (Charles
>>>>> Wilson) said:

 charliew> In article <9310121747.AA23306@ndc.com> derway@ndc.com (Don Erway)
 charliew> writes:

>I feel strongly that the tool chain should support target processors, with
>"optimal", (for gcc), or at least
>un-arbitrarily-constrained-by-backwards-compatibility, configurations.

 charliew> I'm not sure I follow you on this.  What exactly is it that you
 charliew> feel is missing?  What would be an "optimal" configuration?

I'll present the example I have been working with. I want to compile on a
sun4, and produce code for an embedded 68020/68881 system. When I build the
compiler, I have to choose between sun3, sony, motorola, hp3, etc. I don't
have the choice m68k-gnu-aout. All these others have some limitations due to
the necessity of being compatible with the native host compilers and
libraries. For instance, sun3 functions return floating point values in BOTH
fp0, and the d0/d1 pair. This is for compatibility with soft and hard floating
point libraries. But it produces useless extra garbage, if you are sure that
all your code will be compiled with 68881 support.

Not one of the 68k configurations that come with gcc are "optimal". From what
I understand, an optimal configuration would look something like this:

	return floats/doubles in fp0 only. 
	return pointers in a0 only.
	return ints in d0 only.
	pass first two function arguments in d0, d1
		(maybe pointer args in a0, a1, and
		 floating args in fp0, fp1?)
	perhaps adjust scratch/temp registers to more than 2?

This sort of configuration would be for adults only. It would break lots of
code out there, since improperly declared functions would die a horrible
death.

I fully understand that building native compilers, gcc MUST be compatible with
all their quirks. But I argue that the vast majority of people using gcc as a
cross compiler, are doing so because they are going to embedded targets. Why
build a cross compiler to a unix target? I suppose you might do it in order to
bootstrap a compiler across, when you didn't have any native compiler at all,
but distribution of pre-compiled binaries, (as wtih Solaris 2), seems a better
solution to that.

I believe that every processor that gcc (and the rest of the tools) support
should have a processor-gnu-format configuration, which optimizes gcc the best
anyone knows how.

		-Don