116 lines
3.8 KiB
Plaintext
116 lines
3.8 KiB
Plaintext
To-do list for Tock
|
|
-------------------
|
|
|
|
## General
|
|
|
|
## 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.)
|
|
|
|
Eventually (not yet), channel formals should take a direction; this should
|
|
either be given directly using decorators, or inferred from the code that uses
|
|
them.
|
|
|
|
## Support code
|
|
|
|
Types needs cleaning up and Haddocking.
|
|
|
|
## Driver
|
|
|
|
Add an option for whether to compile out overflow/bounds checks.
|
|
|
|
## Parser
|
|
|
|
## Passes
|
|
|
|
Come up with an approach to combining simple passes to avoid multiple tree
|
|
walks (for example, giving passes a "next thing to try" parameter).
|
|
|
|
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.
|
|
|
|
We should generally try to reduce the number of unnecessary pullups we do:
|
|
- plain subscripts that result in a non-array shouldn't pull up (e.g. x[i][j])
|
|
- expressions that are already a variable should just be turned into the variable
|
|
|
|
Pass to turn complicated conversions into simpler ones (currently done in
|
|
GenerateC).
|
|
|
|
Have a final pass that checks all the mangling has been done -- i.e. function
|
|
calls have been removed, and so on.
|
|
|
|
In the PAR wrapping pass, wrapper procs should not be generated for things that
|
|
are already PROC calls.
|
|
|
|
## 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.
|
|
|
|
Slice checks should not be generated if the slice is known to be safe.
|
|
|
|
PLACE should work.
|
|
|
|
Array comparisons generate silly code (rather than failing).
|
|
|
|
Pullups don't work properly for this at the moment, because index changes after
|
|
the pullup:
|
|
c ? index; [array FROM index]
|
|
(Tested in cgtest12.)
|
|
The sensible fix would probably be to make input items Structured, so we can
|
|
insert extra stuff into them.
|
|
|
|
The range checks are probably a bit expensive in stack terms at the moment -- I
|
|
need to check what EXTERNAL_CALLN actually does. If it's really bad we could
|
|
find a less expensive approach, such as being able to call SetErr with more
|
|
parameters.
|
|
|
|
## tock_support
|
|
|
|
No overflow checking is done on most operations.
|
|
|
|
Real-to-integer conversions don't work correctly.
|
|
|
|
## Usage checker
|
|
|
|
Not written yet, obviously...
|
|
|
|
Use a separation logic idea -- at any point in the program, we have a set of
|
|
resources. When you go parallel, you have to divide up the resources among the
|
|
parallel branches -- e.g. splitting a channel into read and write ends, carving
|
|
up an array, and so on. The safety check is done by making sure the resources
|
|
are actually divided up.
|
|
|
|
## Long-term
|
|
|
|
If we have constant folding, we're three-quarters of the way towards having an
|
|
occam *interpreter*.
|
|
|
|
Matt suggested that the TDS C compiler could be used to produce Transputer
|
|
bytecode from Tock's output (if Tock could be persuaded to generate ANSI C).
|
|
|
|
There should be a CIF interface to the Transterpreter runtime.
|
|
|
|
It would be possible to support GUY/ASM blocks on top of the Transterpreter
|
|
runtime, although I'm not sure how useful that really is.
|
|
|