From: Brendan J Simon <Brendan.Simon@ctam.com.au>
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
Date: Fri, 07 Jan 2000 12:44:41 +1100 [thread overview]
Message-ID: <38754508.976B932F@ctam.com.au> (raw)
In-Reply-To: otg0wb8hk8.fsf@thinktwice.zoftcorp.dk
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
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2000-01-07 1:44 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
2000-01-07 1:44 ` Brendan J Simon [this message]
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=38754508.976B932F@ctam.com.au \
--to=brendan.simon@ctam.com.au \
--cc=glibc-linux@ricardo.ecn.wfu.edu \
--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).