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/
next prev parent 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 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.