Fix db48 in powerpc64

[Julio Merino]

Hello,

The databases/db48 port does not build under FreeBSD powerpc64 due to a return type mismatch in an assembly routine.

The patch below fixes the *build*, but I have zero clue if it's correct or not; I'm just following the structure of all other routines.  I'm also pasting below everything related to powerpc in the relevant files, hoping that the comments give enough context.

Could someone that understands powerpc assembly please review this?

Thanks!


----- existing contents -----

/*********************************************************************
 * PowerPC/gcc assembly.
 *********************************************************************/
#if defined(HAVE_MUTEX_PPC_GCC_ASSEMBLY)
typedef u_int32_t tsl_t;

#ifdef LOAD_ACTUAL_MUTEX_CODE
/*
 * The PowerPC does a sort of pseudo-atomic locking.  You set up a
 * 'reservation' on a chunk of memory containing a mutex by loading the
 * mutex value with LWARX.  If the mutex has an 'unlocked' (arbitrary)
 * value, you then try storing into it with STWCX.  If no other process or
 * thread broke your 'reservation' by modifying the memory containing the
 * mutex, then the STCWX succeeds; otherwise it fails and you try to get
 * a reservation again.
 *
 * While mutexes are explicitly 4 bytes, a 'reservation' applies to an
 * entire cache line, normally 32 bytes, aligned naturally.  If the mutex
 * lives near data that gets changed a lot, there's a chance that you'll
 * see more broken reservations than you might otherwise.  The only
 * situation in which this might be a problem is if one processor is
 * beating on a variable in the same cache block as the mutex while another
 * processor tries to acquire the mutex.  That's bad news regardless
 * because of the way it bashes caches, but if you can't guarantee that a
 * mutex will reside in a relatively quiescent cache line, you might
 * consider padding the mutex to force it to live in a cache line by
 * itself.  No, you aren't guaranteed that cache lines are 32 bytes.  Some
 * embedded processors use 16-byte cache lines, while some 64-bit
 * processors use 128-bit cache lines.  But assuming a 32-byte cache line
 * won't get you into trouble for now.
 *
 * If mutex locking is a bottleneck, then you can speed it up by adding a
 * regular LWZ load before the LWARX load, so that you can test for the
 * common case of a locked mutex without wasting cycles making a reservation.
 *
 * gcc/ppc: 0 is clear, 1 is set.
 */
static inline int
MUTEX_SET(int *tsl)  {
        int __r;
        __asm__ volatile (
"0:                             \n\t"
"       lwarx   %0,0,%1         \n\t"
"       cmpwi   %0,0            \n\t"
"       bne-    1f              \n\t"
"       stwcx.  %1,0,%1         \n\t"
"       isync                   \n\t"
"       beq+    2f              \n\t"
"       b       0b              \n\t"
"1:                             \n\t"
"       li      %1,0            \n\t"
"2:                             \n\t"
         : "=&r" (__r), "+r" (tsl)
         :
         : "cr0", "memory");
         return (int)tsl;
}

static inline int
MUTEX_UNSET(tsl_t *tsl) {
         __asm__ volatile("sync" : : : "memory");
         return *tsl = 0;
}
#define MUTEX_INIT(tsl)         MUTEX_UNSET(tsl)
#endif
#endif


----- diff -----

Index: files/patch-dbinc_mutex_int.h
===================================================================
--- files/patch-dbinc_mutex_int.h	(revision 0)
+++ files/patch-dbinc_mutex_int.h	(working copy)
@@ -0,0 +1,11 @@
+--- ../dbinc/mutex_int.h.orig	2014-04-04 12:52:15.255739375 -0400
++++ ../dbinc/mutex_int.h	2014-04-04 12:52:27.454733578 -0400
+@@ -596,7 +596,7 @@ MUTEX_SET(int *tsl)  {
+ 	 : "=&r" (__r), "+r" (tsl)
+ 	 :
+ 	 : "cr0", "memory");
+-	 return (int)tsl;
++	 return !__r;
+ }
+ 
+ static inline int