Open HLVM Projects

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.

If you are thinking about tackling one of these projects, please send a mail to the HLVM Developer's 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.

Projects in the list below are related to working on software code

1. ANTLR Front End. We need to investigate the use of ANTLR (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.
2. RNG->XHTML XSLT Stylesheet. 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.
3. APR Abstractions. 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.
4. Yaml Reader/Writer. 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.
5. Range Check Code Gen. 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.
6. Use Google hashmaps. 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 dense_hash_map and sparse_hash_map. However, to do this, several things need to be resolved:
   1. 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.
   2. 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 sparsetable as well as other places.
   3. 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.
   4. 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.

Projects in the list below are things that are missing or need to be fixed.

1. Enumerator Documentation. 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.

Projects in the list below are related to working on the projects documentation.

1. API Documentation. 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.
2. Tool Documentation. 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
3. General Documentation. General documentation about HLVM needs to be written.

Projects in the list below are related to testing software.

1. AST Construction Tests. 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 tests/xml2xml 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.
2. Code Gen Tests. 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 tests/return0 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.
3. Negative Tests. 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!

Here are some other things that need to get done.

1. Add HLVM project to SourceForge.net
2. Add HLVM project to collab.net
3. Create a logo for the project