From: Jeff Baker <jbaker@qnx.com>
To: Alan Modra <amodra@bigpond.net.au>
Cc: binutils@sourceware.org
Subject: Re: [PATCH] Handle mtsprg and mfsprg properly for BookE
Date: Tue, 08 Mar 2005 16:30:00 -0000 [thread overview]
Message-ID: <422DD386.8050802@qnx.com> (raw)
In-Reply-To: <20050308112011.GC15642@bubble.modra.org>
> Correct for what processor? My BOOKE reference says of SPRG:
>
> SPR number Access Privileged
> SPRG0 272 Read/Write Yes
> SPRG1 273 Read/Write Yes
> SPRG2 274 Read/Write Yes
> SPRG3 259 Read-only No
> 275 Read/Write Yes
> SPRG4 260 Read-only No
> 276 Read/Write Yes
> SPRG5 261 Read-only No
> 277 Read/Write Yes
> SPRG6 262 Read-only No
> 278 Read/Write Yes
> SPRG7 263 Read-only No
> 279 Read/Write Yes
> USPRG0 256 Read/Write No
>
> That says to me that there are two possible SPR numbers you use to
> access each of SPRG3 to SPRG7. And the duplicate numbers start at
> SPRG3, not SPRG4. Now you know why nobody reviewed your patch, and
> why I'm not approving it as is..
My BookE reference states that user-mode read access to sprg3 is
implementation dependant. Since the opcode table doesn't have an
mfsprg3 with an SPR number of 259 I (apparently incorrectly) assumed
that we didn't need that.
I also assumed that one reason for submitting a patch to the mailing
list is so that people who know more than I do can review it and then
point out where I'm making mistakes. If that isn't the case then can
you suggest somewhere I can go or someone I can ask for help if I'm
working on a patch that I need but don't 100% understand?
> If I was a programmer with an ounce of sense (debatable), I'd want
> to use "mfspr gpr,sprgN" where the sprgN are symbols or macros equated
> to the right spr register for the context, rather than trusting the
> assembler to do the right thing with "mfsprg gpr,N" or even worse,
> "mfsprgN gpr".
That may be true but I was asked to get it working. I don't believe
that technically it is correct for m[t,f]sprg to complain that the
register is greater than 3 if you have specified an architecture that
should allow up to 7. Even if so, 'mfsprg %r7,3' will be accepted as
correct but will produce an SPRG number of 275, not 259 as you
previously indicated it should. Same with 'mfsprg3 %r7'.
>>+/* Some dialects (BookE, 405) have 8 SPRG registers instead of
>>+ the normal 4. In addition, mfsprg instructions must
>>+ have sprn5 cleared when using registers 4 through 7. */
>
>
> Is this horrible formatting an artifact of your mailer?
No my editor does that. Easily fixed.
>>+static unsigned long
>>+insert_sprg (unsigned long insn,
>>+ long value,
>>+ int dialect,
>>+ const char **errmsg)
>>+{
>>+ /* This check uses PPC_OPCODE_403 because PPC405 is later defined
>>+ as a synonym. If ever a 405 specific dialect is added this
>>+ check should use that instead. */
>>+ if ((dialect & PPC_OPCODE_BOOKE) || (dialect & PPC_OPCODE_403))
>>+ {
>>+ if (value > 7)
>>+ *errmsg = _("Invalid operand. Must be between 0 and 7.");
>
>
> These error messages should be all lower case, and without a full-stop.
> I suggest simply "invalid sprg number". Then you can restructure the
> function as
>
> if (value > 7
> || (value > 3
> && (dialect & (PPC_OPCODE_BOOKE | PPC_OPCODE_403)) == 0))
> *errmsg = _("invalid sprg number");
>
> insn |= (value & 7) << 16;
> if (value > 3 or maybe 2 && some other condition)
> insn &= bit twiddle;
> return insn;
Easily done once I'm positive what the proper conditions should be.
>>+ 1cc: 7c f3 42 a6 mfsprg r7,3
>>+ 1d0: 7c e7 42 a6 mfsprg7 r7
>>+ 1d4: 7c f7 43 a6 mtsprg 7,r7
>
>
> This isn't the nicest disassembly, a result of mfsprg[3-7] appearing in
> the opcode table before mfsprg.
I know. I briefly thought about implementing an extract_sprg to handle
that but there really isn't a good way to decide how to display it.
>>+ mfsprg %r7, 3
>>+ mfsprg %r7, 7
>>+ mtsprg 7, %r7
>
>
next prev parent reply other threads:[~2005-03-08 16:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-28 20:20 Jeff Baker
2005-02-28 21:11 ` Jeff Baker
2005-02-28 21:26 ` Kumar Gala
2005-02-28 22:52 ` Jeff Baker
2005-02-28 23:09 ` Jeff Baker
2005-03-07 15:22 ` Jeff Baker
2005-03-08 11:20 ` Alan Modra
2005-03-08 16:30 ` Jeff Baker [this message]
2005-03-08 23:51 ` Alan Modra
2005-03-09 1:18 ` Jeff Baker
2005-03-09 2:11 ` Alan Modra
2005-03-09 16:39 ` Jeff Baker
2005-03-10 12:42 ` Alan Modra
2005-03-09 22:30 ` Kumar Gala
2005-03-10 3:58 ` Alan Modra
[not found] ` <ad80a57d7a545e4541f6fbaa2178ad4c@leftfield.org>
2005-03-14 4:14 ` Alan Modra
2005-03-16 16:39 ` Jeff Baker
2005-03-17 15:36 ` Alan Modra
-- strict thread matches above, loose matches on Subject: below --
2005-02-24 0:32 Jeff Baker
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=422DD386.8050802@qnx.com \
--to=jbaker@qnx.com \
--cc=amodra@bigpond.net.au \
--cc=binutils@sourceware.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).