"Andreas Thiele" andreas@atp-media.de writes:
can I use ECL to write software for a chip without OS?
Yes.
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 debugger).
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. https://en.wikipedia.org/wiki/Crash_Bandicoot https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp http://all-things-andy-gavin.com/2011/02/02/making-crash-bandicoot-part-1/ http://all-things-andy-gavin.com/2011/10/25/lispings-ala-john-mccarthy/
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.