All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gabriel Paubert <paubert@iram.es>
To: David Edelsohn <dje@watson.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Kumar Gala <kumar.gala@motorola.com>, Olaf Hering <olh@suse.de>,
	linuxppc-dev list <linuxppc-dev@lists.linuxppc.org>,
	Alan Modra <amodra@bigpond.net.au>
Subject: Re: kernel oops due to unaligned access with lswi
Date: Mon, 17 Nov 2003 10:19:59 +0100	[thread overview]
Message-ID: <20031117091959.GA28611@iram.es> (raw)
In-Reply-To: <200311162331.hAGNVjT29698@makai.watson.ibm.com>


On Sun, Nov 16, 2003 at 06:31:45PM -0500, David Edelsohn wrote:
>
> >>>>> Benjamin Herrenschmidt writes:
>
> Ben> We surely don't want them on G5 at least as they are microcoded
>
> 	Again, one cannot approach this as black or white.  What about
> optimizing for size?

Using lswi/stswi is fine when optimizing for size, but I think
that using these instructions for the case of an 8 byte
move is wrong in most cases because an additional instruction
is often (but not always) needed to compute the address.

Moving 8 bytes with lswi/stswi:

	la rx,src # compute source address
	lswi 5,rx,8
	la ry, dst# compute destination address
	stswi 5,ry,8

Moving 8 bytes with standard instructions:

	lwz rx,src
	lwz ry,src+4
	stw rx,dst
	stw ry,dst+4

IMHO, lswi/stswi should only be used when the move
would be split into 3 or more l[bhw]z/st[bhw] pairs
(i.e., for sizes of 7 or 9 and up).

	Regards,
	Gabriel

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

  reply	other threads:[~2003-11-17  9:19 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 [this message]
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
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=20031117091959.GA28611@iram.es \
    --to=paubert@iram.es \
    --cc=amodra@bigpond.net.au \
    --cc=benh@kernel.crashing.org \
    --cc=dje@watson.ibm.com \
    --cc=kumar.gala@motorola.com \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=olh@suse.de \
    /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.