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 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.