For hacking/prototyping/fun purposes I have a few embedded systems laying around. For example, I have a couple of Raspberry Pi systems, one of the original Raspberry Pi model B boards and one of the new Raspberry Pi 2 model B boards.
And on everything, I have the latest Steel Bank Common Lisp building.
On my Raspberry Pi, which is an armv6 device, I see the following failures in SBCL’s unit tests:
Failure: debug.impure.lisp / (TRACE ENCAPSULATE NIL)
Failure: debug.impure.lisp / (TRACE-RECURSIVE ENCAPSULATE NIL)
Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET
Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT
(62 tests skipped for this combination of platform and features)
On my Raspberry Pi 2, which is an armv7 device, I see the following additional failures:
Failure: float.pure.lisp / (SCALE-FLOAT-OVERFLOW BUG-372)
Failure: float.pure.lisp / (ADDITION-OVERFLOW BUG-372)
Failure: float.pure.lisp / (ADDITION-OVERFLOW BUG-372 TAKE-2)
Failure: debug.impure.lisp / (TRACE ENCAPSULATE NIL)
Failure: debug.impure.lisp / (TRACE-RECURSIVE ENCAPSULATE NIL)
Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET
Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT
(62 tests skipped for this combination of platform and features)
This says to me that, contrary to what some have told me, SBCL probably does need to distinguish the various ARM instruction set variants.
Is anyone actually working on SBCL on ARM?
I also have a DragonBoard 410c on the way, and it might be nice to have a fast Lisp on ARM64, though I suspect that’s a bit further out…