pthread locking code - C vs. ASM

Gilles Carry Gilles.Carry@bull.net
Mon Jan 21 16:35:00 GMT 2008


Mike Frysinger wrote:
> On Saturday 19 January 2008, Clemens Kolbitsch wrote:
> 
>>Why are some (e.g. locking) functions implemented twice -- once in C and
>>once in assembler?
> 
> 
> why is anything written in assembler ?  for optimization.
> 
> 
>>Is the C code used to get an asselber starting point 
>>which is then optimized and saved into a second file?
> 
> 
> that is one way of looking at it.  you write the generic C version for 
> everyone to use and if there's enough interest, re-implement it for a 
> specific operating system/architecture in assembly.  if an appropriate 
> optimized version exists in the source tree, glibc will use that, otherwise 
> it'll default to the generic C version.
> 
> 
>>For example pthread_rwlock_unlock is implemented in
>>source/nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_rwlock_unlock.S
>>and
>>source/nptl/pthread_rwlock_unlock.c
>>
>>If I modify the asm code only, is there a chance that some script (e.g.
>>during make clean && make) will overwrite my changes or is the ASM code the
>>correct place to edit things (otherwise I don't see my modifications being
>>linked into the binary...)?
> 
> 
> no, that is not how the build system works.  pretty much all assembly code in 
> glibc is hand written and not autogenerated.  glibc uses search paths 
> depending on your operating system, target architecture, and specific cpu to 
> figure out which implementation to use.
> 
> if your target operating system is linux, the target architecture is i386, and 
> the specific cpu implementation is i486, then 
> nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_rwlock_unlock.S is the file to 
> modify.  if your target is {linux,i386,i686}, then you should actually look 
> at nptl/sysdeps/unix/sysv/linux/i386/i686/pthread_rwlock_unlock.S.
> -mike

Is asm code supposed to do exactly the same as C code?
I recently had a case when I wanted to modify pthread_cond_signal.c and it did not compile
because of unexisting syscall macros.
Should C code be the reference? Should asm be modified only when we are sure C is ok?
It is a problem when people change asm code without updating the underlying C files.

-gilles



More information about the Libc-alpha mailing list