| Version 2 (modified by , 4 years ago) ( diff ) |
|---|
Wishlist
Features
- All properties should be able to be turned on or off
- Any function can be an entry point. Something like
-programEntry=<function ID> - CIVL report coverage data
- Which statements executed and the number of times they were. Perhaps color code the statements.
- CIVL must be concurrent
- CIVL debugger
- Able to manually step through code choosing which transitions to take.
- Breakpoints
- Some statement that you can insert that, when in debugging mode, asks which transition to take at that point.
$ask; - At any stopped point in the code be able to observe the current execution path and state.
- Similarly, be able to evaluate expressions at any point from any specific process.
- Be able to store high memory items into the hard drive to save memory while executing.
-showProgramshould be able to be directly executed by CIVL.- Be able to specify which transformations we apply when executing
-showProgram
- Be able to specify which transformations we apply when executing
- If
-showProgramenabled and we get an error, then print AST before exiting. - Be able to specify hardware environment to verify under like ints are 32 bits, floats are 32 bits, big-endian vs little-endian, etc.
Design
- Everything goes in one repository
- The ability to associate static traits to ASTs like "no for loops" or "side effect free", etc.
- Be able to easily loop over AST nodes of a certain type (in program order). Maybe just support visitor pattern.
- CIVL-C language and library must be completely well-defined and documented.
- CIVL-IR must be completely well-defined and documented.
- Break up Evaluator by removing big switch:
- Have "ExecutableExpression" and "ExecutableStatement"-type classes which have an evaluate method and extend the syntactic Expression and Statement classes.
- Components:
- Util - uses nothing
- SARL - uses Util
- ABC - uses SARL, Util
- MC - uses ABC, SARL, Util
Process
- No additions accepted to trunk until
- at least unit tests with 100% statement coverage
- the code has been read by at least two other developer
- Perhaps use some kind of web tool that you can highlight code and leave comments on
- Should be regular formal code reviews
Continue Doing
- Code formatter
- Automatic test and coverage analysis
Note:
See TracWiki
for help on using the wiki.
