AW: ECL on very small chips?
andreas at atp-media.de
Sun Mar 27 12:23:05 UTC 2016
> -----Ursprüngliche Nachricht-----
> Von: ecl-devel [mailto:ecl-devel-bounces at common-lisp.net] Im Auftrag
> von Pascal J. Bourguignon
> Gesendet: Sonntag, 27. März 2016 00:32
> An: ecl-devel at common-lisp.net
> Betreff: Re: ECL on very small chips?
> "Andreas Thiele" <andreas at atp-media.de>
> > 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
> 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
> a logic analyser). By writing the emulator in lisp, that means that
> can easily instrumentalize it to help you in debugging.
> Once you have a LAP, you can implement a compiler for a subset of
> 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
> 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
> instead of the CL package, on any CL implementation, using all the
> of your Common Lisp implementation and IDE (choose the one with the
> 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
> 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
> 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
> 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__ http://www.informatimago.com/
> “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
Thank you for the inspiring and enlightening answer.
Although your emulator suggestion first made me grin, I think it is a possible way to go. Problem is, the chip is connected to other hardware, which has slow communication protocols. Now I think about connecting these hardware components to my emulator (to be written). This could indeed be an approach. I have to think :)
P.S. After browsing the ARM Thumb instruction set I guess writing the emulator will not be trivial :)
More information about the ecl-devel