linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Gabriel Paubert <paubert@iram.es>
To: Becky Bruce <becky.bruce@freescale.com>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	linuxppc64-dev <linuxppc64-dev@ozlabs.org>
Subject: Re: [PATCH] powerpc: Merge align.c
Date: Wed, 16 Nov 2005 10:36:09 +0100	[thread overview]
Message-ID: <20051116093609.GA26269@iram.es> (raw)
In-Reply-To: <00eecfdbd5bccc7b293d847033121eee@freescale.com>

On Tue, Nov 15, 2005 at 08:19:58PM -0600, Becky Bruce wrote:
> Ben,
> 
> Yeah,  I clearly shouldn't run testcases at 11pm, because I got in a 
> rush and only confirmed that lmw/stmw were actually taking the 
> exception.  Those 2 are working beautifully.  To test the others, I 
> need to run on a different board which, of course,  isn't bootable at 
> the moment.  As soon as I can get that up and running, I'll try some of 
> 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 
> alignment-exception-causing events on FSL's current parts (603, 603e, 
> 750, 74x, 74xx, e500) is:

The 603 is still in production? And is the upcoming 8641 exactly 
the same as the 74xx series in this respect? 

> 
> - lmw/stmw (all procs, non-word aligned)

Do we really want to emulate these instructions? 

Their purpose is to minimize code size in functions prologue and
epilogue. If you hit an alignment execption with lwm/stmw, your 
stack is probably misaligned for some stupid reason or bug (back 
chain pointer corrrupted because of some buffer overflow comes to 
mind, and you want to know ASAP).

> - single and double precision floating point ld/st ops (non-E500, non 
> data size aligned)

Hmm, you can load a double from any 4 byte aligned address AFAIR.

> - dcbz to WT or CI memory (all procs)
> - dcbz with cache disabled (all procs but 603e?)
> - misaligned little endian accesses (603e)

I understand that you mention it for completeness since we 
don't care about LE mode AFAICT. But I believe that there
were some differences between 603 and 603e in this area.

However we do care about byte reversal instructions, which 
probably believe like the corresponding normal instruction
(i.e., lwbrx has the same rules as lwzx, etc.)

> - lwarx/stwcx (all procs)

And ldarx/stdcx. on 64 bit, but these ones should not 
be emulated. So it's easy ;-)

> - multiple/string with LE set (750, 603e, 7450, 7400)

Again LE mode is probably irrelevant.

> - eciwx/ecowx (750, 7450, 7400)

Have these instructions ever been used for something 
under Linux?

> - a couple of others related to vector processing

Which ones? The Altivec load and store instructions
simply mask the low order bits AFAIR.

> If anybody knows offhand of something missing there, let me know.

Nothing, but did you check when crossing a segment (256MB) boundary.
I seem to remember that some processors performed misaligned 
load/store across pages but not across segments.

	Regards,
	Gabriel

  parent reply	other threads:[~2005-11-16  9:36 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
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 [this message]
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=20051116093609.GA26269@iram.es \
    --to=paubert@iram.es \
    --cc=becky.bruce@freescale.com \
    --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 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).