linuxppc-dev.lists.ozlabs.org archive mirror
 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 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).