linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
To: Gabriel Paubert <paubert@iram.es>,
	Kevin Hendricks <khendricks@ivey.uwo.ca>
Cc: David Edelsohn <dje@watson.ibm.com>, linuxppc-dev@lists.linuxppc.org
Subject: Re: Fwd: Re: still no accelerated X ($#!$*)
Date: Thu, 20 Jan 2000 23:34:23 +0100	[thread overview]
Message-ID: <00012023473100.01038@enzo.bigblue.local> (raw)
In-Reply-To: <Pine.HPX.4.10.10001202043560.18916-100000@gra-ux1.iram.es>


Am Don, 20 Jan 2000 schrieb Gabriel Paubert:
>Hi,
>
>> In this particular case, the base address can change (but very very rarely
>> such as writing to one Aperature or Another on the Rage 128 card) and all of
>> the writes are made to either the card memory mapped io or the frame buffer
>> itself.
>
>Then the memory clobber would force the compiler to reload base_addr
>between 2 writes to the frame buffer.
>
>> Should I not include the : "memory" clobber in this case?  Will it hurt
>> performance much?
>
>I think that it is not necessary: the best thing with a compiler which
>performs alias analysis might be to tell the truth
>
>asm ("stwbrx %1,%2,%3"
>     : "=m" (*(volatile unsigned *)(base_addr+regindex))
>     : "r" (regdata), "b" (base_addr), "r" (regindex));
>
>Note we don't use %0, and it won't produce any aditional code. You may
>want to check what the compiler would have generated as addressing mode
>by appending " # %0" at the end of the code string.

It depends a little bit on the usage of the asm's if the memory (either
global or local) clobber is needed or not. If you use them for read/writes to HW
registers needing ordering (which is very likely here since we talk about
graphics HW), the compiler can only decide on the memory usage defined by the
clobbers/memory inputs on how to order the inlines (volatile has no effect on
this).

Actually the load instructions need a memory input too:

asm volatile ("lwbrx %0,%1,%2" : "=r"(val) : "b"(regindex), "r"(base_addr),
"m" (*(volatile unsigned *)(base_addr+regindex)));

And to insure ordering on processor level you still need the eieio (with a
memory clobber) as usual.

Franz.

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

  parent reply	other threads:[~2000-01-20 22:34 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Message from Kevin Hendricks <khendricks@ivey.uwo.ca>
2000-01-20 18:12 ` Fwd: Re: still no accelerated X ($#!$*) Kevin Hendricks
2000-01-20 18:26   ` David Edelsohn
2000-01-20 18:45     ` Benjamin Herrenschmidt
2000-01-20 18:51       ` David Edelsohn
2000-01-20 18:52     ` Franz Sirl
2000-01-20 19:31       ` Gabriel Paubert
2000-01-20 19:36         ` Kevin Hendricks
2000-01-20 19:51           ` Geert Uytterhoeven
2000-01-20 19:59           ` Gabriel Paubert
2000-01-20 20:08             ` David Edelsohn
2000-01-20 22:34             ` Franz Sirl [this message]
2000-01-21  0:05               ` Gabriel Paubert
2000-01-21  0:35                 ` Kevin Hendricks
2000-01-21  1:53                   ` Gabriel Paubert
2000-01-21  2:19                     ` Kevin Hendricks
2000-01-21  7:58                       ` Geert Uytterhoeven
2000-01-21 14:15                       ` Benjamin Herrenschmidt
2000-01-22 20:54                         ` [linux-fbdev] " anthony tong
2000-01-23  2:44                           ` Kevin Hendricks
2000-01-21 11:54                   ` Benjamin Herrenschmidt
2000-01-21 13:34                     ` Gabriel Paubert
2000-01-21 14:06                       ` Benjamin Herrenschmidt
2000-01-21 15:47                 ` Franz Sirl
2000-01-21 19:08                   ` Gabriel Paubert
2000-01-20 18:46   ` Franz Sirl
2000-01-21 13:53 Kevin_Hendricks
     [not found] <200001211355.NAA05477@granada.iram.es>
2000-01-21 15:13 ` Gabriel Paubert
2000-01-21 15:29   ` Benjamin Herrenschmidt
  -- strict thread matches above, loose matches on Subject: below --
2000-01-21 17:32 David Edelsohn
2000-01-21 20:25 jlquinn
2000-01-23 13:06 ` Gabriel Paubert

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=00012023473100.01038@enzo.bigblue.local \
    --to=franz.sirl-kernel@lauterbach.com \
    --cc=dje@watson.ibm.com \
    --cc=khendricks@ivey.uwo.ca \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=paubert@iram.es \
    /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).