All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Joel Soete" <soete.joel@tiscali.be>
To: "Randolph Chung" <randolph@tausq.org>
Cc: John David Anglin <dave@hiauly1.hia.nrc.ca>,
	parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] c3k panics
Date: Tue, 31 May 2005 07:41:49 +0200	[thread overview]
Message-ID: <4282FEEE0000724C@mail-5-bnl.tiscali.it> (raw)

Hello Randolph,

>
> > #ifndef CONFIG_64BIT
> >         .macro fixup_branch,lbl
> >         b           \lbl
> >         .endm
> > #else
> >         .macro fixup_branch,lbl
> >         ldil        L%\lbl, %r1
> >         ldo         R%\lbl(%r1), %r1
> >         bv,n        %r0(%r1)
> >         .endm
> > #endif
>
> These two do the same thing. The 32-bit version is simpler because we
> can rely on the linker to do fixups for us if the branch is too far
> away. The 64-bit version always uses a long branch sequence to avoid
> stub issues with the 64-bit toolchain. In the C code I have simply not
> done this (micro-)optimization.
>
Ok clear but still confused why 32bit branch doesn't nullify the insn
in delay slot like did 64bit?

btw one more thing confusing me: the third fixup_branch macro definition
in lusercopy.S:
[snip]
         .macro fixup_branch,lbl
         ldil        L%\lbl, %r1
         ldo         R%\lbl(%r1), %r1
         bv          %r0(%r1)
         .endm

This time just bv not bv,n ?
I presume that's needed because here that's user space but couldn't we ha=
ve
2 macro name (e.g a k_fixup_br, us_fixup_br)  to avoid this confusion?

Thanks again,
    Joel


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

             reply	other threads:[~2005-05-31  5:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-31  5:41 Joel Soete [this message]
2005-05-31  6:26 ` [parisc-linux] c3k panics Randolph Chung
2005-06-01 13:11   ` Joel Soete
2005-06-01 13:55     ` John David Anglin
2005-06-05 19:15   ` Some other cleanup [Was: [parisc-linux] c3k panics] Joel Soete
  -- strict thread matches above, loose matches on Subject: below --
2005-06-01 15:05 [parisc-linux] c3k panics Joel Soete
     [not found] <429A0B7C.3020003@tiscali.be>
2005-05-29 20:49 ` John David Anglin
2005-05-29  1:41 John David Anglin
2005-05-29  1:50 ` John David Anglin
2005-05-29 22:08   ` Carlos O'Donell
2005-05-29 23:39     ` John David Anglin
2005-05-29 10:32 ` Joel Soete
2005-05-29 17:15   ` Joel Soete
2005-05-30  1:13     ` Randolph Chung
2005-06-01 14:04     ` Joel Soete
2005-05-29 17:45   ` John David Anglin

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=4282FEEE0000724C@mail-5-bnl.tiscali.it \
    --to=soete.joel@tiscali.be \
    --cc=dave@hiauly1.hia.nrc.ca \
    --cc=parisc-linux@lists.parisc-linux.org \
    --cc=randolph@tausq.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 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.