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 10:29:00 -0400 [thread overview]
Message-ID: <1093184939.2301.2799.camel@cube> (raw)
In-Reply-To: <20040822162845.GA10911@snarc.org>
On Sun, 2004-08-22 at 12:28, Vincent Hanquez wrote:
> However each person that has read some documentations about ppc assembly know
> that a 'clrrwi' is a macro to a more complex instruction 'rlwinm'.
>
> Any documentation that wouldn't mention that is just plain wrong.
It's buried in Appendix F.
> > 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.
>
> Are you counting one operations for 'rlwinm' and one for 'rlwinm.' to have
> so much (1848) operations ? or is your figures totally random ?
That's just for branches.
There are 32 condition register bits.
There are 9 values for the BO field. (so far)
There are 8 of these: bc,bca,bcl,bcla,bcctr,bcctrl,bclr,bclrl
That comes to 2304. Subtract the 456 "simplified"
instruction names you have. That leaves 1848 that
you are unable to access.
Take a look at the crand instruction. It uses numbers.
Now, just imagine mixing that with branch instructions
that hide the numbers. I hope you see the problem.
> But anyway it seems, we could discuss the benefit or not, of using simplified
> instructions the whole night. I think this is a good idea (obviously) and it
> seems Benjamin thinks it too. Thoses simplified instructions are mentioned in
> all officials ppc assembly documentation because they are simple and help.
It doesn't appear to be so. He wrote:
: Oh well.. I've got quite used to tweaking rlwinm directly
: but I suppose it's more clear for others to go to clrrwi.
So I'd like him to know that others like rlwinm directly too.
Using instructions that are in the index makes sense.
Using a zillion poorly documented alternatives is madness.
next prev parent reply other threads:[~2004-08-22 17:03 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
2004-08-22 16:28 ` Vincent Hanquez
2004-08-22 14:29 ` Albert Cahalan [this message]
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=1093184939.2301.2799.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