tock-mirror/fco2/TODO

76 lines
2.2 KiB
Plaintext

To-do list for FCO
------------------
## General
Tock would be a good name for this (Translator from occam to C from Kent).
## Data structures
Think about simplifying the subscript types -- just have a single data type
that takes several expressions.
(Multi-subscript expressions like a[x][y] currently get pulled up into an array
slice, which is inefficient.)
The show instance for types should produce occam-looking types.
ParseState should be called something more sensible, since most of it has
nothing to do with parsing.
## Support code
Types needs cleaning up and Haddocking.
## Driver
Add an option for whether to compile out overflow/bounds checks.
## Parser
Record literals aren't implemented.
## Passes
Expression simplification -- this should use generics, so that we can have a
default behaviour that simplifies expressions inside another one.
Output item expressions should be pulled up to variables.
RETYPES of expressions should be converted to RETYPES of variables.
Before code generation, have a pass that resolves all the DATA TYPE .. IS
directives to their real types.
Pass to turn subscripted expressions into subscripted variables. (Need to write
a test for this -- use a function that returns an array?)
Have a final pass that checks all the mangling has been done -- i.e. function
calls have been removed, and so on.
## C backend
We could have genSpec generate {} around specs if it's not immediately inside
another spec (which'd require some extra boolean arguments to find out).
If the assembler-analysis approach to working out process sizes works, then we
can put the sizes in variables in a separate object file and only
generate/compile that after we've done the main one.
IF could detect, like CASE, whether it's got a TRUE branch.
IF could generate a simple if ... else ... without the gotos and label when
there's no replication or specs.
genParRep uses a C99 dynamic array for a dynamic PAR count, which may turn out
to be a bad idea for very large counts (since I assume it'll allocate off the
stack). We should probably do a malloc if it's not determinable at compile
time.
Real-to-integer conversions don't work correctly.
## Long-term
If we have constant folding, we're three-quarters of the way towards having an
occam *interpreter*.