From: Albert Cahalan <albert@users.sf.net>
To: Vincent Hanquez <tab@snarc.org>
Cc: benh@kernel.crashing.org,
linux-kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ppc32 use simplified mmenonics
Date: 22 Aug 2004 08:40:22 -0400 [thread overview]
Message-ID: <1093178422.2301.2674.camel@cube> (raw)
In-Reply-To: <20040822144501.GA10017@snarc.org>
On Sun, 2004-08-22 at 10:45, Vincent Hanquez wrote:
> On Sun, Aug 22, 2004 at 06:41:32AM -0400, Albert Cahalan wrote:
> > This is a slightly better example, but still, it's
> > lots easier to look up "bc" to see the selection of
> > options that are available.
> >
> > Plus, yeah, "what the hell is 4,2", but those numbers
> > replace a _lot_ of other things you'd need to remember.
> > There are 456 of these "simplified" branch instructions.
> > If you use those, you'll tend to restrict your code to
> > those few common ones you remember. There's bdnzltrl,
> > bdnzfla, bunla... That's madness.
>
> So you writing assembly ppc code with your book on your side ?
> because I don't see any reason to associate easily '4,2' with 'not equal'
As I said, it's a slightly better example.
(it's also NOT what the patch was changing)
> bdnzltrl kinds of mmenonics are actually not fair, they are not really used :).
> But even that I would prefer bdnztlrl which I would have to lookup,
> than bclr with cryptics numbers which I would had to lookup too.
See, that's a problem. You're limiting yourself to
just 96 of the 456 listed operations, which are only
1/5 of the 2304 available operations.
I do admit to using bne at times. The bit manipulation
stuff is different though. It's not so cryptic in the
raw form. The same goes for using "or" to copy a register.
If you don't use the full bit manipulation notation
all the time, you might forget what it can do. Then
you'll end up using 2 instructions where one would do.
> > That's 114 opcodes to 1.
>
> There's not 1 opcode for conditional branching. There are more on ppc basis:
>
> bc, bca, bclr, bcctr, bcl, bcla, bclrl, bcctrl
OK, that's 8. Dividing 456 by that, I still see a 57:1 ratio.
There's also that matter of the 1848 operations you can't
access via the "simplified" instruction names.
next prev parent reply other threads:[~2004-08-22 15:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-22 0:45 [PATCH] ppc32 use simplified mmenonics Albert Cahalan
2004-08-22 9:43 ` Vincent Hanquez
2004-08-22 10:41 ` Albert Cahalan
2004-08-22 14:45 ` Vincent Hanquez
2004-08-22 12:40 ` Albert Cahalan [this message]
2004-08-22 16:28 ` Vincent Hanquez
2004-08-22 14:29 ` Albert Cahalan
2004-08-22 19:17 ` Vincent Hanquez
2004-08-22 17:02 ` Horst von Brand
2004-08-23 1:24 ` Benjamin Herrenschmidt
-- strict thread matches above, loose matches on Subject: below --
2004-08-21 22:23 Vincent Hanquez
2004-08-22 2:00 ` Benjamin Herrenschmidt
2004-08-22 9:48 ` Vincent Hanquez
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=1093178422.2301.2674.camel@cube \
--to=albert@users.sf.net \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tab@snarc.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