Hello, 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. Andreas
On Fri, Mar 25, 2016 at 11:24 AM, Andreas Thiele <andreas@atp-media.de> wrote:
Hello,
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. ECL takes up much more RAM than that. And any full common lisp implementation would have trouble with that.
-- With best regards, Stas.
-----Ursprüngliche Nachricht----- Von: Stas Boukarev [mailto:stassats@gmail.com] Gesendet: Freitag, 25. März 2016 10:10 An: Andreas Thiele Cc: ecl-devel@common-lisp.net Betreff: Re: ECL on very small chips? On Fri, Mar 25, 2016 at 11:24 AM, Andreas Thiele <andreas@atp-media.de> wrote:
Hello,
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. ECL takes up much more RAM than that. And any full common lisp implementation would have trouble with that.
-- With best regards, Stas. Thanks, so ECL can't be my way. I will take a look at miniPicolisp. If you have other ideas for a dynamic language on such a small system I am thankful. Sorry for my naïve question :) Best regards Andreas
Armpit scheme targets risc processors. Regards, Daniel Dnia 25 marca 2016 11:28:43 CET, Andreas Thiele <andreas@atp-media.de> napisał(a):
-----Ursprüngliche Nachricht----- Von: Stas Boukarev [mailto:stassats@gmail.com] Gesendet: Freitag, 25. März 2016 10:10 An: Andreas Thiele Cc: ecl-devel@common-lisp.net Betreff: Re: ECL on very small chips?
On Fri, Mar 25, 2016 at 11:24 AM, Andreas Thiele <andreas@atp-media.de> wrote:
Hello,
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. ECL takes up much more RAM than that. And any full common lisp implementation would have trouble with that.
-- With best regards, Stas.
Thanks, so ECL can't be my way. I will take a look at miniPicolisp. If you have other ideas for a dynamic language on such a small system I am thankful. Sorry for my naïve question :)
Best regards Andreas
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
"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. -- __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
-----Ursprüngliche Nachricht----- Von: ecl-devel [mailto:ecl-devel-bounces@common-lisp.net] Im Auftrag von Pascal J. Bourguignon Gesendet: Sonntag, 27. März 2016 00:32 An: ecl-devel@common-lisp.net Betreff: Re: ECL on very small chips?
"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.
-- __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. Yes my question was a bit unspecific. The trigger for my question was an unbelievable turnaround time of about 2 minutes (edit, compile, reload, test again) I came across when an embedded box currently under development came onto my desk. This one is written by a junior c programmer with lengthy, sparsely commented c code containing cryptic function names. My job here is programming common lisp, nearly exclusively. So I thought about having a more dynamic development system on the box, which allows dynamic compilation of functions during runtime to not have to reboot the whole box just because one function gets modified. Meanwhile I thought about ECL, PicoLisp, miniPicoLisp, Lua and even Javascript, but I abandoned them all. 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 :) Andreas P.S. After browsing the ARM Thumb instruction set I guess writing the emulator will not be trivial :)
In my case I’d like to write software for NXP1769 which is ARM Cortex M3, 64kB Ram, 512kB Flash. To be honest, to me that sounds like a job for FORTH.
That can be nearly as dynamic as CL (or so I've heard - my own experience is too limited ;), but if you manage to put all (needed! not the whole set) CL primitives into a forth then you'll only need a small translator from CL... At least it should be possible to put new routines into RAM (via some kind of programming line - JTAG, serial, USB, you name it), and test them from there nearly as fast as via swank (slime)... Please keep your discussion (and results) on this list, it sounds interesting!
you may also take a look at ecl_min (minimal lisp written in C supporting bytecode compiler which bootstraps ecl). I'm not sure how much memory does it take. According to the manual VM for the bytecode is similar to what forth does. Regards, Daniel Philipp Marek writes:
In my case I’d like to write software for NXP1769 which is ARM Cortex M3, 64kB Ram, 512kB Flash. To be honest, to me that sounds like a job for FORTH.
That can be nearly as dynamic as CL (or so I've heard - my own experience is too limited ;), but if you manage to put all (needed! not the whole set) CL primitives into a forth then you'll only need a small translator from CL...
At least it should be possible to put new routines into RAM (via some kind of programming line - JTAG, serial, USB, you name it), and test them from there nearly as fast as via swank (slime)...
Please keep your discussion (and results) on this list, it sounds interesting!
-- Daniel Kochmański ;; aka jackdaniel | Poznań, Poland TurtleWare - Daniel Kochmański | www.turtleware.eu "Be the change that you wish to see in the world." - Mahatma Gandhi
From: ecl-devel [mailto:ecl-devel-bounces@common-lisp.net] On Behalf Of Philipp Marek
In my case I'd like to write software for NXP1769 which is ARM Cortex M3, 64kB Ram, 512kB Flash. To be honest, to me that sounds like a job for FORTH.
I second that, In 1989+ we had 7270 "smart" terminals connected to IBM360-line mainframes, (in our University) those "smart" terminal were having 64K of RAM and were allowing FORTH there, and this combination was efficient enough to have plenty of ASCII-based games, and for us to having programmer's fun. This is why I also thought about FORTH, But - still - LISP have similar background of history, so if there is no task of having entire COMMON LISP standard there - then just reasonable subset is really possible. My intuition says to me that FORTH is easier to strip down. However - ECL has closer connection to C, which will make your life easier. Regards, Vadim.
"Konovalov, Vadim" <Vadim.Konovalov@emc.com> writes:
However - ECL has closer connection to C, which will make your life easier.
I don't agree. ECL architecture with respect to C is very complex. Also ECL includes: - an interpreter (IIRC), - a byte-code compiler with a byte-code virtual machine, and - an optional compiler that translates lisp to C, and then forks an external process running gcc to compile the C to native code in a dynamically linked library, which is then dynamically loaded into the lisp image. This later part, which is what is refered to when people say it has a "closer connection to C" is the most complex, and the most strongly dependent on a unix system (perhaps just a POSIX system, but I wouldn't try to strain it too much). In any case the problem would be to run a program (ecl) without an OS. This programs relies on OS services (file systems, process management (signals, fork/exec), network stacks, device drivers (terminal) and external programs (gcc, ld.so)) either thru the POSIX layer or with direct syscalls (libc and other libraries). If you want to run it on the bare hardware, then you will have to provide those libraries implemented on the bare hardware, instead of on a unix kernel. -- __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
"Andreas Thiele" <andreas@atp-media.de> writes:
Thank you for the inspiring and enlightening answer.
Yes my question was a bit unspecific. The trigger for my question was an unbelievable turnaround time of about 2 minutes (edit, compile, reload, test again) I came across when an embedded box currently under development came onto my desk. This one is written by a junior c programmer with lengthy, sparsely commented c code containing cryptic function names. My job here is programming common lisp, nearly exclusively. So I thought about having a more dynamic development system on the box, which allows dynamic compilation of functions during runtime to not have to reboot the whole box just because one function gets modified. Meanwhile I thought about ECL, PicoLisp, miniPicoLisp, Lua and even Javascript, but I abandoned them all.
There are also C interpreters. Cint, EiC, etc. Perhaps one of them could be made to run on a bare hardware (with some set of library). But probably it would be as hard to do as to make some CL work there. (Also, assuming you need to make those tools run from the EEROM, and not from the RAM).
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 :)
While I rejected it on principle, you may envisage to use Qemu or some other emulator already existing for ARM processors. You may have to find one or patch one to match your exact processor instruction set. -- __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
Hi Andreas, I was annoyed by the ~20s programming time of the Arduino Due. I tried to port femtolisp to the Arduino Due: https://github.com/plops/arduino_due_lisp/tree/master/arduino-femtolisp I added a few functions to access the DAC and the GPIO pins. Using this I was able to do some exploratory programming. I didn't try to implement a garbage collector but small examples like this work: (let ((i 0)) (while (< i 10) (digitial-write 8 1) (delay 10) (digital-write 8 0) (delay 1) (set i (+ i 1)))) Development with this is much more fun. I found that even though the code is is interpreted, there is very low jitter. The next steps would be to get a garbage collector and then a way to load compiled functions from the host computer into RAM. Unfortunately I don't know how to do that. Regards, Martin On Sun, Mar 27, 2016 at 2:23 PM, Andreas Thiele <andreas@atp-media.de> wrote:
-----Ursprüngliche Nachricht----- Von: ecl-devel [mailto:ecl-devel-bounces@common-lisp.net] Im Auftrag von Pascal J. Bourguignon Gesendet: Sonntag, 27. März 2016 00:32 An: ecl-devel@common-lisp.net Betreff: Re: ECL on very small chips?
"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.
-- __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.
Yes my question was a bit unspecific. The trigger for my question was an unbelievable turnaround time of about 2 minutes (edit, compile, reload, test again) I came across when an embedded box currently under development came onto my desk. This one is written by a junior c programmer with lengthy, sparsely commented c code containing cryptic function names. My job here is programming common lisp, nearly exclusively. So I thought about having a more dynamic development system on the box, which allows dynamic compilation of functions during runtime to not have to reboot the whole box just because one function gets modified. Meanwhile I thought about ECL, PicoLisp, miniPicoLisp, Lua and even Javascript, but I abandoned them all.
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 :)
Andreas
P.S. After browsing the ARM Thumb instruction set I guess writing the emulator will not be trivial :)
-- Dr. Martin Kielhorn martin.kielhorn@eZono.com Spitzweidenweg 32 Home: +49 (0)3641 795 5844 Work: +49 (0)3641 876 1735 D – 07743 Jena Germany
participants (7)
-
Andreas Thiele -
Daniel Kochmański -
Konovalov, Vadim -
Martin Kielhorn -
Pascal J. Bourguignon -
Philipp Marek -
Stas Boukarev