Re: gcc support for mips32 release 2]

Re: gcc support for mips32 release 2]

[Eric Christopher]

More on the thread from Chris since it was cross posted to gcc@ as well.

-eric

-----Forwarded Message-----
> From: cgd@broadcom.com
> To: long21st@yahoo.com
> Cc: gcc@gcc.gnu.org
> Subject: Re: gcc support for mips32 release 2
> Date: Fri, 05 Mar 2004 08:19:08 -0800
> 
> At Fri, 5 Mar 2004 07:54:19 +0000 (UTC), "Long Li" wrote:
> > I have a question about gcc support for mips32 release
> > 2. I noticed that in gnu as(assembler) 2.14, there is
> > an option for it, but does newest gcc version support
> > mips32 release 2? I did not find it in the mips.c or
> > configure file. 
> 
> as others have noted, I contributed it to GCC and it should appear in
> 3.4.
> 
> Note that 3.4 has only partial support for the new instructions.  In
> particular, it only knows how to generate rotates and, IIRC, some of
> the sign-extend instructions.  (it's been a while since i did the
> work.)
> 
> It does *not* know how to do use the insert/extract instructions.
> 
> 
> If anybody knows of a MIPS64 release 2 implementation, I also have
> support for GCC to do that.  (Problem is, the way the GCC MIPS
> back-end currently is, it really wants a processor implementation
> before a new ISA is added.)
> 
> I also have a number of sim changes for 32r2 -- can't remember if i've
> integrated all of them or not, yet -- and 64r2.  (Fairly sure i've not
> done the 64r2 changes.)
> 
> 
> 
> chris
-- 
Eric Christopher <echristo@redhat.com>

Re: gcc support for mips32 release 2]

[Maciej W. Rozycki]

On Fri, 5 Mar 2004, Eric Christopher wrote:

> > If anybody knows of a MIPS64 release 2 implementation, I also have
> > support for GCC to do that.  (Problem is, the way the GCC MIPS
> > back-end currently is, it really wants a processor implementation
> > before a new ISA is added.)

 Well, I think this can be handled by creating an artificial processor
entry (e.g. "PROCESSOR_MIPS64R2" in this case) and replacing it with a
real one once an implementation is publicly available.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: gcc support for mips32 release 2]

[cgd]

At Wed, 17 Mar 2004 17:18:37 +0100 (CET), Maciej W. Rozycki wrote:
>  Well, I think this can be handled by creating an artificial processor
> entry (e.g. "PROCESSOR_MIPS64R2" in this case) and replacing it with a
> real one once an implementation is publicly available.

yeah.  doing that, but introducing known "to be removed" code bugs me.

it's probably better than not getting the rest of the infrastructure
in, though.


cgd

Re: gcc support for mips32 release 2]

[Maciej W. Rozycki]

On Wed, 17 Mar 2004 cgd@broadcom.com wrote:

> >  Well, I think this can be handled by creating an artificial processor
> > entry (e.g. "PROCESSOR_MIPS64R2" in this case) and replacing it with a
> > real one once an implementation is publicly available.
> 
> yeah.  doing that, but introducing known "to be removed" code bugs me.

 That's a mechanical update and a very trivial one -- to be done with
"s///".  Sometimes you just cannot avoid placeholders.

> it's probably better than not getting the rest of the infrastructure
> in, though.

 Indeed -- you get certain automatical updates done by the others in
return.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: gcc support for mips32 release 2]

[Ralf Baechle]

On Wed, Mar 17, 2004 at 08:41:47AM -0800, cgd@broadcom.com wrote:

> At Wed, 17 Mar 2004 17:18:37 +0100 (CET), Maciej W. Rozycki wrote:
> >  Well, I think this can be handled by creating an artificial processor
> > entry (e.g. "PROCESSOR_MIPS64R2" in this case) and replacing it with a
> > real one once an implementation is publicly available.
> 
> yeah.  doing that, but introducing known "to be removed" code bugs me.
> 
> it's probably better than not getting the rest of the infrastructure
> in, though.

It seems a small problem compared to having to answer all the questions
about why Linux tries to optimize for processor X when it's configured
for type Y.  People just love tweaking compiler flags it seems - even if
not necessarily knowing all the consequences ...

  Ralf

Re: gcc support for mips32 release 2]

[Eric Christopher]

> It seems a small problem compared to having to answer all the questions
> about why Linux tries to optimize for processor X when it's configured
> for type Y.  People just love tweaking compiler flags it seems - even if
> not necessarily knowing all the consequences ...

Amen brother.

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: gcc support for mips32 release 2]

[Maciej W. Rozycki]

On Thu, 18 Mar 2004, Ralf Baechle wrote:

> > yeah.  doing that, but introducing known "to be removed" code bugs me.
> > 
> > it's probably better than not getting the rest of the infrastructure
> > in, though.
> 
> It seems a small problem compared to having to answer all the questions
> about why Linux tries to optimize for processor X when it's configured
> for type Y.  People just love tweaking compiler flags it seems - even if
> not necessarily knowing all the consequences ...

 The recent updates to Makefiles should help a bit -- now at least you can
give a short answer of: "Because you use outdated tools."  Note there's a
single trivial update still awaiting approval in this area (I can resend
it, if it would help).

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +