cadey
/
nim-wiki
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Updated GSoC 2014 Ideas (markdown)

This commit is contained in:
Andreas Rumpf 2014-02-12 15:43:10 -08:00
parent 9f6cab8ac9
commit f705232f60
1 changed files with 15 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
GSoC-2014-Ideas.md
View File

@ -7,9 +7,16 @@ Below is a list of project ideas for [GSoC](https://www.google-melange.com/gsoc/
## Nimrod Compiler ## Nimrod Compiler
#### Add support for full coroutines #### Add support for full coroutines
* Full coroutines in contrast to Nimrod's closure iterators can capture the full call stack.
* Needs inline assembler to implement the stack switching. **Description:**
* The GC needs to support conservative marking of multiple stacks * Many programming languages, in particular Lua, offer coroutines as way to provide light-weight collaborative tasking. Nimrod supports "closure iterators" which are comparable to Python's generators to accomplish the same.
* However closure iterators are much more limited as they cannot capture the call stack completely.
* The best example to see the limitations of Nimrod's current way is that iterators cannot be recursive.
Here is a sketch of a possible implementation, but there are lots of other possibilities to implement full coroutines for Nimrod:
* Implement the necessary stack switching via inline assembler.
* The GC needs to support conservative marking of multiple stacks.
* In particular the write barrier in the GC which does the 'isOnStack' check needs to be changed. * In particular the write barrier in the GC which does the 'isOnStack' check needs to be changed.
* Using a bloom filter for quick testing whether an address belongs to some stack is likely to pay off. * Using a bloom filter for quick testing whether an address belongs to some stack is likely to pay off.
* Creating a coroutine needs to register a new stack to the GC. * Creating a coroutine needs to register a new stack to the GC.
@ -50,9 +57,6 @@ provides configuration for the code generator and implements the logic of the ga
**Mentor:** zahary ([@zah](http://github.com/zah)) **Mentor:** zahary ([@zah](http://github.com/zah))
___
#### Fix bugs with iterators/generics
...
___ ___
#### Fix/Expand Nimrod's "Compiler as a Service" features #### Fix/Expand Nimrod's "Compiler as a Service" features
@ -228,6 +232,8 @@ Babel is the Nimrod package manager. It is currently very basic and some importa
**Mentor:** dom96 ([@dom96](http://github.com/dom96)) **Mentor:** dom96 ([@dom96](http://github.com/dom96))
___ ___
#### Implement re2nim, a lexer generator for nimrod #### Implement re2nim, a lexer generator for nimrod
**Description:**
* Model it after re2c or the Ragel state machine generator * Model it after re2c or the Ragel state machine generator
* Alternatively model it after Flex. * Alternatively model it after Flex.
@ -240,6 +246,9 @@ ___
**Mentor:** zahary ([@zah](http://github.com/zah)) **Mentor:** zahary ([@zah](http://github.com/zah))
___ ___
#### Implement a Nimrod backend for the Ragel state machine generator #### Implement a Nimrod backend for the Ragel state machine generator
**Description:**
* Ragel is a widely used state machine generator which supports C, C++ etc. But not Nimrod. So let's change that.
* http://www.complang.org/ragel/ * http://www.complang.org/ragel/
**Skill Requirements**: Knowledge of Ragel's internals. **Skill Requirements**: Knowledge of Ragel's internals.