[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
GSoC 08 Ideas for DotGNU
From: |
Kirill Kononenko |
Subject: |
GSoC 08 Ideas for DotGNU |
Date: |
Mon, 10 Mar 2008 10:53:54 -0700 |
Hello,
Below is a list of ideas for the DotGNU project.
<h3><a id="dotgnu" href="http://www.gnu.org/software/dotgnu/">DotGNU</a></h3>
<ol>
<li><i>Finish the implementation of libJIT support for ARM or x86-64
(Complexity: medium)</i><br />For this project, you should be familiar with
compiler implementation techniques and the particulars of the target CPU's
instruction set. <a
href="http://www.southern-storm.com.au/doc/libjit/libjit_19.html#SEC37">The
libJIT manual</a> describes the steps needed to for porting libJIT to new
architectures. We can provide access to ARM and x86-64 machines, and indeed
machines with other CPUs too.</li>
<li><i>Finish libJIT ELF writer (Complexity: medium)</i><br/>Read <a
href="http://www.southern-storm.com.au/doc/libjit/libjit_1.html#SEC1">the
libjit rationale</a> for instruction and rationale for the DotGNU
JIT Library (libJIT). The libJIT library contains routines that
permit pre-compiling JIT'ed functions to an on-disk
representation. This representation can be loaded at some future
time, to avoid the overhead of compiling the functions at
runtime. We use the ELF format for this purpose, which is a common
binary format used by modern operating systems and compilers.
GNU/Linux uses ELF. However, it isn't necessary for your operating
system to be based on ELF natively. We use our own routines to read
and write ELF binaries. We chose ELF because it has all of the
features that we require, and reusing an existing format was better
than inventing a completely new one.</li>
<li><i>Port libJIT to a new architecture (Complexity:
medium)</i><br />You could port libJIT to a new architecture, for
example OpenRISC, SPARC, MIPSEL and so on. For this project, you
should be familiar with compiler implementation techniques and the
particulars of the target CPU's instruction set. The <a
href="http://www.southern-storm.com.au/doc/libjit/libjit_19.html#SEC37">libJIT
manual</a> describes the steps needed to for porting libJIT to new
architectures.</li>
<li><i>Porting Application (Complexity: medium)</i><br />There are a
number of Free applications using .NET which currently do not run
under DotGNU. Pick any non-trivial Free application and propose a
Summer-of-Code project to make it work under DotGNU. The <a
href="http://www.codeproject.com/">CodeProject</a> contains many
software projects that are interesting, but they are likely small.
Ports should aim to create a helper class library to assist in the
porting. Basically, every time a P/Invoke is found in one of these
applications or a dependency exists on a third-party control or
library, some stubs or primitive implementation should be exposed in
this "helper" library. This includes Windows.Forms, XML, and
Internet applications.</li>
<li><i>Enhance Windows.Forms (Complexity: medium)</i><br />The
Portable .NET Windows.Froms library implements much of .NET 1.1, but
many are still missing. None of the .NET 2.0 specific Windows.Forms
is implemented yet. This project would significantly enhance the
completeness of implementation of at .NET 1.1 or .NET 2.0.</li>
<li><i>Replacing CIL with native code. (Complexity: very
high)</i><br />DotGNU
contains a code generator that can be used for Just-in-Time compilation at
runtime. Code can also be compiled ahead of time to produce native
code before
it's needed.
JIT compilation is more commonly used, but for some systems where
memory is restricted or where startup time is important,
pre-compiling the code can be a significant win. The goal is to
modify the runtime and compilation so that the bytecodes can be
safely removed from a program and a single image is shipped
containing both metadata and native code.</li>
*
<li><i>Implement any C# 2.0, 3.0 feature. (Complexity: very
high)</i><br />The Portable .NET C# compiler is based on the <a
href="http://www.southern-storm.com.au/treecc_doc/treecc_toc.html">treecc</a>
tool.</li>
</ol>
<hr/>
Thanks,
Kirill
On 03/03/2008, Karl Berry <address@hidden> wrote:
> FYI, I have submitted an application for GNU to SoC 2008.
>
> I see from the SoC timeline
> (http://code.google.com/soc/2008/faqs.html#0.1_timeline) that there is
> only a week between org acceptance being finalized and student proposals
> starting.
>
> Therefore, we should probably move forward now on the hope that we will
> be approved again. If you want to participate as a mentor, please send
> ideas for student projects for your package asap. The easiest format
> for me to deal with is plain text html, formatted as a simple <ol> or
> <ul> list if you have more than one. I will begin updating the ideas
> page shortly (http://www.gnu.org/software/soc-projects/ideas.html), and
> send out a notice to other GNU lists.
>
> If you haven't been a mentor before (or as a reminder :), here is the
> general story:
>
> - you are committing to spend a nontrivial amount of time working with
> the student, proactively pinging them to make sure they are working
> along, etc. They won't just disappear and come back with beautiful code.
> This has been the #1 issue in past years.
>
> - please recruit a backup mentor for your package, just in case
> unexpected problems turn up and you have to bow out for some length of
> time.
>
> - during the application process, it's important to actually
> commmunicate with the students making proposals you like. Some
> individual communication turns up all kinds of things (like whether
> you really want to work with them, whether they really understand,
> etc.) and avoids surprises later.
>
> - it is very good to review, comment, and vote on as many proposals
> that are submitted as you can, not just those for your package. The
> more feedback (both for the student and for me :), the better.
>
> - there are always far more worthwhile projects than slots available
> from Google. As a result, any given GNU package is only going to get
> one project (except in some unforeseen extraordinary circumstance; I
> don't think it's happened yet). So pick the one you really like.
>
> In principle, I (since rms delegated this job to me) make the final
> decision, but I try hard not to be too arbitrary about it :).
>
> - there's a midterm progress report and final report that google
> requires from the mentor of each project. I'll also need to get
> feedback from you too about how things go, since they need that for
> the general organization report.
>
> I think those are the main points. So let the ideas roll, and feel free
> to try to stir up your individual package lists for ideas too.
>
> Thanks,
> Karl
>
>
>
- GSoC 08 Ideas for DotGNU,
Kirill Kononenko <=