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 | 

