Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Kaz Kylheku <kaz@zeugmasystems.com>
Cc: linux-mips@linux-mips.org
Subject: Re: SiByte 1480 & Branch Likely instructions?
Date: Sun, 9 Dec 2007 05:26:23 +0000	[thread overview]
Message-ID: <20071209052623.GC18181@linux-mips.org> (raw)
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C5590D6B@exchange.ZeugmaSystems.local>

On Fri, Dec 07, 2007 at 03:39:57PM -0800, Kaz Kylheku wrote:

> > Not really a kernel-related question. I've discovered that GCC 4.1.1
> > (which I'm not using for kernel compiling, but user space) generates
> > branch likely instructions by default, even though the documentation
> > says that their use is off by default for MIPS32 and MIPS64, because
> 
> That's because the compiler is not configured correctly. The default CPU
> string "from-abi" ends up being used, and so the target ISA is MIPS III.
> 
> > In parallel with writing some tests, I thought I would ask whether
> > anyone happens know whether or not these instructions are known to
> > actually work correctly on the SB1480 silicon (and perhaps any
> > additional details, like what revisions, etc)?
> 
> A basic sanity test does find bnezl working.
> 
> #include <stdio.h>
> #include <stdlib.h>
> 
> static int branch_likely_works(void)
> {
>     int one = 1;
>     int result;
> 
>     __asm__ __volatile__
>     ("        .set push\n"
>      "        .set noreorder\n"
>      "1:      move %0, $0\n"
>      "        bnezl %0, 1b\n"
>      "        lw %0, %1\n"
>      "        .set pop\n"
>      : "=r" (result)
>      : "m" (one));
> 
>      return result == 0;
> }
> 
> int main(void)
> {
>     if (branch_likely_works()) {
>         puts("branch-likely instruction bnezl correctly annuls delay
> slot");
>         return 0;
>     } 
>     puts("branch-likely instruction bnezl fails to annul delay slot");
>     return EXIT_FAILURE;
> }

That's a very basic test and it'd be very unlikely for the CPU to fail
such a simple test.

But think of scenarios like a load in the delay slot of a branch likely
where the load instruction is on a different page than the branch and a
tlb exception is getting caused.  There are many other special cases
which might be improperly implemented.

But honestly - branch likely instructions were introduced into the MIPS
architecture by the MIPS II R6000 in '89.  And the SB1 core is 2000
vintage so I'd assume by now have figured out how to get it right.  And
branch likely is used in existing binaries.  So I'd be surprised if it
was broken.

  Ralf

  parent reply	other threads:[~2007-12-09  5:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-07 21:54 SiByte 1480 & Branch Likely instructions? Kaz Kylheku
2007-12-07 21:54 ` Kaz Kylheku
2007-12-07 23:39 ` Kaz Kylheku
2007-12-07 23:39   ` Kaz Kylheku
2007-12-09  5:26   ` Ralf Baechle [this message]
2007-12-14  3:05   ` GCC bug affecting MIPS (was Re: SiByte 1480 & Branch Likely instructions?) Kaz Kylheku
2007-12-14  3:05     ` Kaz Kylheku
2007-12-09  5:14 ` SiByte 1480 & Branch Likely instructions? Ralf Baechle
2007-12-10 15:28   ` Maciej W. Rozycki
2007-12-10 15:35     ` Ralf Baechle
2007-12-10 16:20       ` Maciej W. Rozycki

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=20071209052623.GC18181@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=kaz@zeugmasystems.com \
    --cc=linux-mips@linux-mips.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox