Home - madisongh/blissc GitHub Wiki

This wiki hosts information about the BLISS-M compiler.

Recent updates

Look at the git log for complete information, this will cover only highlights.

2013-04-21

  • First pass at generating and reading library files. The code needs some cleanup and further testing, but unit testing so far looks good.

2013-03-24

  • Initial stab at packaging with autotools. Configuration and build of the compiler is still pretty simple, but it works, as does make dist to create a source package. The version string is set to 0.1 for now.
  • Ran the compiler through valgrind and fixed an off-by-1 buffer overrun and several memory leaks in the cleanup code.
  • Other minor fixes for compiler warnings.

2013-03-17

  • Added a script to drive running the tests, and hooked up a 'make check' target.

2013-03-01

  • The compiler now works on 32-bit as well as 64-bit x86 hosts.
  • Test cases updated to produce uniform results on either 32- or 64-bit systems.
  • Several bugs fixed during testing.

2013-02-20

  • Added test cases for handling of literals, lexical functions, macros.
  • Fixed bugs found during testing.

2013-02-17

  • Removed the testfiles directory, which had some random files I was using for testing at various stages of early development. Added a new tests directory, along with the start of some tests that will be more systematic and automatable.
  • Found (and fixed) some bugs while running through the new tests.
  • Filed some bugs/enhancements earlier in the week for some known issues.

To-do list

  1. Complete the test suite based on the current capabilities in the compiler, and automate the tests.
  2. Check on further issues to be recorded. Some will come up during testing, others will come up as I review the LRM to create the test cases -- e.g., keywords not hooked up yet.
  3. Decide whether to pursue further enhancements to the LLVM back-end -- adding debug metadata, multiple target machines, fixing the MAIN problem, etc. -- or plug in another back-end for older processors (looking at TACK for this).
  4. More documentation.
  5. Package up with Autotools.
  6. More stress-testing for memory leaks.
  7. Reevaluate the error-handling paths in the front end. There are more places where the compiler needs to be smarter about error recovery, particularly in parts that were coded early on.