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

[Marcus Sundberg <erammsu at kieraypc01 dot p dot y dot ki dot era dot ericsson dot se>]

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.

>  
> -      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)?

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.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se