[Openmcl-devel] ARM testing

[Gary Byers]

My best guess is that this is fixed in the trunk; if it's what I think
it is, I ran into it a few weeks ago.

It looks like a closure - probably the first function that's executed
on startup - is checking to ensure that it received exactly one arg.
(Values inherited from the enclosing environment are passsed to closures
as arguments.)  The (pseudo) code for that looks like:

(cmp nargs ($ 4)) ; 4 = the fixnum one
(trap-if-not-equal wrong-number-of-args-trap)

Most ARM instructions can be conditionally executed; if the condition
is false, the instruction is ordinarily treated as a NOP.

The fine print in the ARMv7 manual says that if a conditional
instruction would signal certain kinds of exceptions if executed, a
hardware implementation is allowed to raise that exception even if
the condition is false.  I apparently didn't parse that correctly
(I do remember reading it), and implemented lots of things on the
assumption that illegal instructions would be conditionally executed,
just like legal conditional instructions.

Trying to get CCL running on my cell phone (which, IIRC, uses a 
Qualcomm Snapdragon) made it clear that that was wishful thinking;
the TRAP-IF-NOT-EQUAL above behaves like TRAP-ALWAYS, and we have to
branch around an unconditional trap:

(cmp nargs ($ 4))
(beq @ok)
(trap-always wrong-number-of-args-trap)
@ok

which is slightly worse on hardware that implements conditional traps
and infinitely better on hardware that doesn't.

Bootstrapping that change is a bit complicated (it affects how consing
works, among other things.)  While trying to get things working in the
trunk, I added a workaround in the CCL kernel: if we get an illegal
instruction exception and the instruction is a conditional trap whose
condition was false, just skip over the instruction.  That enables code
to run, but there's noticeable overhead (we spend a lot oftime handling
and ignoring conditional traps that are being executed unconditionally.)
If that change was backported to 1.6, you'd at least be able to run.

> The CPU is an ARM v7 (QSD8x50, same as what's in the Nexus One).

I missed that on first reading.  It just so happens that my phone is
a Nexus One, so my confidence in this explanation just went from ~90%
to ~100%.


On Wed, 19 Jan 2011, David Brown wrote:

> Since my day job involves working on the Linux kernel on ARM targets, I
> thought I'd give the new ARM CCL port a try.  It doesn't get very far,
> and was wondering if anyone had any suggestions on what would be a good
> way to investigate this.
>
> The userspace is running Ubuntu 10.04, and I've built the kernel myself
> (currently off of 2.6.37-rc6, soon 2.6.38-rc1).
>
> The CPU is an ARM v7 (QSD8x50, same as what's in the Nexus One).
>
> On running ./armcl, I get
>
> Unhandled exception 4 at 0x508f4248, context->regs at #xbead82e0
> wrong number of args (1) to #<Function (:INTERNAL SAVE-IMAGE)
> #x544363ae>
> ? for help
> [2430] Clozure CL kernel debugger: r
> r00 = 0x00000013    r08 = 0xBEBCA628
> r01 = 0x0000000A    r09 = 0x544363AE
> r02 = 0x00000004    r10 = 0x403E0FFC
> r03 = 0x000383D0    r11 = 0x00000000
> r04 = 0x5455871E    r12 = 0xFFFFFFF8
> r05 = 0x00000000    r13 = 0xBEBCA5B0
> r06 = 0x00000000    r14 = 0x0001D7CC
> r07 = 0x00000000    r15 = 0x508F4248
> [2430] Clozure CL kernel debugger: v
> Lisp kernel svn revision: 14487
> Symbol *OPENMCL-VERSION* at #x541F09DE
>  value    : "1.6-r14468M  (~A)"
> [2430] Clozure CL kernel debugger: b
> current thread: tcr = 0x383d0, native thread ID = 0x97e, interrupts
> disabled
>
>
> (#xBEBCA5D0) #x0001D7BC : (subprimitive toplevel_loop)
> (#xBEBCA5E0) #x0001D84C : (subprimitive (null))
> [2430] Clozure CL kernel debugger: t
> Current Thread Context Record (tcr) = 0x383d0
> Control (C) stack area:  low = 0xbea67000, high = 0xbebca628
> Value (lisp) stack area: low = 0x403e1000, high = 0x40295000
> Exception stack pointer = 0xbebca5b0
> [2429] Clozure CL kernel debugger: k
> Killed
>
> Thanks for any ideas,
> David
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>