linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: linas@austin.ibm.com
To: Hollis Blanchard <hollisb@us.ibm.com>
Cc: linuxppc-dev list <linuxppc-dev@lists.linuxppc.org>
Subject: Re: kernel oops due to unaligned access with lswi
Date: Wed, 19 Nov 2003 16:50:01 -0600	[thread overview]
Message-ID: <20031119165001.B34072@forte.austin.ibm.com> (raw)
In-Reply-To: <9851EA7C-1ADC-11D8-AB84-000A95A0560C@us.ibm.com>; from hollisb@us.ibm.com on Wed, Nov 19, 2003 at 04:06:15PM -0600


On Wed, Nov 19, 2003 at 04:06:15PM -0600, Hollis Blanchard wrote:
> On Wednesday, Nov 19, 2003, at 15:51 US/Central, linas@austin.ibm.com
> wrote:
> > Just curious,  these insn's used to be freinds, not enemies.
>
> I think they've always been the enemy of the CPU designers. At least
> that's how it was explained to me from a Motorolan, and I assume the
> same is true for IBM. And they're the ones writing the CPU manuals
> telling people not to use the instructions... :)

Depends on whose CPU designer camp you visit.

DEC Alpha strategy: pump up the clock; minimize number of gate
    delays between start of insn cycle and end of cycle.  Less
    gate delay == faster clock.

Ye olde superscalar strategy: do more per clock cycle by deploying
    more transistors (even if one must have slower clock as a result.)

The load string insn needs a big fat shift register with oodles of
gate delays right in the middle of the load/store path.  No other
insn's need or use this register.   Getting rid of it allows you
to pump up the clock.

The original POWER cpu designers clearly thought it was a worthwhile
tradeoff, otherwise it wouldn't have been in the insn set to begin
with.  But the alpha camp sure made a clear and ringing point ...

--linas

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2003-11-19 22:50 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-15 21:04 kernel oops due to unaligned access with lswi Olaf Hering
2003-11-15 22:24 ` Olaf Hering
2003-11-15 22:30   ` David Edelsohn
2003-11-15 22:37     ` Olaf Hering
2003-11-15 22:43     ` Olaf Hering
2003-11-15 22:59       ` David Edelsohn
2003-11-16 10:17         ` Benjamin Herrenschmidt
2003-11-16 17:49           ` Kumar Gala
2003-11-16 22:19             ` Alan Modra
2003-11-16 22:45               ` Jon Masters
2003-11-17  0:50               ` Paul Mackerras
2003-11-17  7:55                 ` Olaf Hering
2003-11-16 23:12             ` Benjamin Herrenschmidt
2003-11-16 23:31               ` David Edelsohn
2003-11-17  9:19                 ` Gabriel Paubert
2003-11-16 23:04           ` David Edelsohn
2003-11-17  0:40             ` Paul Mackerras
2003-11-19 21:51             ` linas
2003-11-19 22:06               ` Hollis Blanchard
2003-11-19 22:50                 ` linas [this message]
2003-11-16  0:40 ` Paul Mackerras
2003-11-16  1:45   ` Olaf Hering
2003-11-16 16:49     ` Olaf Hering
2003-11-16  5:07   ` Benjamin Herrenschmidt

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=20031119165001.B34072@forte.austin.ibm.com \
    --to=linas@austin.ibm.com \
    --cc=hollisb@us.ibm.com \
    --cc=linuxppc-dev@lists.linuxppc.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 NNTP newsgroup(s).