blob: e1b973f74b5d1312004e3bd4ab81ff4b1839b9c5 [file] [log] [blame]
<!--#set var="title" value="Open Projects" -->
<!--#include virtual="/incl/header.incl" -->
<h1>Open HLVM Projects</h1>
<ul>
<li><a href="#what">What is this?</a></li>
<li><a href="#code">Coding Projects</a></li>
<li><a href="#cleanup">Cleanup Projects</a></li>
<li><a href="#doc">Documentation Projects</a></li>
<li><a href="#test">Testing Projects</a></li>
<li><a href="#misc">Miscellaneous Projects</a></li>
</ul>
<h2><a name="what">What is this?</a></h2>
<div class="text">
<p>This document is a "TODO" list for HLVM. Each project in this document is
something that would be useful for HLVM to have, and would also be a great way
to get familiar with the system. Some of these projects are small and
self-contained, which may be implemented in a couple of days. Others are
larger. In any case, we welcome all contributions.</p>
<p>If you are thinking about tackling one of these projects, please send a mail
to the <a href="/hlvm-dev.shtml">HLVM Developer's</a> mailing
list, so that we know the project is being worked on. Additionally this is a
good way to get more information about a specific project or to suggest other
projects to add to this page.</p>
</div>
<h2><a name="code">Coding Projects</a></h2>
<div class="text">
<p>Projects in the list below are related to working on software code</p>
<ol>
<li><em>ANTLR Front End</em>. We need to investigate the use of
<a href="http://www.antlr.org/">ANTLR</a> (ANother Tool for Language
Recognition) as a possible front end lexer/parser for HLVM. Ideally I would
like to see a set of C++ constructs to make mapping from a source language
to the HLVM AST very simple. For example, a simple set of macros or
functions that build an HLVM AST could be used as the semantic actions for a
grammar. This task is to analyze the suitability of ANTLR for HLVM.</li>
<li><em>RNG->XHTML XSLT Stylesheet</em>. We will use the Relax/NG grammar
for the XML version of the AST to document the AST. However, the Relax/NG
specification is not particularly user friendly. What we need is a way to
publish (in XHTML) the specification with descriptive documentation. A
fairly straightforward XSLT stylsheet to translate Relax/NG to XHTML should
do nicely. This is a nice self-contained project for someone who knows
XSLT and can understand Relax/NG.</li>
<li><em>APR Abstractions</em>. The runtime portion of HLVM will use APR
as its portability layer. However, APR is written in C and not particularly
object-oriented. We need some of the things APR supports to be wrapped in
simple C++ classes that take care of the book keeping such as deleting APR
objects at the right time. Abstracts we need to wrap, currently, are Pool
and File. These should go in HLVM's "base" library.</li>
<li><em>Yaml Reader/Writer</em>. We intend to support a reader and
writer of the AST in Yaml syntax. Some people just don't like XML and having
an alternate way to build the AST from a nicer-to-read source would be
useful in helping some people comprehend HLVM. The design should be very
similar to the XML Reader/Writer and be based on the Syck library.</li>
<li><em>Range Check Code Gen</em>. This is a well contained project having
to do with emitting LLVM code to do range checking for RangeType
variables. RangeType's are currently treated like integers without range
checking.</li>
<li><em>Use Google hashmaps</em>. We would like to convert HLVM away from
the slow and bulky STL maps currently being used to google's open source
maps such as <tt>dense_hash_map</tt> and <tt>sparse_hash_map</tt>. However,
to do this, several things need to be resolved:
<ol>
<li>Do we incorporate the code into HLVM, or build it separately and
reference it when configuring HLVM? Its just a few header files, so the
former approach seems okay, but this needs to be investigated.</li>
<li>The google code exposes its "config.h" which will conflict with
ours. It defines several macros from the config.h info and uses them
in <tt>sparsetable</tt> as well as other places.</li>
<li>Deciding whether to use sparse or dense versions of the hash maps
needs to be decided on a case-by-case basis. In general, where the map is
not expected to be large (like MultiOperator), dense should give us good
performance. In cases where the content could be large (like SymbolTable),
it might be wiser to use the sparse version. Same for the various maps
used in LLVMGenerator.cpp and LLVMEmitter.cpp.</li>
<li>Consider writing wrappers for these classes. Since we're going to
compile HLVM with LLVM (eventually), the wrappers would get discarded by
LLVM's inliner so the performance loss wouldn't be great.</li>
</ol>
</li>
</ol>
</div>
<h2><a name="cleanup">Cleanup Projects</a></h2>
<div class="text">
<p>Projects in the list below are things that are missing or need to be
fixed.</p>
<ol>
<li><em>Enumerator Documentation</em>. Right now enumerators are simple
string values in the EnumerationType. This prevents documentation from being
associated with the Enumerators. This needs to be fixed so that
documentation can be associated with the enumerators.</li>
</ol>
</div>
<h2><a name="doc">Documentation Projects</a></h2>
<div class="text">
<p>Projects in the list below are related to working on the projects
documentation.</p>
<ol>
<li><em>API Documentation</em>. Documenting the HLVM AST API is very
important. Currently it needs some work. Someone who knows Doxygen and
would like to keep the documentation up to date would be very helpful.</li>
<li><em>Tool Documentation</em>. As HLVM produces tools, those tools need to
be documented in a POD file. Also, the packaging of the generated HTML and
INFO files leaves a little to be desired. In particular these file should be
available through the public web site</li>
<li><em>General Documentation</em>. General documentation about HLVM needs
to be written.</li>
</ol>
</div>
<h2><a name="test">Testing Projects</a></h2>
<div class="text">
<p>Projects in the list below are related to testing software.</p>
<ol>
<li><em>AST Construction Tests</em>. In order to explore and test the AST
node construction, we need to develop test cases that exercise these
aspects of HLVM. These test cases are in the <tt>tests/xml2xml</tt>
directory. They are snippets of XML to test construction of the
AST by using the hlvm-xml2xml program. Many of these test cases will
explore ideas for what should or shouldn't be in the AST.</li>
<li><em>Code Gen Tests</em>. In order to verify program correctness, a wide
variety of tests to check for correct code generation are needed. These test
are found in the <tt>tests/return0</tt> directory. These are full HLVM
programs written in the AST XML language that should return from main with
a value of 0 if the test succeeds. They are intended to check control flow,
arithmetic, and other aspects of runtime behavior of the HLVM code
generator and runtime system.</li>
<li><em>Negative Tests</em>. These are tests that provide invalid input to
HLVM to ensure that it doesn't crash but instead generates a nice error
message. There are no tests in this class yet. Help!</li>
</ol>
</div>
<h2><a name="misc">Miscellaneous Projects</a></h2>
<div class="text">
<p>Here are some other things that need to get done.</p>
<ol>
<li>Add HLVM project to SourceForge.net</li>
<li>Add HLVM project to collab.net</li>
<li>Create a logo for the project</li>
</ol>
</div>
<!--#include virtual="/incl/footer.incl" -->