Page 1 of 1

LISP for the parallella-16

PostPosted: Wed Dec 30, 2015 12:17 am
by drewvid
I've just posted a version of LISP I wrote for the parallella on github. This version contains no garbage collection and limited error detection and is intended to be a starting point for those who are interested in experimenting in this area.

The 10 primitives suggested by John McCarthy's paper are implemented:

    atom
    eq
    car
    cdr
    cons
    quote
    cond
    lambda
    label
    eval

The following primitives have been added in addition to those above.

    nilp
    append
    concat
    loop
    block
    progn
    if
    define
    ldefine
    print
    terpri
    <
    >
    +
    -
    /
    *
    =

The code isn’t documented because I intend to do that with a series of blog posts over the next few months or so.

Re: LISP for the parallella-16

PostPosted: Wed Dec 30, 2015 4:08 am
by aolofsson
Brilliant! Send me a note if you want to publish those blog posts at parallella.org. Either way I look forward to reading them!

Andreas

Re: LISP for the parallella-16

PostPosted: Tue Mar 29, 2016 8:52 am
by drewvid
Here is the first blog post about Parallella-LISP:

https://github.com/drewvid/parallella-lisp/wiki/Parallella-LISP---the-runtime-environment

This post concentrates on the runtime environment. Later posts will describe how to build applications using both LISP and the LIST processing library.

Re: LISP for the parallella-16

PostPosted: Mon Apr 04, 2016 10:54 pm
by theover
Hi Drewvid,

I've downloaded and tried running you Lisp interpreter for the Epiphany, and it works great! I'm glad you took some of my forum thread on Lisp and put all this work in.

I didn't check how big a piece of code can load into the interpreter in an Epiphany node, but the examples are serious enough Lisp, and run fast enough. I hoped for a interactive evaluator, but that may be hard to do with the current Epiphay example code, but it would be fun to route calls/codes from on node to another and be able to play interactively with the Lisp.

I don't know how (incredibly) far it is to take a big piece of LISP code like Maxima runs at and take some evaluation parts from the main Zynq memory, send them to this interpreter and get the results back, but it's interesting to think about little applications. I was glad that for instance (faculty 20) runs good and the return value is correct, I don't know how much stack space that takes, but it was alright.

If I understand it right, the 23 kB of C code with the REPL function gets compiled for the Epiphany core, right ? Good that that fits, does it stay in the cores and have the ability to get called again with new strings fed to the REPL function without the need to reload and restart the Epiphan cores ?

T.

Re: LISP for the parallella-16

PostPosted: Tue Jun 21, 2016 1:21 pm
by drewvid
Hi theover. Sorry I missed your blog post and didn't reply earlier.

I'm glad you took some of my forum thread on Lisp and put all this work in.


Yes, your post did get me started on writing a LISP interpreter. Before that I was just doing LIST processing! Recently I've been busy with other things but have just finished writing an image processing example which will be posted soon.

I didn't check how big a piece of code can load into the interpreter in an Epiphany node, but the examples are serious enough Lisp, and run fast enough. I hoped for a interactive evaluator, but that may be hard to do with the current Epiphay example code, but it would be fun to route calls/codes from on node to another and be able to play interactively with the Lisp.


With luck I'll get around to implementing message passing between cores this summer. I've also been thinking about ways of implementing an "interactive evaluator" and may be able to move a little in that direction too.

I don't know how (incredibly) far it is to take a big piece of LISP code like Maxima runs at and take some evaluation parts from the main Zynq memory, send them to this interpreter and get the results back, but it's interesting to think about little applications. I was glad that for instance (faculty 20) runs good and the return value is correct, I don't know how much stack space that takes, but it was alright.


Porting apps like Maxima is not really possible but some form a computer algebra should be possible.

If I understand it right, the 23 kB of C code with the REPL function gets compiled for the Epiphany core, right ? Good that that fits, does it stay in the cores and have the ability to get called again with new strings fed to the REPL function without the need to reload and restart the Epiphan cores ?


Yes, that is correct. Once the REPL is loaded on each core it should then be possible to just send code to be evaluated and get back the result. An "interactive evaluator" requires such an approach and will be a good way to test all of the above possibilities together.