Installing Clozure Common Lisp on the Raspberry Pi
lispm.dyndns.org
lispm.dyndns.org
If you are reading this and you work for Broadcom of have some sway there, why not encourage them to make that possible by freeing the GPU from its proprietary bindings.
(CCL mapping the framebuffer into memory, using existing Lisp libraries to draw graphics into it).
I have not looked into OpenGL, but it'd certainly be good to have a faster way to draw on the screen. VECTO and bitmap copying is not suitable for anything that is supposed to move.
This is my experience as well. You can mmap /dev/fb0 and draw on it, and you can use something like directfb or even Cairo if you're not into lisp, but if you want to do even trivial 2D acceleration you are out of luck.
Granted, "for educational reasons" is a valid subject for the Pi. Get that old Abrash book out and let the OpenGL-spoiled kids feel the pain.
David Lichteblau got it and Hemlock (an Emacs in CL) running on a tablet:
https://twitter.com/i/#!/lichteblau/media/slideshow?url=http...
Althought he said that Hemlock on a tablet wasn't particularly useful, when I asked him about it.
This lisp system has a small kernel, and almost entirely written in Lisp, so it is extremely efficient and portable.
SBCL and MIT Scheme has a similar architecture and could be easily ported.
Now, what about rebuilding openjdk-1.7.0?)) And then run, say, mvn install clojure?))
Portability might have been a design goal, but ease of porting wasn't. The amount of platform-specific code is only small in relation to the system as a whole. In the classic paper describing CMUCL, Rob MacLachlan has a great line about "porting taking 2-4 wizard-months". Things have progressed a bit since then, so you don't need a wizard. But the time estimate is probably still valid.
So why is it a non-trivial task? Well, first of all you'll need to add instruction descriptions so that the table-driven assembler and disassembler work for that new arch. There might be regularities in the instruction set that make this easier, but on the other hand any mistakes will make debugging much harder than you'd like.
Then you get to translate 5k-10k lines of assembler templates from whatever existing backend you decided to start from. That's actually just tedious, not hard, unless none of the backends is really close. My understanding is that ARM has lots of warts about e.g. which values are easily representable as immediate values. Some parts of this work will be trickier, like adding the support for the platform's native ABI.
That gets you far enough to theoretically compile the system. It will almost certainly crash on startup, before it has even managed to load enough of the state required for debugging itself. So the workflow will consist of figuring out where something odd is happening, and then collecting and cross-correlating various bits of information (single stepping in gdb, gdb disassemblies, annotated assembler code from the compiler) around the problematic bit of code.
There will be dozens of bugs like that between this stage and a working Lisp prompt. The first time floating point code gets used, or the first time the compiler is called during the startup, the first explicit call to C code, the first call the garbage collector (or rather what happens sometime right after the first call, when e.g. the GC has mangled some relocations), etc. Doing the bring-up for a merely compiling SBCL port was probably the hardest programming I've ever done.
I'd bet that none of the CCL ports were just "easy" either.
A small hack could be using a very modern sophisticated clang compiler, to produce an optimized assembly for an idiom you need, coded in C. Like clang -S a.c then you change and hard-code what you like.
Yes, it is a non-trivial task, so, it might make you much better engineer, like a difficult journey into unknown improves you.
I have heard that Scheme48 has a good story when it comes to portability and Lisp-implementation-written-in-Lisp, but I haven't looked at it.
Any system based on a C VM is going to be lots easier to port than something that compiles into native instructions. Also look at the Gambit-C implementation of Scheme, which compiles to C. The C itself is arranged like a VM, it's very fast (biggest issue with this approach is incremental compiling, where you need trampolines; the more code you block compile the more you can avoid this overhead).
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
6573 pi 20 0 546m 36m 7580 S 1.6 19.8 1:55.26 armcl