GSoC 08 Ideas for DotGNU

[Kirill Kononenko]

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
>
>
>