|
From: | Kirill Kononenko |
Subject: | [Pnet-developers] Google Summer of Code 2006 |
Date: | Mon, 1 May 2006 15:49:41 +0400 |
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.
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.
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.
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.
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.
For example, implement inlining, enhance constant propagation or dead-code elimination.
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 )
.
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.
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.
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.
The Portable .NET C# compiler is based on the treecc tool.
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 .
[Prev in Thread] | Current Thread | [Next in Thread] |