Edit report at http://bugs.php.net/bug.php?id=53310&edit=1
ID: 53310
User updated by: stefan at whocares dot de
Reported by: stefan at whocares dot de
Summary: fpm_atomic.h uses SPARC v9 only code, doesn't work
on v8
Status: Wont fix
Type: Feature/Change Request
Package: FPM related
Operating System: Linux (Debian for Sparc)
PHP Version: 5.3.3
Assigned To: fat
Block user comment: N
Private report: N
New Comment:
Of course you may ask: because I'm porting PHP to the ReadyNAS platform
which
happens to use a SPARC v8 compatible CPU and thus *needs* the v8
instruction set.
Seeing that you've already made up your mind though, so I guess there's
nothing
more to add here. Makes me wonder why I can't get a response in > 24
hours as to
my patch but you can't wait for me to answer for like 4 hours.
Previous Comments:
------------------------------------------------------------------------
[2010-11-16 23:05:04] [email protected]
we've decided sparc < v9 won't be supported. I've just updated the
source code to
warn specificaly about this.
------------------------------------------------------------------------
[2010-11-16 23:02:38] [email protected]
Automatic comment from SVN on behalf of fat
Revision: http://svn.php.net/viewvc/?view=revision&revision=305417
Log: - Fixed #53310 (sparc < v9 won't is not supported)
------------------------------------------------------------------------
[2010-11-16 19:48:36] sriram dot natarajan at gmail dot com
May I know as to why you need to compile with v8 ? compiling with v9
does not
automatically make your application 64-bit . if that is the reason you
want to
choose -v8 in here.
v8 sparc instruction is decade old - http://en.wikipedia.org/wiki/SPARC
and is not
being used in any hardware. so, i see no reason as to why we need to use
/ support
this specific instruction set.
------------------------------------------------------------------------
[2010-11-15 03:05:11] stefan at whocares dot de
Well, I blatantly copied from PostgreSQL's s_lock.h and came up with
this:
diff -Nau fpm_atomic.h.org fpm_atomic.h
--- fpm_atomic.h.org 2009-12-14 09:18:53.000000000 +0000
+++ fpm_atomic.h 2010-11-15 01:50:31.000000000 +0000
@@ -82,7 +82,7 @@
#endif /* defined (__GNUC__) &&... */
#elif ( __sparc__ || __sparc ) /* Marcin Ochab */
-
+#if (__sparc_v9__)
#if (__arch64__ || __arch64)
typedef uint64_t atomic_uint_t;
typedef volatile atomic_uint_t atomic_t;
@@ -118,7 +118,23 @@
}
/* }}} */
#endif
+#else /* sparcv9 */
+typedef uint32_t atomic_uint_t;
+typedef volatile atomic_uint_t atomic_t;
+static inline int atomic_cas_32(atomic_t *lock) /* {{{ */
+{
+ register atomic_uint_t _res;
+ __asm__ __volatile__("ldstub [%2], %0" : "=r"(_res),
"+m"(*lock) : "r"(lock) : "memory");
+ return (int) _res;
+}
+/* }}} */
+
+static inline atomic_uint_t atomic_cmp_set(atomic_t *lock,
atomic_uint_t old,
atomic_uint_t set) /* {{{ */
+{
+ return (atomic_cas_32(lock)==0);
+}
+/* }}} */
#else
#error unsupported processor. please write a patch and send it to me
Rationale:
If I'm reading the original code correctly, there's no actual locking
done but
instead the code only tests whether it could acquire a lock. 'ldstub'
works such
that it returns the current value of the memory region specified and
sets it to
all '1' afterwards. Thus, if the return value is '-1' the lock was
already set
by another process whereas if it's '0' we acquired the lock. Well, at
least in
my certainly flawed logic ;) Since ldstub is atomic I didn't see a need
to
explicitly "lock;" the code.
The patch should leave the 'cas' code intact when being compiled on v9
type
SPARC systems. Tested (for successful compilation only!) on Debian
(etch) using
gcc 3.3.5. Thus I believe further testing is necessary to verify this is
actually working.
Well, please test and incorporate if you feel the code is doing what
it's
supposed to do.
------------------------------------------------------------------------
[2010-11-15 00:53:49] [email protected]
As the sparc documentation says
(http://developers.sun.com/solaris/articles/atomic_sparc/#CAS):
The SPARC v9 manual introduced the newest atomic instruction: compare
and swap
(cas)
I don't know how to fix this right now. If you know someone who can,
he's
welcome. I've already asked for help.
wait and see
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=53310
--
Edit this bug report at http://bugs.php.net/bug.php?id=53310&edit=1
