dotgnu-pnet
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pnet-developers] Google Summer of Code 2006


From: Kirill Kononenko
Subject: [Pnet-developers] Google Summer of Code 2006
Date: Mon, 1 May 2006 15:49:41 +0400

Hi All,
 
We participate in the Google Summer of Code as a part of the GNU Operating System. If you, your friends, your students can apply please do not hesitate to take a summer of fun.
 
The following is a list of items you might want to work on. Most of these tasks are considered at the moment to be 50% complete. If you want to modify or extend these tasks or have your own ideas, please see the GNU Project guidelines for Summer of Code projects. If you want to discuss potential projects with the team, we'd love to talk to you about it.
 
 
  1. Finish libJIT ELF writer (Complexity: medium-high)

    Read the libjit rationale 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.

  2. Port libJIT to a new architecture (Complexity: medium-high)

    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 libJIT manual describes the steps needed to for porting libJIT to new architectures.

  3. Enhance the libJIT interpreter (Complexity: medium)

    LibJIT includes an interpreter for running code on platforms that don't have a native code generator yet. This reduces the need for programmers to write their own interpreters for such platforms. Essentially, this project means making the regression tests with 'make check' in the Portable .NET directory work with the interpreter.

  4. Finish the implementation of libJIT support for ARM or x86-64 (Complexity: medium)

    For this project, you should be familiar with compiler implementation techniques and the particulars of the target CPU's instruction set.

    The libJIT manual 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.

  5. Enhance libJIT support for x86 (Complexity: medium)

    LibJIT includes a set of primitive code generators. However, the current implementation calls intrinstic functions for opcodes with long and float values. These need to be implemented as primitive code generators instead.

  6. Enhance libJIT optimization (Complexity: medium-high)

    For example, implement inlining, enhance constant propagation or dead-code elimination.

  7. Work on memory leaks, implement a special feature in GC. (Complexity: high)

    It would be beneficial to have a method in GC which can enumerate all objects which reference a specified object. The signature of this method might be, for example, object[] GC.GetReferences( object o ).

  8. Porting Application (Complexity: medium)

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

  9. Enhance Windows.Forms (Complexity: medium)

    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.

  10. Replacing CIL with native code. (Complexity: high)

    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.

  11. Implement generics or any other C# 2.0, 3.0 feature. (Complexity: very high)

    The Portable .NET C# compiler is based on the treecc tool.

  12. C# bindings for Allegro (Complexity: medium-high)

    This project would provide C# bindings for the Allegro library. This includes not only being able to call Allegro functions from C#, but also being able to do so in a way which 'feels natural' for the C# language. While the first part of the task is technically straightforward to define, the second part will require some thoughtful interface design.

    The Allegro library is a free video game software library, with functions for basic 2D graphics, image manipulation, text output, audio output, midi music, input and timers. It also includes additional routines for things like fixed-point and floating-point matrix arithmetic, unicode strings, file system access, file manipulation, data files, and (limited, software-only) 3D graphics.

    As of version 4.0, programs that use the library work on DOS, Microsoft Windows, BeOS, Mac OS X, and various Unix-like systems with (or without) the X Window System, abstracting their application programming interfaces into one portable interface. Allegro is very simple and easy to use yet powerful. In that way it is different from many other graphics libraries such as DirectX or SDL that offer more advanced functionality .

 
 
 
K
 
--
Kirill Kononenko
mail: Kirill.KononenkoATgmailDOTcom
PGP/GPG public key available on request
 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]