ECL on very small chips?

Tue Mar 29 12:13:12 UTC 2016

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 at atp-media.de>
wrote:

>
>
> > -----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>
> > 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 at eZono.com
Spitzweidenweg 32
Home: +49 (0)3641 795 5844
Work:  +49 (0)3641 876 1735
D – 07743 Jena
Germany
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20160329/3f5cd812/attachment.html>