Google Summer of Code 2013/cs648/Initial Meeting: Difference between revisions
(Created page with 'cps is analogous to coroutine_fn cps is infact a GCC function attribute - __attribute__((cps)) A good first task is to check the annotations in the QEMU tree are correct as the…') |
No edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 8: | Line 8: | ||
Suggest will take a week to read and understand the workings of cpc_runtime: | Suggest will take a week to read and understand the workings of cpc_runtime: | ||
* needs a blogpost to explain it as documentation once understood | |||
* any bugs/optimisations noticed should be submitted as (separate patches) | |||
A good place to start is to examine the different stages of CPC translation (accessed with -stageX option) | A good place to start is to examine the different stages of CPC translation (accessed with -stageX option) | ||
Best test compilation is cpc/samples/loops.cpc | Best test compilation is cpc/samples/loops.cpc | ||
| Line 17: | Line 18: | ||
Need to read and reimplement: | Need to read and reimplement: | ||
* cpc_sleep | |||
* cpc_spawn (not annotated with cps) | |||
* cpc_yield | |||
* cpc_invoke/call | |||
Don't need cpc_main loop | Don't need cpc_main loop | ||
Extensions | ==Extensions== | ||
Good extension is to skip translation if no cps functions, compile as C | Good extension is to skip translation if no cps functions, compile as C | ||
Need to benchmark result extensively, is important for understanding different "calling conventions" -ecpc mode and packed vs unpacked | Need to benchmark result extensively, is important for understanding different "calling conventions" -ecpc mode and packed vs unpacked | ||
==Milestone== | |||
Aim by Friday 21st is to produce a blog post documenting CPC memory format and how functions manipulate it | Aim by Friday 21st is to produce a blog post documenting CPC memory format and how functions manipulate it | ||
"anatomy of a continuation" | "anatomy of a continuation" | ||
* Define a CPC continuation as a datastructure | |||
* how it works in practise | |||
* detail cpc_push/cpc_invoke (also cpc-yield, cpc_spawn, cpc_patch) | |||
Latest revision as of 16:25, 21 June 2013
cps is analogous to coroutine_fn
cps is infact a GCC function attribute - __attribute__((cps))
A good first task is to check the annotations in the QEMU tree are correct as they are currently untested
Need to understand distinctions between packed/unpacked mode (also ecpc)
Suggest will take a week to read and understand the workings of cpc_runtime:
- needs a blogpost to explain it as documentation once understood
- any bugs/optimisations noticed should be submitted as (separate patches)
A good place to start is to examine the different stages of CPC translation (accessed with -stageX option)
Best test compilation is cpc/samples/loops.cpc
May turn out that coroutine_io.c is entirely built on coroutine.h primitives and therefore will not need editing for CPC variant.
Need to read and reimplement:
- cpc_sleep
- cpc_spawn (not annotated with cps)
- cpc_yield
- cpc_invoke/call
Don't need cpc_main loop
Extensions
Good extension is to skip translation if no cps functions, compile as C
Need to benchmark result extensively, is important for understanding different "calling conventions" -ecpc mode and packed vs unpacked
Milestone
Aim by Friday 21st is to produce a blog post documenting CPC memory format and how functions manipulate it
"anatomy of a continuation"
- Define a CPC continuation as a datastructure
- how it works in practise
- detail cpc_push/cpc_invoke (also cpc-yield, cpc_spawn, cpc_patch)