ECL on very small chips?

Pascal J. Bourguignon pjb at
Sat Mar 26 23:32:23 UTC 2016

"Andreas Thiele" <andreas at>

> can I use ECL to write software for a chip without OS?


> In my case I’d like to write software for NXP1769 which is ARM Cortex
> M3, 64kB Ram, 512kB Flash.

Anything with more than one bit of memory.

You didn't ask if you could develop software using ECL running on this
chip.  You can use ECL (or any other CL implementation), at all phases
of the creation of software for a chip without an OS.

I would start by writing LAP (Lisp Assembler Program) for that chip.
Then I would write in lisp an emulator of that chip.  The reason why you
don't want to use the chip itself is that it doesn't have an OS,
therefore it must be rather hard to debug code you sent there, (even with
a logic analyser).  By writing the emulator in lisp, that means that you
can easily instrumentalize it to help you in debugging.

Once you have a LAP, you can implement a compiler for a subset of Common
Lisp targetting this LAP.

Let's remember, you didn't ask to run an interactive lisp with an
development environment ON this chip.  Therefore you may not need a
garbage collector, a compiler or an interpreter, strings, cons cells,
pathnames, multidimensional arrays, CLOS objects, bignums, ratios, etc.
Probably, for the application you have in mind, you only need
(signed-byte 32) and vectors, perhaps structures.  You may not need to
implement dynamic unwinding, the condition system with restarts and so
on.  After all, all your other colleagues only run C code on those
chips.  So a small subset of Common Lisp can be all you really need.

But notice that in the code of your macros, you can use the full Common
Lisp language, since macros are evaluated at compilation time.  It's in
the lisp code generated by your macros that you must restrict yourself
to your CL subset.  (Cf. eg. parenscript).

You would  define this CL subset also as a package that exports only the
operators included in that subset.  Say the ANDREAS-THIELE-LISP
package, nickname ATL.

So you can now develop your software for this chip, as a normal CL
program using this subset of Common Lisp, that is, using the ATL package
instead of the CL package, on any CL implementation, using all the tools
of your Common Lisp implementation and IDE (choose the one with the best

Once it's good and debugged as a normal CL program, you compile it with
your compiler instead of using the CL compiler, and you obtain the bytes
to be sent to the chip.  You don't send them to the chip!

You send them to your emulator, and you test and debug on your emulator
in Common Lisp, using all the tools of your Common Lisp implementation
and IDE.

When it's good and debugged as binary program for you chip, then you can
send it to the chip, and test the final product with whatever tools you
have there.

Ok, it may sound complex explained like this, but it's one of the most
fun way to build a program.

This is how they wrote Crash Banditcoot, for example.

Finally, remember that the original LISP was written on a machine with
36-bit words and 32 Kwords; that's 144 KB. (each 36-bit word could store
a cons cell with two 15-bit pointers and two 3-bit type tags).

There were lisp implementations on 8-bit processors (eg. on the Apple ][
6502 with 64 KB of addressing space).

In the case of CL, the name of the symbols alone take already 12 KB:

(let ((z 0)) (do-symbols (s "CL" z) (incf z (length (symbol-name s)))))
--> 11271

(but that's uncompressed, you can be smart).

So if your purpose was to implement a Common Lisp system on your chip,
with 512 KB of flash memory, I'd say that it would be perfectly
possible, but easier by starting from scratch to take into account the
size limitations.

__Pascal Bourguignon__       
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

More information about the ecl-devel mailing list