GPSEE on armv7hl
Jeff Johnson
cc -Wall -Wwrite-strings -Wcast-align -Wstrict-aliasing=2 -Wwrite-strings -Winline -g -O1 -fPIC -D_GNU_SOURCE -DGPSEE -I/X/src/gpsee -I/X/src/gpsee/spidermonkey/builds/release/jsapi/include/js -I/usr/include/nspr4 -c -o gpsee.o gpsee.c
In file included from gpsee.h:611:0,
from gpsee.c:52:
/X/src/gpsee/gpsee_lock.c:222:3: error: #error "Define NSPR_LOCK if your platform lacks a compare-and-swap instruction."
In file included from gpsee.c:52:0:
gpsee.h: In function ‘jsval_CompareAndSwap’:
gpsee.h:617:3: warning: implicit declaration of function ‘js_CompareAndSwap’ [-Wimplicit-function-declaration]
This is a panda board and a armv7hl architecture:
Linux panda3.jbj.org 2.6.40.3-0.fc15.armv7hl.omap #1 SMP PREEMPT Wed Aug 17 18:55:49 EDT 2011 armv7l armv7l armv7l GNU/Linux
Its a dual Cortex-A9 at 1Ghz with 1Gb … patches shortly, NSPR hackery ain't hard.
I've also succeeded building GPSEE-0.2 on the G5, will try to fold in the PPC
JIT code as soon as I catch up with GPSEE 0.3.
73 de Jeff
Wes Garland
You should hack gpsee_lock.c to support CAS for the new architecture; we've never built on ARM before.
The code in gpsee_lock.c is stolen from (and mega-simplified from) jslock.c from JS 1.7 or JS 1.8. But the only thing we care about is the compare-and-swap routines.
Falling back to PR_LOCK, as the warning suggests, would work but suck. Faking hardware CAS with PRLock sucks; PRLock is either pthread_mutex_* or -- most vomitaticiously -- fcntl(FSETLK_W), depending on the platform.
Wes
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
Jeff Johnson
On Sep 20, 2011, at 5:36 PM, Wes Garland wrote:
> Hey, Jeff;
>
> You should hack gpsee_lock.c to support CAS for the new architecture; we've never built on ARM before.
>
> The code in gpsee_lock.c is stolen from (and mega-simplified from) jslock.c from JS 1.7 or JS 1.8. But the only thing we care about is the compare-and-swap routines.
>
> Falling back to PR_LOCK, as the warning suggests, would work but suck. Faking hardware CAS with PRLock sucks; PRLock is either pthread_mutex_* or -- most vomitaticiously -- fcntl(FSETLK_W), depending on the platform.
>
WORKSFORME (but I would not trust these wild hacks yet: lemme figger what is *really* needed)
[jbj@panda3 gpsee]$ gsr -c 'print("w00t!")
'w00t!
[jbj@panda3 gpsee]$ uname -a
Linux panda3.jbj.org 2.6.40.3-0.fc15.armv7hl.omap #1 SMP PREEMPT Wed Aug 17 18:55:49 EDT 2011 armv7l armv7l armv7l GNU/Linux
I now have gpsee 0.2 built on Lion(x86_64), Leopard(ppc64), RHEL6(x86_64) and the panda board.
Let's peep at GPSEE 0.3 + JS 1.8.5 next: todo++
hth
73 de Jeff
=======================================
diff -r 2d3417f15927 gpsee_lock.c
--- a/gpsee_lock.c Mon Sep 19 14:38:45 2011 -0400
+++ b/gpsee_lock.c Tue Sep 20 18:25:49 2011 -0400
@@ -180,6 +180,31 @@
: "cc", "memory");
return (int)res;
}
+#elif defined(__GNUC__) && defined(__arm__)
+/* XXX perhaps defined(__ARM_ARCH_7A__) or similar? */
+/* XXX swiped from
+ * http://code.google.com/p/armv6-atomic/downloads/detail?name=armv6_atomic.h
+ */
+static JS_ALWAYS_INLINE int
+js_CompareAndSwap(jsword *w, jsword ov, jsword nv)
+{
+ register unsigned int res;
+
+ __asm__ __volatile__ (
+ "ldrex r0, [%1]\n\t" /* exclusive load of w */
+ "cmp r0, %2\n\t" /* compare the ov == *w */
+#if defined(__thumb__)
+ "ite eq\n\t"
+#endif
+ "strexeq %0, %3, [%1]\n\t" /* store if eq, strex+eq */
+#if defined(__thumb__)
+ "clrexne"
+#endif
+ : "=&r" (res)
+ : "r" (w), "r" (ov), "r" (nv)
+ : "r0");
+ return (res == 0);
+}
#elif defined(SOLARIS) && defined(sparc) && defined(ULTRA_SPARC)
static JS_INLINE int __attribute__((unused))
Jeff Johnson
On Sep 20, 2011, at 6:30 PM, Jeff Johnson wrote:
>
> WORKSFORME (but I would not trust these wild hacks yet: lemme figger what is *really* needed)
>
These builtins are likely widely available in > gcc-4.1.2 and likely
should be used in JS as well as GPSEE to hide the gory details
of the asm voo-doo:
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html
And yes you still need the asm voodoo to handle non-GCC unless
there are other librray API's that can be used (as on Apple and AIX
and likely most every other compiler in use today).
But old code (and gnarly asm voo-doo) dies a lingering death … we
all phear change and if it ain't broke, don't fix it.
73 de Jeff
Donny Viszneki
Sorry if I am jumping into the middle of your train of thought without
reading previous emails, just realized the activity here!
If my speculation is right, you may be able to remove lines 221-223
(revision 2d3417f15927 Mon Sep 19 14:38:45 2011 -0400) and replace
them with a platform-specific implementation of the
js_CompareAndSwap() function (also, we have conservatively chosen to
qualify this function with static, and also make it inline, please see
similar implementations beginning on lines 168 and 185.)
If my recollection is right, this error message is supposed to be
informing you that Spidermonkey will not (or at least DID not when
this #error was written) make a js_CompareAndSwap() function which is
required by gpsee_lock.c. I don't believe any core developers have had
access to your platform, so we haven't been able to do this ourselves.
Please feel free to keep us up to date on this! Thanks :)
Wes Garland
>
> WORKSFORME (but I would not trust these wild hacks yet: lemme figger what is *really* needed)
>
Lemme know and I'll push to -0.2. Biggest question: does that ASM force a full write barrier? If yes then we should be in fine shape. jbramley in #jsapi on irc.mozilla.org is an ARM employee who knows this stuff inside out and backwards, I think his timezone is something like +1 GMT.
These builtins are likely widely available in > gcc-4.1.2 and likely
should be used in JS as well as GPSEE to hide the gory details
of the asm voo-doo:
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html
Excellent. I have no problems deprecating GCC < 4.2, given what SpiderMonkey itself requires.
And yes you still need the asm voodoo to handle non-GCC unless
there are other librray API's that can be used (as on Apple and AIX
and likely most every other compiler in use today).
Yeah - I ripped out the Sparc assembly code and replaced with OS headers years ago.
Compiler support for GPSEE, FWIW -- is GCC only right now. We'll support Sun Workshop, Visual C, and CLang in the fullness of time.