Re: CLISP GSoC Project Ideas

Hi Charles,

I did not realize that you were writing to clisp-list, not clisp-devel.
I am replying there, so that Bruno will see it.
I hope he will volunteer to be the primary mentor.
I am certainly willing to help too, but Bruno's command of both C and
CLISP internals is unsurpassed.

Bruno, please respond!

Thanks.

> * Charles Zhang <[email protected]> [2018-02-18 17:57:19 -0800]:
>
> 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 http://camera.org
http://islamexposedonline.com http://thereligionofpeace.com
Would you like a dozen wireless mice to feed the Python book you just bought?

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