Linux PARISC architecture development
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox