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
<http://www.gnu.org/software/soc-projects/guidelines.html>. 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
<http://www.southern-storm.com.au/doc/libjit/libjit_1.html#SEC1>
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
<http://www.southern-storm.com.au/doc/libjit/libjit_19.html#SEC37>
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
<http://www.southern-storm.com.au/doc/libjit/libjit_19.html#SEC37>
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 <http://www.codeproject.com/>
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
<http://www.southern-storm.com.au/treecc_doc/treecc_toc.html> tool.
12. C# bindings for Allegro <http://www.allegro.cc/> (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
------------------------------------------------------------------------
_______________________________________________
Pnet-developers mailing list
address@hidden
http://dotgnu.org/mailman/listinfo/pnet-developers