Re: Let's see if _this_ works...

[Geoff Keating <geoffk at ozemail dot com dot au>]

> Cc: libc-alpha@sourceware.cygnus.com
> From: Marcus Sundberg <erammsu@kieraypc01.p.y.ki.era.ericsson.se>
> Date: 24 Nov 1999 17:16:24 +0100
> User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.3
> 
> Geoff Keating <geoffk@ozemail.com.au> writes:
> 
> This is not really about the patch, but relevant for dl-machine.c
> regardless of whether this patch is applied or not.
> 
> > --- libc/sysdeps/powerpc/dl-machine.c.p56b	Thu Oct  7 21:12:54 1999
> > +++ libc/sysdeps/powerpc/dl-machine.c	Mon Nov 15 17:48:11 1999
> > @@ -136,126 +143,172 @@ __elf_preferred_address(struct link_map 
> 
> [snip]
> 
> >  	 Assumes the cache line size is at least 32 bytes, or at least
> > -	 that dcbst and icbi apply to 32-byte lines. At present, all
> > +	 that dcbst and icbi apply to 32-byte lines.  At present, all
> >  	 PowerPC processors have line sizes of exactly 32 bytes.  */
> 
> This is not true. The Motorola 8xx series of processors have a 
> line size of 16 bytes.

Grrr.  They shouldn't do that.

> >  
> > -      size_modified = lazy ? rel_offset_words : PLT_INITIAL_ENTRY_WORDS;
> > -      for (i = 0; i < size_modified; i+= 8)
> > +      size_modified = lazy ? rel_offset_words : 6;
> > +      for (i = 0; i < size_modified; i += 8)
> >  	PPC_DCBST (plt + i);
> 
> How performance critical is this code? Would changing 8 ==> 4 affect
> performance at all? (the bottleneck should be pushing the data to the
> L2 cache or RAM anyway, not executing the loop, right?)
> Or will this have to be a compile-time option (bad)?

I think that if you do a dcbst on a block which is not modified in the
cache, it'll be much faster.  So it'd probably be OK to change the
'8'.

Note that this has been assuming this line size since I wrote it---if
you haven't noticed any problems, you can safely say that the 8xx do
have a 32-bit (or more) line size.

Annoyingly, the PowerPC architecture explicitly says that it is
undefined what size cache lines are.

> Then there is the issue of memset.S, which also assumes a cache line
> size of 32 bytes. Currently I simply move it away when I build glibc,
> but it would be nice if that could be solved as well. Now that there
> is FP-emulation for PPC in the kernel the cache line issue is the
> only thing preventing the same glibc binary from running on 8xx and
> other PPC cpus.

I really don't want to halve the speed of bzero() for all machines.
Any other ideas?

-- 
Geoffrey Keating <geoffk@cygnus.com>