Difference between revisions of "SCOOP-A3: Compiler adaptation"
m (Added a note that processor syntax will not be supported in 6.7) |
m (Introduced several new sections with more details) |
||
Line 3: | Line 3: | ||
[[Category:Compiler]] | [[Category:Compiler]] | ||
Team: [[User:Alexander Kogtenkov|Alexander Kogtenkov]], [[User:Ted|Ted]] | Team: [[User:Alexander Kogtenkov|Alexander Kogtenkov]], [[User:Ted|Ted]] | ||
− | + | = Summary = | |
* '''Parser''' | * '''Parser''' | ||
** Support only separate type declarations (exclude separate class declarations). | ** Support only separate type declarations (exclude separate class declarations). | ||
Line 15: | Line 15: | ||
** C code | ** C code | ||
** CIL code | ** CIL code | ||
+ | = Decisions = | ||
+ | # Syntax | ||
+ | #* Drop support of separate classes, only separate types are supported. | ||
+ | #* Separate mark is allowed not only for class types, but also for other types. | ||
+ | # Semantics | ||
+ | #* Default formal generic constraint is <e>detachable separate ANY</e>. | ||
+ | #* Formal generic is considered non-separate if at least one constraint is not separate, otherwise it is considered separate. | ||
+ | # Code generation | ||
+ | #* Separate and non-separate class types are generated separately, i.e. <e>ANY</e> and <e>separate ANY</e> get different code. | ||
+ | #* Generic derivations with separate and non-separate generics are generated separately, i.e. <e>ARRAY [G]</e> and <e>ARRAY [separate G]</e> get different code. | ||
+ | = Open questions = | ||
+ | * Shall separate types be supported in CECIL? If yes, how this is done? | ||
+ | = Progress = | ||
+ | {| border="1" style="border-collapse: collapse; border-width: 1px; border-style: solid;" | ||
+ | |+ SCOOP support in compiler | ||
+ | ! Functionality !! Status | ||
+ | |- | ||
+ | | Syntax for separate types || rev#84252 | ||
+ | |- | ||
+ | | Separate status in conformance tests || | ||
+ | |- | ||
+ | | Validity rules specific to separate types || | ||
+ | |- | ||
+ | | Bytecode generation || | ||
+ | |- | ||
+ | | C code generation || | ||
+ | |- | ||
+ | | CIL code generation || | ||
+ | |} |
Revision as of 02:21, 25 August 2010
Team: Alexander Kogtenkov, Ted
Contents
Summary
- Parser
- Support only separate type declarations (exclude separate class declarations).
- Provide syntax to refer to the processors (not supported in 6.7).
- Take into account the possibility to use anchors.
- Type checking introduces new
- Conformance rules that affect type system
- Validity rules that require good description of errors
- Code generation is closely connected with work on the scheduler (A1, A2) and should target
- bytecode
- C code
- CIL code
Decisions
- Syntax
- Drop support of separate classes, only separate types are supported.
- Separate mark is allowed not only for class types, but also for other types.
- Semantics
- Default formal generic constraint is
detachable separate ANY
. - Formal generic is considered non-separate if at least one constraint is not separate, otherwise it is considered separate.
- Default formal generic constraint is
- Code generation
Open questions
- Shall separate types be supported in CECIL? If yes, how this is done?
Progress
Functionality | Status |
---|---|
Syntax for separate types | rev#84252 |
Separate status in conformance tests | |
Validity rules specific to separate types | |
Bytecode generation | |
C code generation | |
CIL code generation |