All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Gabriel Paubert <paubert@iram.es>
To: David Edelsohn <dje@watson.ibm.com>
Cc: "Kevin B. Hendricks" <khendricks@ivey.uwo.ca>,
	Ani Joshi <ajoshi@shell.unixbox.com>,
	Ryuichi Oikawa <roikawa@rr.iij4u.or.jp>,
	linuxppc-dev@lists.linuxppc.org
Subject: Re: Some issues to resolve with XFree 4.0 yet
Date: Wed, 29 Mar 2000 12:45:18 +0200 (METDST)	[thread overview]
Message-ID: <Pine.HPX.4.10.10003291229460.14656-100000@gra-ux1.iram.es> (raw)
In-Reply-To: <200003271913.OAA28080@mal-ach.watson.ibm.com>


On Mon, 27 Mar 2000, David Edelsohn wrote:

>
> 	Gabriel's patch is the correct way to address the problem and
> should be the one which goes into the public sources.

Thanks, and sorry for the delay. I was busy on other fronts (my wife had
surgery on Monday, nothing serious however).

> 	I do not understand, however, why the patch only includes the "=m"
> constraint on regw() and not regw16().  All of the inlined functions
> should have constraints which reference the actual memory address read or
> written to ensure proper dependencies in optimized code.

Well, I overlooked that. What I wanted to insist upon in my patch was that
the volatile was absolutely unnecessary.

Actually, if it were my call I would have declared the variable as
volatile unsigned  char *, which is the right type for address arithmetic
and eliminates any need for cast on byte accesses. I consider minimizing
the number or required casts as the right guideline to choose the variable
type in this case.

BTW, did anybody think of adding a __builtin_byteswap to GCC ?

This would allow the compiler to directly generate *brx instructions on
PPC by combining them with memory loads and stores. I'm aware that it
would require an additional constraint letter for indexed addressing modee
only but this is required for Altivec anyway.

And this would open opportunities for quite a lot of optimizations, for
example when setting or clearing some bits in a device register. In this
latter case (and in the given example) operands are often constants and
the compiler could generate non byte swapped load and stores and byte swap
the constants.

	Gabriel.


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

  parent reply	other threads:[~2000-03-29 10:45 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.10.10003230911180.6826-100000@shell.unixbox.com>
2000-03-23 18:16 ` Some issues to resolve with XFree 4.0 yet Kevin Hendricks
2000-03-25  3:54   ` Found bug in mode switching but who is at fault...XFree86 or aty128fb.c? Kevin Hendricks
2000-03-25  7:57     ` Michel Dänzer
2000-03-25  8:07       ` Michel Dänzer
2000-03-25 13:46     ` Geert Uytterhoeven
2000-03-25 23:50   ` Some issues to resolve with XFree 4.0 yet Kevin Hendricks
2000-03-27 11:09     ` Kostas Gewrgiou
2000-03-27 17:41       ` Ryuichi Oikawa
2000-03-27 18:05         ` Ani Joshi
2000-03-27 19:06           ` Kevin B. Hendricks
2000-03-27 19:13             ` David Edelsohn
2000-03-27 19:20               ` Kevin B. Hendricks
2000-03-27 19:25               ` Ani Joshi
2000-03-27 19:45                 ` David Edelsohn
2000-03-27 19:38                   ` Ani Joshi
2000-03-27 20:01                     ` David Edelsohn
2000-03-27 19:48                 ` Kevin B. Hendricks
2000-03-28  7:59                   ` Geert Uytterhoeven
2000-03-29 10:45               ` Gabriel Paubert [this message]
2000-03-29 13:11                 ` Franz Sirl
2000-03-29 14:58                   ` Gabriel Paubert
2000-03-29 19:39                     ` Franz Sirl
2000-03-28 16:51           ` Ryuichi Oikawa
2000-03-28 17:51             ` Geert Uytterhoeven
     [not found] <Pine.LNX.4.05.10003240806290.5355-100000@callisto.of.borg>
2000-03-24  8:58 ` Michael Schmitz
2000-03-15 14:09 patch to get latest XFree 4.0 snapshot (xf3918) to workonppcwithr128 Kostas Gewrgiou
2000-03-23  4:46 ` Some issues to resolve with XFree 4.0 yet Kevin Hendricks

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=Pine.HPX.4.10.10003291229460.14656-100000@gra-ux1.iram.es \
    --to=paubert@iram.es \
    --cc=ajoshi@shell.unixbox.com \
    --cc=dje@watson.ibm.com \
    --cc=khendricks@ivey.uwo.ca \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=roikawa@rr.iij4u.or.jp \
    /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.