linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Dan Malek <dan@embeddededge.com>
To: Chris Thomson <cmt@bivio.net>
Cc: acurtis@onz.com, "'Paul Mackerras'" <paulus@samba.org>,
	linuxppc-dev@lists.linuxppc.org
Subject: Re: eieio rule-of-thumb?
Date: Thu, 23 May 2002 15:02:10 -0400	[thread overview]
Message-ID: <3CED3CB2.1080803@embeddededge.com> (raw)
In-Reply-To: 000001c20281$a98be6b0$9502a8c0@cthomson59


Chris Thomson wrote:

> Eieio instructions are needed for CPUs based on the 745x core.
> These are the 7445, 7450, 7451 and 7455.

The eieio is needed on many of the processors, I just got lucky
on some of them :-)

> Earlier PPC implementations never reordered guarded, or even
> uncached, accesses.  Motorola made a big deal about this in its
> embedded sales.  All you had to do was set the WIMG bits right.

The 74xx is a little confusing, but I don't think it really changed
any semantics.  Loads from uncached and guarded spaces are still
performed in order.  Writes to such spaces are not gathered and are
performed in order.  I think there was some fine tuning of pipelines
that may cause writes to hang around in a buffer longer than they
did on previous processors (and there is this funny description of
a cache line load if all of them would be executed).  The only
confusing part is how the cache inhibit or guarded attribute controls
this behavior.  The eieio is still necessary to ensure a load doesn't
cross a pending store.

The eieio further performs a broadcast bus operation which can be
used by external bridges to prevent them from performing a store
gathering (write combining as Ben said :-) if necessary.

I know there is something a little different with the 74xx, because
when I received one of the first 7450s for my Sandpoint the PCI I/O
didn't work exactly correct.  A couple of minor bug fixes suitable to
all processors cured it.

> Evidently Motorola decided that getting the extra performance
> of reordering was needed to keep the Apple account.

You could probably say that of Altivec, but I don't see any difference
with the reordering behavior of the processors.  Anything we see is likely
to be an effect of significantly improving the performance of the normal
superscalar mode of operation.

Thanks.


	-- Dan


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

  reply	other threads:[~2002-05-23 19:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-22  4:43 eieio rule-of-thumb? Allen Curtis
2002-05-22  6:01 ` Paul Mackerras
2002-05-23  2:25   ` Allen Curtis
2002-05-23  4:26     ` Paul Mackerras
2002-05-23 13:38       ` Allen Curtis
2002-05-23 13:54         ` Dan Brennan
2002-05-23 14:42           ` Allen Curtis
2002-05-23 17:28         ` Dan Malek
2002-05-23 17:45           ` Chris Thomson
2002-05-23 19:02             ` Dan Malek [this message]
2002-05-23 22:36             ` Paul Mackerras
2002-05-23 18:44           ` benh
2002-05-23 18:02             ` Dan Malek
2002-05-23 22:58               ` Paul Mackerras

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=3CED3CB2.1080803@embeddededge.com \
    --to=dan@embeddededge.com \
    --cc=acurtis@onz.com \
    --cc=cmt@bivio.net \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=paulus@samba.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).