public inbox for crossgcc@sourceware.org
 help / color / mirror / Atom feed
From: Julien Ducourthial <julien.ducourthial@detexis.thomson-csf.com>
To: Michael Schwingen <rincewind@discworld.dascon.de>
Cc: Roger Racine <rracine@draper.com>, crossgcc@sources.redhat.com
Subject: Re: PowerPC and Volatile
Date: Tue, 05 Dec 2000 06:56:00 -0000	[thread overview]
Message-ID: <3A2D0131.8E57E10A@detexis.thomson-csf.com> (raw)
In-Reply-To: <20001205130927.A14770@a-tuin.dascon.de>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]

Michael Schwingen wrote:
On Tue, Dec 05, 2000 at 10:10:02AM +0100, Julien
Ducourthial wrote:
> Unfortunately there is no such thing on PowerPC, even when set as
non-cached and
> guarded (the most conservative setting) you may get out of order
accesses.
Does this behaviour depend on the specific PPC CPU/MMU used? When working
on
MPC860, setting IO spaces to non-cache/guarded (that was the term I
was
looking for) worked fine without requiring eioio instructions throughout
the
code.
I guess I should re-read that chapter in the manual next week ...
cu
Michael
--
Michael Schwingen, Ahornstrasse 36, 52074 Aachen
------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
The exact behaviour seems to depend on the PPC model. I worked on
a driver for AMD ethernet chip, for an in-house OS. There was no eieio
in the code, but the registers were mapped with guarded and cache-inhibited
mmu attributes. It ran flawlessly on a 603e board. But when we received
newer boards with 604e cpu, the driver wasn't anymore working.
The problem was that the chip internal registers are accessed
through 2 registers (one for address, one for data), so when reading an
internal register you have to first write its adress then read the data.
Without eieio in between, the read is made ahead of the write (at least
on the 604e) and ... you do not really get the data expected.
 
-- 
Julien Ducourthial       julien.ducourthial@detexis.thomson-csf.com 
LDB
Dépt SIA, SBU ISA          
THOMSON-CSF DETEXIS
 

  reply	other threads:[~2000-12-05  6:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-01 12:38 Roger Racine
2000-12-01 12:55 ` Peter Barada
2000-12-05  4:14   ` Roger Racine
2000-12-05  8:01     ` Peter Barada
2000-12-04  2:16 ` Michael Schwingen
2000-12-05  1:13   ` Julien Ducourthial
2000-12-05  6:06     ` Michael Schwingen
2000-12-05  6:56       ` Julien Ducourthial [this message]
2000-12-05 10:22         ` Michael Schwingen

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=3A2D0131.8E57E10A@detexis.thomson-csf.com \
    --to=julien.ducourthial@detexis.thomson-csf.com \
    --cc=crossgcc@sources.redhat.com \
    --cc=rincewind@discworld.dascon.de \
    --cc=rracine@draper.com \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).