This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] memset.S and PowerPC


David Mueller wrote>

> AFAICS the memset.S in sysdeps/powerpc is broken for PowerPC 
> implementations with cache line sizes other than 8 words.
> My current work-around is to delete this specific memset.S file. Is 
> there a smarter way of doing it?

Here is a simple patch that makes memset.S safe for all PowerPC 
implementations. It is a bit slower for bzero but is still faster 
then the ./generic/memset.c

>>>>>>>>>>>
*** glibc-2.2.5/sysdeps/powerpc/memset.S	Thu Jul  5 23:56:01 2001
--- libc225/sysdeps/powerpc/memset.S	Tue May 21 16:02:00 2002
***************
*** 106,110 ****
  	clrrwi.	rALIGN, rLEN, 5
  	mtcrf	0x01, rLEN	/* 40th instruction from .align */
! 	beq	cr1, L(zloopstart) /* special case for clearing memory using dcbz */
  	srwi	rTMP, rALIGN, 5
  	mtctr	rTMP
--- 106,113 ----
  	clrrwi.	rALIGN, rLEN, 5
  	mtcrf	0x01, rLEN	/* 40th instruction from .align */
! /* SJM this is a problem since it assumes that all data caches are 32 bytes
!     so disable this code for now
! 	beq	cr1, L(zloopstart) * special case for clearing memory using dcbz */
! 	nop
  	srwi	rTMP, rALIGN, 5
  	mtctr	rTMP
***************
*** 115,119 ****
  	bdz	L(cloopdone)	/* 48th instruction from .align */
  
! L(c3):	dcbz	rNEG64, rMEMP
  	stw	rCHR, -4(rMEMP)
  	stw	rCHR, -8(rMEMP)
--- 118,124 ----
  	bdz	L(cloopdone)	/* 48th instruction from .align */
  
! /* SJM this is a problem since it assumes that all data caches are 32 bytes
!     change to a touch which is safe */
! L(c3):	dcbt	rNEG64, rMEMP
  	stw	rCHR, -4(rMEMP)
  	stw	rCHR, -8(rMEMP)

<<<<<<<<<<<<

> I've heard that there are some ideas of using a variable (exported by 
> the OS kernel) to give glibc a chance to adapt itself to the cache line 
> size of the hardware. What's the status of this idea/project? Anybody 
> using it already?

The newer kernels do pass the cache size in the Aux Vector. It is simple
enough to scan the Aux Vector in libc-start.c but it has proven problematic.

The obvious hack is to define a static int in memset.s (now memset.s needs
to set up and access the GOT) and have libc-start store the cache size 
into it. Tom Gall tried this but it created a circular dependency between
ld.so and libc-start and the build failed. We dropped it there, should get
back to it soon ...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]