CogVM binaries as per VMMaker.oscog-eem.1370/r3386 Add the ARMv5/ARMv6 Cog Spur JIT VM! Add explicit read barriers to primitives which access an argument as the receiver (i.e. the mirror primitives). Don't check if the actual receiver is used. Simplify failure where appropriate cuz the primitives will be retried. Add -fwrapv to all linux gcc builds (to insist on 2's complement arithmetic) and add makeallclean, making makeall do the dirty build. Provide a -exitonwarn command line switch for the Mac and Unix VMs to allow for CI testing of asserts. Unix: restore the SCCS revision after the version number in -version output. Spur: Remember to count shrink requests Cogit: Fix bug in rewriting compiler primitives on module unload, etc. The old code didn't change the assignment to the primitiveFunctionPointer, which is needed for correct management of failing primitive calls on Spur. Simplify the post compile hook to eliminate the label parameter; this is local to the Cogit. ARM Cogit: Use out-of-line literals for compactness. -- best,
Eliot |
Hi All,
On Sat, Jun 20, 2015 at 6:26 PM, Eliot Miranda <[hidden email]> wrote:
It's very satisfying to release a JIT for a new (for Cog) ISA. Thanks to Lars Wassermann and Tim Rowledge for lots of hard work on the JIT, which I participated in too. And thanks to Doug McPherson for lots of work in other parts of the ARM build. This is great. The main caveat is that this has only been tested on Raspberry Pi running Raspbian. We're interested to hear of experience with other ARM linux systems. All is not perfect. I've been able to update a Spur image completely and run almost all tests. But currently there's a segfault coming from SSL. Anyone who's got expertise with SSL and ARM is encouraged to take a look. Here's the current stack trace for the segfault: Program received signal SIGILL, Illegal instruction. 0xb5fd4600 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 (gdb) where #0 0xb5fd4600 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 #1 0xb5fd0fe4 in OPENSSL_cpuid_setup () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 #2 0xb6fe8254 in ?? () from /lib/ld-linux-armhf.so.3 #3 0x0029db18 in ?? () #4 0x0029db18 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) call printStackCallStackOf (framePointer) 0xbefab924 I SqueakSSL>initialize 0x619df8: a(n) SqueakSSL 0xbefab93c M SqueakSSL class(Behavior)>new 0x1a3f6c0: a(n) SqueakSSL class 0xbefab954 M SqueakSSLTest>setUp 0x18a9f08: a(n) SqueakSSLTest 0xbefab96c M [] in SqueakSSLTest(TestCase)>runCase 0x18a9f08: a(n) SqueakSSLTest 0xbefab988 M BlockClosure>on:do: 0x44d640: a(n) BlockClosure 0xbefab9b0 M [] in SqueakSSLTest(TestCase)>timeout:after: 0x18a9f08: a(n) SqueakSSLTest 0xbefab9d0 M BlockClosure>ensure: 0x44d6e0: a(n) BlockClosure 0xbefab9f8 M SqueakSSLTest(TestCase)>timeout:after: 0x18a9f08: a(n) SqueakSSLTest 0xbefaba18 M [] in SqueakSSLTest(TestCase)>runCase 0x18a9f08: a(n) SqueakSSLTest 0xbefaba38 M BlockClosure>ensure: 0x44d810: a(n) BlockClosure 0xbefaba54 M SqueakSSLTest(TestCase)>runCase 0x18a9f08: a(n) SqueakSSLTest
best,
Eliot |
On Sat, Jun 20, 2015 at 6:33 PM, Eliot Miranda <[hidden email]> wrote:
Ah, I was confused by running this under gdb. Had I run it natively the SIGILL would have been caught and ignored. So ignore this. One lives and learns.
best,
Eliot |
In reply to this post by Eliot Miranda-2
On 20-06-2015, at 6:33 PM, Eliot Miranda <[hidden email]> wrote: > It's very satisfying to release a JIT for a new (for Cog) ISA. Thanks to Lars Wassermann and Tim Rowledge for lots of hard work on the JIT, which I participated in too. That’s putting it a bit mildly. Eliot has done a major chunk of this, quite aside from having built cog in the first place. > And thanks to Doug McPherson for lots of work in other parts of the ARM build. Seconded. > This is great. > > The main caveat is that this has only been tested on Raspberry Pi running Raspbian. We're interested to hear of experience with other ARM linux systems. Seconded. Oh, and remember - this is for ARM v5/6/7 systems. Running full chat 64bit on v8 is not going to happen just yet. You know the drill by now - send me $1,000,000 and we can start talking. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim "Bollocks," said Pooh being more forthright than usual |
In reply to this post by Eliot Miranda-2
> On 21 Jun 2015, at 03:33, Eliot Miranda <[hidden email]> wrote: > > Hi All, > > > All is not perfect. I've been able to update a Spur image completely and run almost all tests. But currently there's a segfault coming from SSL. Anyone who's got expertise with SSL and ARM is encouraged to take a look. Here's the current stack trace for the segfault: > > Program received signal SIGILL, Illegal instruction. > 0xb5fd4600 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 > (gdb) where > #0 0xb5fd4600 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 > #1 0xb5fd0fe4 in OPENSSL_cpuid_setup () > from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 That is trying to detect available CPU instructions at runtime[1]. The idea is that the code sets a signal handler for SIGILL, then executes ARMvX instruction and if the signal handler is not called it can use these routines. So the SIGILL is expected behavior, is this the last error or the first one? holger [1] https://git.openssl.org/?p=openssl.git;a=blob;f=crypto/armcap.c;h=1afbc9fcd036771dd694d0dbfa42df4d839d382b;hb=bc9567cdc9a56b5c904e075e3b929076c1e7583c#l89 |
In reply to this post by Eliot Miranda-2
On 21-06-15 03:26, Eliot Miranda wrote: > ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3386 > > CogVM binaries as per VMMaker.oscog-eem.1370/r3386 > > Add the ARMv5/ARMv6 Cog Spur JIT VM! Oh, that's great news! Thanks to all who made this possible. Stephan |
+ 1 I asked jb to see if he can run it on our builds. Stef >> ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3386 >> >> CogVM binaries as per VMMaker.oscog-eem.1370/r3386 >> >> Add the ARMv5/ARMv6 Cog Spur JIT VM! > > Oh, that's great news! Thanks to all who made this possible. > > Stephan > > |
In reply to this post by Holger Freyther
Hi Holger, On Jun 21, 2015, at 1:48 AM, Holger Freyther <[hidden email]> wrote: > > >> On 21 Jun 2015, at 03:33, Eliot Miranda <[hidden email]> wrote: >> >> Hi All, >> >> >> All is not perfect. I've been able to update a Spur image completely and run almost all tests. But currently there's a segfault coming from SSL. Anyone who's got expertise with SSL and ARM is encouraged to take a look. Here's the current stack trace for the segfault: >> >> Program received signal SIGILL, Illegal instruction. >> 0xb5fd4600 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 >> (gdb) where >> #0 0xb5fd4600 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 >> #1 0xb5fd0fe4 in OPENSSL_cpuid_setup () >> from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 > > > That is trying to detect available CPU instructions at runtime[1]. The idea is that > the code sets a signal handler for SIGILL, then executes ARMvX instruction > and if the signal handler is not called it can use these routines. Yes, I get it now. > > So the SIGILL is expected behavior, is this the last error or the first one? It isn't visible unless one runs under gdb. I was checking that the assert VM ran the test suite without assert failures by running under gdb (so I could diagnose failures if they occurred) and so when the SSL library started up gdb caught the SIGILL and stopped execution. This confused me and I assumed it was an error. Forgive the noise. > > holger > > > [1] https://git.openssl.org/?p=openssl.git;a=blob;f=crypto/armcap.c;h=1afbc9fcd036771dd694d0dbfa42df4d839d382b;hb=bc9567cdc9a56b5c904e075e3b929076c1e7583c#l89 |
In reply to this post by Eliot Miranda-2
Awesome! - Bert - smime.p7s (5K) Download Attachment |
On 22-06-2015, at 3:03 AM, Bert Freudenberg <[hidden email]> wrote: > > Awesome! It is. For example, ‘method source with it’ is now practical on a Pi (a 2, anyway) instead of ‘get a coffee, go pee, read newspaper’.[1] Mind you, there are still plenty of places in the image where approximately a gazzillion times more work is done than could plausibly be needed. Just try stepping the simulator through image startup to get some idea of how poorly thought out some bits of code are. And a second or more to open a Browser - on a machine running at around 100 Dorado? tim [1] for the younger readers I should point out that ‘newspaper’ is an old technology where a bundle of poor quality paper is printed up with the equivalent of news.google.com, twitter, fabecook and local malicious gossip, along with garish poorly designed adverts. Though at least they are auto-play. Or infected with viruses. Normally, anyway. And -get this - they don’t have built in links! -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim A)bort, R)etry, I)gnore, V)alium? |
In reply to this post by Eliot Miranda-2
Hi Carl,
|
In reply to this post by timrowledge
Pi FP is now working pretty well (enough to pass all the SUnits and run big benchmarks). And it roughly triples the speed of the nbody benchmark :-) tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: JTC: Jump To Conclusions |
Free forum by Nabble | Edit this page |