Re: CLISP GSoC Project Ideas

Thanks for your encouraging response.

After digging deeper into the CLISP internals (reading the byte-code
specification), I've decided a do-able and interesting backend project
would be to add native file compilation as described here:
https://clisp.sourceforge.io/wanted.html
My understanding is that this would allow the use of external debuggers
like GDB on compiled code and forgo the need for a byte-code interpreter at
execution time. In essence, this would be the ahead of time counterpart to
the JIT compiler. I do not know which option (to C, LLVM, or GCC IR) would
be the easiest to integrate into CLISP, although my intuition tells me that
transpilation to C would be easiest. At this point, I am wondering if there
is anyone available who is willing to mentor this project, so that I may
write a more detailed proposal to be submitted for GSoC and receive general
pointers.

Charles

On Fri, Feb 16, 2018 at 9:52 AM, Sam Steingold <[email protected]> wrote:

> Hi Charles,
>
> > * Charles Zhang <[email protected]> [2018-02-16 02:52:26 -0800]:
> >
> > I'd like to work on GNU CLISP for Google Summer of Code 2018.
>
> Welcome!
>
> > Specifically, I am interested in either implementing lock-free
> > hash-tables or
>
> I think getting MT to work has the highest priority ATM.
>
> > working on the backend, e.g. adding either a bytecode to C transpiler,
> > or using bytecode as an IR as a means to compile straight to native
> > code, either AOT or adding onto the existing JITC work. Another
> > possible idea I'm interested in would be to improve the byte-code
> > compiler itself: adding various optimizations not already done
>
> One compiler improvement that has been on the TODO list as long as I
> remember is
>
> Enhance the compiler so that it can inline local functions.
>
> (Using local function involves copying the closure object ATM, avoiding
> that would be very nice).
>
> > or (more ambitiously) to perform better type inference. As far as
> > I can tell, CLISP does not do as much type-informed optimizations as
> > other Common Lisp implmentations.
>
> I don't think type-informed optimizations would be easy to do in CLISP.
>
> > I am familiar with the internals of SBCL and know the details of Lisp
> > compilation fairly well, so compiler features rather than user-level
> > additions like library bindings would be more interesting to work on.
> > It would be great to hear thoughts from the CLISP maintainers on what
> > seems like a feasible GSoC goal.
>
> The success of your project depends on your commitment, which depends on
> your interest.
> Please pick whatever excites you.
>
> Thanks.
>
> --
> Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
> http://steingoldpsychology.com http://www.childpsy.net https://ffii.org
> http://thereligionofpeace.com http://islamexposedonline.com
> What's the difference between Apathy & Ignorance? -I don't know and don't
> care!
>



-- 
Class of 2021
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
clisp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-list