I continued my reading about Lisp and also searched the Web a bit more for anything related to Embedded Systems. I think that this is a pretty sad story.
I heard from a friend that I missed ecls in my last post. He said that it is possible to compile Lisp to C with it and then you can crosscompile the resulting C source to any architecture you like. But that simply does not feel right. That is only a hack. You miss the things you want the most (beside Lisp itself) REPL and with it the integrated inspector and debugger just like the profiler and tracer. Also you miss binary upload of functions. Think for yourself. If you do not have that things does development with lisp feel like it should? If you ask me it does not.
So I searched further. I knew that there was someone who developed the triple L, Mars and Venus. I did not know what it exactly was but I knew that it was a lisp development environment for embedded systems.
Looking more in depth in to that, I had to realize that the only thing that exists is the paper L – A Common Lisp for Embedded Systems (pdf format is here) by Rodney A. Brooks and Charles Rosenberg. This paper is telling a beautiful story about a development system that would be the thing one would like to have. But you can not get it anywhere! On the page of Charles Rosenberg you find the pointer that the company IS Robots (that was developing L, Mars and Venus) is now iRobot (yes the Roomba guys). Searching their site does not say anything about lisp though.
The only other person bringing iRobot together with Lisp is Lemindor I have not read all his posts yet but he does not really say anything that helps me neither.
I also asked about the topic in #lisp on freenode but it seems that the overall opinion is that everyone is brewing his own Lisp if he/her wants to use lisp on embedded system.
That is really bad news. I was hoping that there will be something I will be able to base on. The only solution that I see now is to take some common lisp implementation and port it to some embedded system. And when it works start changing it and splitting in parts so that it fits development on embedded systems. (you do not really want the compiler on your embedded system normally an interpreter is enough)
That somehow sounds pretty big and heavy. 🙁
The second solution would be to start with a small Lisp implementation by oneself. When you read Paul Graham’s article Roots of Lisp you get the feeling that it can not be that hard. But still I think that is probably a false feeling. But if I had the power and money to hire some people that are bright enough I think I would attack that. I even know some people that are bright and that would be able to create such thing but none of them would want to invest their time in such a project when they do not get money for that. So there is high possibility that Lisp on embedded systems will remain a dream. 🙁
doing all the delicious lisp developing directly on the hardware while being able to use a native REPL and object inspector should be really hard because of limited memory and processing power. such lisp environments must be custimized towards the used architecture(REPL over USB/seriell/…). everybody is using something different here, like arm for example. and even there
are several different arm-processor manufactors and boards used today.
the easiest method I found by now is using ecl(http://ecls.sf.net) and compiling the generated c source with your cross compiler (http://ecls.sourceforge.net/ecl/The-compiler.html#The-compiler).
I am currently doing some hacking towards using lisp on the ecos operating system (http://ecos.sourceware.org/). Of course I would miss all the neat stuff, like repl and inspectors. But using the linux syntethic target it’s possible to have a fast compiling & developing process. having some glue code in lisp it should even be possible to develop inside lisp with sbcl and co and then finally do the compiling with ecls.
the glue code is necessary, because in the lisp ansi standard, things like sockets and streams are not well standardized.
you can use #+sbcl or #+cmucl to only compile s-formes while you are using a specific compiler. this helpes developing for multiple lisp compilers. but as in c-source:
too much preprocessor-defines make the code unreadable 😉
Have you looked at Hedgehog[1]?
[1] http://www.oliotalo.fi/hedgehog/hoglisp.html
Thanks for the pointer! That brings me much further. Hedgehog is pretty much what I was looking for. The only negative side is that it is an interpreter.
I think scheme would be better for a system with limited resources.
SCM (http://www-swiss.ai.mit.edu/~jaffer/SCM.html) already runs on my old pocket pc. Theres also Pocket Scheme that can call the W32API functions. I bet you could just run a scheme or lisp implementation through a gcc toolchain for the target architecture.
I wished for having Lisp on our embedded systems (ColdFire and eCos based) and did some experiments with Chicken (http://www.call-with-current-continuation.org/). I even got it to run on the target system at some point, but I had a lot of problems integrating the Scheme interpreter with the rest of the system, in particular with the C++ classes, and finally gave up on the idea. It was just too much work and I could not build a friendship with Scheme. Now we have Javascript as interpreter language on our embedded systems. Not quite Lisp, but way better than C++ 🙂
I guess what I was actually looking for was Common Lisp, which does not seem to be really be available for m68k based systems nowadays.
So, what will be better to use – C or Lisp?
There are the BIT and PICBIT Scheme systems for small microcontrollers. See:
http://w3.ift.ulaval.ca/~dadub100/
word. I’m just finding out about it now myself, sure wish L were alive, and kicking, and available, and stuff.