This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
REJECTION
- To: glibc-linux at ricardo dot ecn dot wfu dot edu
- Subject: REJECTION
- From: Mail Delivery System <Mailer-Daemon at ls dot anomalous dot net>
- Date: Sat, 8 Jan 2000 15:14:22 -0600
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
All future mailings will bounce. Remove us from your list(s).
------ This is a copy of the message, including all the headers. ------
Received: from localhost ([127.0.0.1] ident=jmshack)
by home.com with esmtp (Exim 2.02 #1)
id 1273Bm-0000BV-02
for jmshack@lsmtsrvr1.ls.anomalous.net; Sat, 8 Jan 2000 15:14:22 -0600
Received: from netmail.home.com
by localhost with POP3 (fetchmail-5.1.0)
for jmshack@lsmtsrvr1.ls.anomalous.net (single-drop); Sat, 08 Jan 2000 15:14:22 -0600 (CST)
Received: from h1.mail.home.com ([24.0.0.50]) by mail.rdc1.il.home.com
(InterMail v4.01.01.00 201-229-111) with ESMTP
id <20000107042038.UKOK26071.mail.rdc1.il.home.com@h1.mail.home.com>
for <jmshack@mail.mntp1.il.home.com>;
Thu, 6 Jan 2000 20:20:38 -0800
Received: from mx1-w.mail.home.com (mx1-w.mail.home.com [24.0.0.51])
by h1.mail.home.com (8.9.3/8.9.0) with ESMTP id UAA04988;
Thu, 6 Jan 2000 20:20:37 -0800 (PST)
Received: from ricardo.ecn.wfu.edu (ricardo.ecn.wfu.edu [152.17.150.2])
by mx1-w.mail.home.com (8.9.1/8.9.1) with ESMTP id UAA29070;
Thu, 6 Jan 2000 20:20:36 -0800 (PST)
Received: (from majordom@localhost)
by ricardo.ecn.wfu.edu (8.9.3/8.9.1) id VAA14408
for glibc-linux-outgoing; Thu, 6 Jan 2000 21:44:55 -0500
X-Authentication-Warning: ricardo.ecn.wfu.edu: majordom set sender to owner-glibc-linux@ricardo.ecn.wfu.edu using -f
Received: from k9.prophecy.com.au (IDENT:root@ctam160.prophecy.com.au [203.21.127.160])
by ricardo.ecn.wfu.edu (8.9.3/8.9.1) with ESMTP id VAA14402
for <glibc-linux@ricardo.ecn.wfu.edu>; Thu, 6 Jan 2000 21:44:48 -0500
Received: from ctam.com.au (brendan@localhost [127.0.0.1])
by k9.prophecy.com.au (8.8.7/8.8.7) with ESMTP id MAA05001;
Fri, 7 Jan 2000 12:44:42 +1100
Message-ID: <38754508.976B932F@ctam.com.au>
Date: Fri, 07 Jan 2000 12:44:41 +1100
From: Brendan J Simon <Brendan.Simon@ctam.com.au>
Organization: CTAM Pty Ltd, Australia.
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
CC: linuxppc-dev <linuxppc-dev@lists.linuxppc.org>,
linuxppc-embedded <linuxppc-embedded@lists.linuxppc.org>,
glibc-linux <glibc-linux@ricardo.ecn.wfu.edu>
Subject: Re: MPC860 patches for glibc
References: <20000105233607.0D48DED@elph.research.canon.com.au> <otg0wb8hk8.fsf@thinktwice.zoftcorp.dk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-glibc-linux@ricardo.ecn.wfu.edu
Precedence: bulk
Reply-To: glibc-linux@ricardo.ecn.wfu.edu
Would the changes suggested below, to the cache line size (mpc8xx = 16 bytes, others = 32 bytes) make any difference
if my Instruction Cache and Data Cache was disabled. My current linux kernel has them all disabled for now.
Brendan Simon.
Jesper Skov wrote:
> >>>>> "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