public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.



  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