linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Jesper Skov <jskov@cygnus.co.uk>
To: greyham@research.canon.com.au (Graham Stoney)
Cc: Brendan.Simon@ctam.com.au,
	linuxppc-dev@lists.linuxppc.org (linuxppc-dev),
	linuxppc-embedded@lists.linuxppc.org (linuxppc-embedded),
	dmalek@jlc.net
Subject: Re: MPC860 patches for glibc
Date: 06 Jan 2000 14:18:15 +0100	[thread overview]
Message-ID: <otg0wb8hk8.fsf@thinktwice.zoftcorp.dk> (raw)
In-Reply-To: greyham@research.canon.com.au's message of "Thu, 6 Jan 2000 10:36:06 +1100 (EST)"


>>>>> "Graham" == Graham Stoney <greyham@research.canon.com.au> writes:

Graham> Brendan J Simon writes:
>> I didn't realise there were 860 patches for glibc.  Where can I get
>> these patches from ?

Graham> The magic mailing list archive, of course (-:

Graham> http://lists.linuxppc.org/listarcs/linuxppc-embedded/199909/msg00000.html

>> What do they do ?

Graham> Fix the cache line size for dynamic loading, and rearrange the
Graham> FPU stuff so it doesn't get included when you build.

I think the below patch for dl-machine.c would be better. It incurs no
loop overhead on the 32-byte cache line CPUs - and I think the double
flush of the same line should be harmless (and cheaper than the loop
overhead).

There is one small potential for error; if the macro is called with a
(32-byte aligned pointer)+16/17/18...31 in which case the first 16
bytes (of the 32-byte aligned address) would not be flushed on a 8xx,
while they would be on a bigger CPU. (did that make any sense at all ;)

Comments? Is it as safe/sensible as I think it is?

Thanks,
Jesper

--- powerpc/dl-machine.c~	Fri Mar  5 00:26:43 1999
+++ powerpc/dl-machine.c	Thu Jan  6 14:09:34 2000
@@ -63,10 +63,17 @@
 #define OPCODE_SLWI(ra,rs,sh) OPCODE_RLWINM(ra,rs,sh,0,31-sh)
 
 
-#define PPC_DCBST(where) asm ("dcbst 0,%0" : : "r"(where) : "memory")
+/* The macros dealing with cache lines affect both (where) and
+   (where+16).  This is in order to support the 8xx CPUs which have
+   16-byte cache lines.  On the CPUs with 32-byte cache lines this
+   should have no noticable effect as the first store instruction
+   would effectively make the second instruction a NOP (since the line
+   would no longer be dirty). */
+#define PPC_DCBST(where) asm ("dcbst 0,%0;dcbst 0,%1" : : "r"(where), "r"((unsigned long)(where)+16) : "memory")
+#define PPC_ICBI(where) asm ("icbi 0,%0;icbi 0,%1" : : "r"(where), "r"((unsigned long)(where)+16) : "memory")
+
 #define PPC_SYNC asm ("sync" : : : "memory")
 #define PPC_ISYNC asm volatile ("sync; isync" : : : "memory")
-#define PPC_ICBI(where) asm ("icbi 0,%0" : : "r"(where) : "memory")
 #define PPC_DIE asm volatile ("tweq 0,0")
 
 /* Use this when you've modified some code, but it won't be in the

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

  reply	other threads:[~2000-01-06 13:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-01-04 23:00 Linux ABI documents and powerpc supplements Brendan J Simon
2000-01-05  0:23 ` Franz Sirl
2000-01-05  5:08   ` Brendan J Simon
2000-01-05  6:46     ` Momchil 'Velco' Velikov
2000-01-05  6:21       ` Brendan J Simon
2000-01-05 10:19         ` Michael Schmitz
2000-01-05  7:04       ` dynamic binaries not working Brendan J Simon
2000-01-05  8:34         ` Daniel Jacobowitz
2000-01-05 12:47         ` Kenneth Johansson
2000-01-05 22:24           ` MPC860 patches for glibc Brendan J Simon
2000-01-05 23:36             ` Graham Stoney
2000-01-06 13:18               ` Jesper Skov [this message]
2000-01-07  1:44                 ` Brendan J Simon
2000-01-08  8:46                   ` Jesper Skov

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=otg0wb8hk8.fsf@thinktwice.zoftcorp.dk \
    --to=jskov@cygnus.co.uk \
    --cc=Brendan.Simon@ctam.com.au \
    --cc=dmalek@jlc.net \
    --cc=greyham@research.canon.com.au \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=linuxppc-embedded@lists.linuxppc.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).