From: Becky Bruce <becky.bruce@freescale.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc64-dev <linuxppc64-dev@ozlabs.org>,
linuxppc-dev list <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH] powerpc: Merge align.c
Date: Tue, 15 Nov 2005 20:19:58 -0600 [thread overview]
Message-ID: <00eecfdbd5bccc7b293d847033121eee@freescale.com> (raw)
In-Reply-To: <1132032910.23979.6.camel@gaston>
Ben,
Yeah, I clearly shouldn't run testcases at 11pm, because I got in a=20
rush and only confirmed that lmw/stmw were actually taking the=20
exception. Those 2 are working beautifully. To test the others, I=20
need to run on a different board which, of course, isn't bootable at=20
the moment. As soon as I can get that up and running, I'll try some of=20=
the other cases and let you know how it goes......
BTW, Based on the pile of docs I have here, I think the list of=20
alignment-exception-causing events on FSL's current parts (603, 603e,=20
750, 74x, 74xx, e500) is:
- lmw/stmw (all procs, non-word aligned)
- single and double precision floating point ld/st ops (non-E500, non=20
data size aligned)
- dcbz to WT or CI memory (all procs)
- dcbz with cache disabled (all procs but 603e?)
- misaligned little endian accesses (603e)
- lwarx/stwcx (all procs)
- multiple/string with LE set (750, 603e, 7450, 7400)
- eciwx/ecowx (750, 7450, 7400)
- a couple of others related to vector processing
If anybody knows offhand of something missing there, let me know.
Cheers,
B
On Nov 14, 2005, at 11:35 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2005-11-14 at 23:10 -0600, Becky Bruce wrote:
> > Ben,
> >
> > I've just done some basic testing of lmw/stmw, lwz/stw, lhx/sth,
> > lfs/stfs, and lfd/stfd misaligned across a doubleword boundary, and
> > everything looks good so far.=A0=A0 I'll check out the byte =
reversals=20
> and a
> > few other forms tomorrow.
>
> Excellent, thanks ! BTW. Make sure you test these one CPUs that=20
> actually
> trap on misaligned accesses :) Best is probably to do the misaligned
> access accross a page boundary, that's what most CPUs can do.
>
> Ben.
>
next prev parent reply other threads:[~2005-11-16 2:19 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-14 8:00 [PATCH] powerpc: Merge align.c Benjamin Herrenschmidt
2005-11-14 19:53 ` Becky Bruce
2005-11-14 20:55 ` Benjamin Herrenschmidt
2005-11-15 5:10 ` Becky Bruce
2005-11-15 5:35 ` Benjamin Herrenschmidt
2005-11-16 2:19 ` Becky Bruce [this message]
2005-11-16 2:34 ` Benjamin Herrenschmidt
2005-11-16 3:23 ` Becky Bruce
2005-11-16 16:54 ` Andrey Volkov
2005-11-16 4:26 ` Dan Malek
2005-11-16 5:00 ` Benjamin Herrenschmidt
2005-11-16 5:35 ` Dan Malek
2005-11-16 6:13 ` Benjamin Herrenschmidt
2005-11-16 9:36 ` Gabriel Paubert
2005-11-16 15:15 ` Kumar Gala
2005-11-16 16:31 ` Becky Bruce
2005-11-16 19:24 ` Dan Malek
2005-11-16 19:20 ` Dan Malek
2005-11-16 19:45 ` Gabriel Paubert
2005-11-16 20:36 ` Dan Malek
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=00eecfdbd5bccc7b293d847033121eee@freescale.com \
--to=becky.bruce@freescale.com \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=linuxppc64-dev@ozlabs.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 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.