Fork us on GitHub Follow us on Facebook Follow us on Twitter

Changes between Version 37 and Version 38 of Sysel


Ignore:
Timestamp:
2011-03-06T21:02:36Z (8 years ago)
Author:
Jiri Svoboda
Comment:

NNPS battle plan

Legend:

Unmodified
Added
Removed
Modified
  • Sysel

    v37 v38  
    1515
    1616|| '''Sub-project name'''            || '''Status''' || '''Description''' ||
    17 || Sysel Bootstrap Interpreter (SBI) || In progress  || Interpreter of Sysel written in C. Runs in HelenOS and POSIX. ||
    18 || Sysel Compiler Toolkit (NNPS)     || Not started  || Modular compiler of Sysel written in Sysel itself. To produce C and/or LLVM IR.
     17|| Sysel Bootstrap Interpreter (SBI) || Mostly       || Interpreter of Sysel written in C. Runs in HelenOS and POSIX. ||
     18|| Sysel Compiler Toolkit (NNPS)     || In progress  || Modular compiler of Sysel written in Sysel itself. To produce C and/or LLVM IR.
    1919
    2020== SBI ==
    2121
    22 SBI is an interpreter of Sysel currently in development. It is available stand-alone for POSIX or bundled with HelenOS (only in ''Bazaar repository'', not yet in a stable release). You can run it with the command "`sbi `''source_file.sy''". Demos that you can run are available in `/src/sysel/demos`. Source files comprising the library are in `/src/sysel/lib`.
     22SBI is an interpreter of Sysel. It is available stand-alone for POSIX or bundled with HelenOS (only in ''Bazaar repository'', not yet in a stable release). You can run it with the command "`sbi `''source_file.sy''". Demos that you can run are available in `/src/sysel/demos`. Source files comprising the library are in `/src/sysel/lib`.
    2323
    2424You can also run `sbi` without parameters to enter interactive mode.
     25
     26SBI still has some missing features, but covers enough of the language to start development of NNPS.
    2527
    2628=== Synopsis of current SBI features ===
     
    3941=== Missing SBI features ===
    4042
    41 Should be addressed before phase 2:
     43More important:
    4244 * Access control
    4345 * ~~Method overloading~~ (rejected)
     
    4648 * Property overriding
    4749
    48 Not necessary for phase 2:
     50Less important:
    4951 * Division
    5052 * Structs
     
    5658
    5759 * Add cspan to all error and warning messages.
    58  * Most run-time errors should have been caught during static checking. They need to be reviewed, efectiveness of static checking verified and run-time errors converted to asserts.
     60 * Most run-time errors should have been caught during static checking. They need to be reviewed, effectiveness of static checking verified and run-time errors converted to asserts.
    5961 * All errors should be handled gracefully. Calls to `exit()` must be eliminated.
    6062
     
    6769NNPS will be bootstrapped using SBI. That is by running SBI(NNPS(NNPS)) we will obtain a binary version of NNPS. This process will presumably require 'significant' computing resources since SBI is rather slow and consumes a lot of memory. Once compiled to binary form, NNPS should be much more modest.
    6870
    69 Currently only the NNPS lexer has been implemented (as an experiment). When all missing SBI features listed as ''Should be addressed before phase 2'' have been addressed, development focus should switch from SBI to NNPS.
     71Currently the NNPS lexer and skeleton parser has been implemented (it verifies that input is syntactically valid, but nothing else). I am now focusing on developing NNPS while simultaneously improving SBI where needed.
     72
     73NNPS shall process the code in several separate stages. The first few are common with SBI:
     74
     75|| Parsing             || Lex and parse source files to produce a syntax tree ||
     76|| Ancestry resolution || Determine ancestry of classes and interfaces ||
     77|| Typing              || Annotate syntax tree with static types and make all type conversions explicit ||
     78
     79While the remaining are specific to NNPS:
     80
     81|| Code lowering       || A.k.a. code generation. Produce CFG with linear blocks of instructions. Implements/eliminates structured code and OO features. ||
     82|| Data lowering       || Implements/eliminates structured data, strings, big integers. We get a CFG again, but with a different instruction set. ||
     83|| Output translation  || Conversion to the desired output format (LLVM IR, C). Straightforward. ||
     84
     85From the ''code lowering phase'' we obtain a CFG where the instructions operate on structured data (objects, arrays), but the code is strictly procedural (functions, but no methods, no inheritance). The ''data lowering phase translates'' these instructions into another instruction set that is more like an abstract CPU instruction (or LLVM IR). Thus in this phase, we need to implement the objects, arrays, strings and big integers. The ''output translation'' should be a simple 1-1 translation.
    7086
    7187== Other Links ==