From: Ralf Baechle <ralf@oss.sgi.com>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: <linux-mips@oss.sgi.com>
Subject: Re: Can't build a CONFIG_CPU_NEVADA kernel
Date: Fri, 16 Mar 2001 20:35:40 +0100 [thread overview]
Message-ID: <20010316203540.D2857@bacchus.dhis.org> (raw)
In-Reply-To: <010201c0ae49$6df089e0$0deca8c0@Ulysses>; from kevink@mips.com on Fri, Mar 16, 2001 at 07:46:23PM +0100
On Fri, Mar 16, 2001 at 07:46:23PM +0100, Kevin D. Kissell wrote:
> > GCC to schedule instructions for a certain processor xxx. This does not
> > enable the full use of it's instruction set. Back in time when I choose
> > these options I choose because GCC didn't know -mcpu=r5000 but the R8000
> > was supported and it was the closest fit. Gcc 1.1.2 knows this option
> > so I just changed all instances of -mcpu=r8000 into -mcpu=r5000.
>
> As I understand it, the original intention behind -mcpu was to optimise
> instruction scheduling, but it got perverted over time to enable
> instructions as well. In any case, the R5000 and R8000 have the
> same ISA, but the pipelines are radically different. The R8K is
> 4-way superscalar, with a 2-cycle branch penalty and branch
> prediction. The R5K is two way supercalar (Int/FP pairs only)
> with classic MIPS branch behavior, etc.
Gcc's knowledge about MIPS architecture is so limited that an R5000 isn't
very much different from an R8000 ...
> > Unfortunately true but there is a reason that QED's manual marks it as an
> > proprietary extension ...
>
> Yup. The quesiton is, does gcc's -mmad option actually
> select based on -mcpu or some other variable which
> semantics to use, or does it assume R4650 semantics
If you have a collection which of the CPUs have implemented mmad in what
way I'd like to use that to put it into gcc.
> (I had the impression that it was the R4650 that drove
> the implementation of MIPS madd's into gcc - correct
> me if I'm wrong).
Guess that's right.
Ralf
WARNING: multiple messages have this Message-ID (diff)
From: Ralf Baechle <ralf@oss.sgi.com>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: linux-mips@oss.sgi.com
Subject: Re: Can't build a CONFIG_CPU_NEVADA kernel
Date: Fri, 16 Mar 2001 20:35:40 +0100 [thread overview]
Message-ID: <20010316203540.D2857@bacchus.dhis.org> (raw)
Message-ID: <20010316193540.HyRswpRtx_43_ionnLzkMr69GNJKDgCtdG3S7VqEtik@z> (raw)
In-Reply-To: <010201c0ae49$6df089e0$0deca8c0@Ulysses>; from kevink@mips.com on Fri, Mar 16, 2001 at 07:46:23PM +0100
On Fri, Mar 16, 2001 at 07:46:23PM +0100, Kevin D. Kissell wrote:
> > GCC to schedule instructions for a certain processor xxx. This does not
> > enable the full use of it's instruction set. Back in time when I choose
> > these options I choose because GCC didn't know -mcpu=r5000 but the R8000
> > was supported and it was the closest fit. Gcc 1.1.2 knows this option
> > so I just changed all instances of -mcpu=r8000 into -mcpu=r5000.
>
> As I understand it, the original intention behind -mcpu was to optimise
> instruction scheduling, but it got perverted over time to enable
> instructions as well. In any case, the R5000 and R8000 have the
> same ISA, but the pipelines are radically different. The R8K is
> 4-way superscalar, with a 2-cycle branch penalty and branch
> prediction. The R5K is two way supercalar (Int/FP pairs only)
> with classic MIPS branch behavior, etc.
Gcc's knowledge about MIPS architecture is so limited that an R5000 isn't
very much different from an R8000 ...
> > Unfortunately true but there is a reason that QED's manual marks it as an
> > proprietary extension ...
>
> Yup. The quesiton is, does gcc's -mmad option actually
> select based on -mcpu or some other variable which
> semantics to use, or does it assume R4650 semantics
If you have a collection which of the CPUs have implemented mmad in what
way I'd like to use that to put it into gcc.
> (I had the impression that it was the R4650 that drove
> the implementation of MIPS madd's into gcc - correct
> me if I'm wrong).
Guess that's right.
Ralf
next prev parent reply other threads:[~2001-03-16 19:35 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-14 13:46 Can't build a CONFIG_CPU_NEVADA kernel Daniel Jacobowitz
2001-03-14 18:59 ` Ralf Baechle
2001-03-14 19:05 ` Daniel Jacobowitz
2001-03-14 19:20 ` Ralf Baechle
2001-03-14 19:48 ` Jun Sun
2001-03-14 20:02 ` Ralf Baechle
2001-03-14 20:56 ` Daniel Jacobowitz
2001-03-14 22:11 ` Kevin D. Kissell
2001-03-14 22:11 ` Kevin D. Kissell
2001-03-14 22:47 ` Kevin D. Kissell
2001-03-14 22:47 ` Kevin D. Kissell
2001-03-15 1:50 ` Pete Popov
2001-03-15 8:01 ` Kevin D. Kissell
2001-03-15 8:01 ` Kevin D. Kissell
2001-03-16 14:04 ` Ralf Baechle
2001-03-16 14:04 ` Ralf Baechle
2001-03-16 18:02 ` Daniel Jacobowitz
2001-03-16 18:16 ` Ralf Baechle
2001-03-16 18:46 ` Kevin D. Kissell
2001-03-16 18:46 ` Kevin D. Kissell
2001-03-16 19:35 ` Ralf Baechle [this message]
2001-03-16 19:35 ` Ralf Baechle
2001-03-16 15:34 ` Ralf Baechle
2001-03-16 15:34 ` Ralf Baechle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010316203540.D2857@bacchus.dhis.org \
--to=ralf@oss.sgi.com \
--cc=kevink@mips.com \
--cc=linux-mips@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.