Copilot/TODO at testingFunctions · devmjc/Copilot · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
TODOs

* Fix 'XXX's through the code.

* Modify atom so that it refuses names that produce invalid C code. See
   checkname in Language.Atom.Elaboration.hs (still probably bugged) Also see
   normalizeVar in Language.Copilot.Core.hs. (Actually, should Copilot worry
   about it?  It'll just fail during compilation, so there's nothing dangerous
   about it.)

 * Add arrays to the language(?)

 * Do MC/DC coverage testing(?)
   * Use the open-source Certification thing?

 * AIG-based equivalence checking.

 * Add math.h functions to Language.hs.

 * Move all the error-checking to one file, instead of "error ..." spread all
   over.

 * Better error handling/error message for bad options/parameters for interface
   functions.  Perhaps use hsTidy?  <http://hackage.haskell.org/package/hstidy>

 * Use para <http://hackage.haskell.org/package/para> for pretty-formatting
   error msgs from Analyzer.hs as well as Help.hs.

 * Add to Help.hs documentation on using the setClock function to use the HW
   clock.

 * Go through using hlint suggestions.

 * Fix splint warnings on generated C code

 * Libs/Indexes return a parameterized type rather than Int16

 * Display external vars when interpreting

 * send lets you send stream values on ports at some phase.  Make sure that the
   stream semantics are preserved by ensuring you don't send at in appropriate
   times.

 * Allow for sampling functions; i.e., you get the return value of the
   function.  So you don't have to set up extra C vars to get the function
   values.

 * We might want to put triggers at phase 1 and draw on the output vars so as to
   avoid computing so many next-states.

 * Make showing better---don't show with constructors but something more
   user-friendly.  ShowRaw in Core.hs.

 * Generate random arrays?

 * Compare some sample specs to Lustre and Esterel.

 * Try the cast operation in Core.hs.

 * Revisit: why no sampling in phase 0?

 * Move triggers to Compile.hs.

 * Define a clocks library.

 * Remove the notion of a phase!!  To low-level.  As the programmer, you should
   JUST manipulate clocks.  The period is the smallest unit of time, as far as
   you're concerned.

 * Lots of debugging with sampling functions (both array and var return types).

 * Add a 'when' operator to the Clocks lib: when clk foo means update foo if clk
   is true.

 * The scheduling is completely unoptimized...  All sampling in phase 1, and all
   next-state computation in phase 0.  Spread out as room permits across phases?
   (Need to add a "beforePhase" to Atom.)

 * Normalize variables just once and then pass those around instead of doing it
   ad-hoc throughout the compiler.

 * Make a constant for the setPP option of ("","") meaning don't try to
   compile/add main.  Do we really want to have an option to set array index
   sizes?  What if we're sampling a function that returns an array?  Also, we
   don't declare functions in general...  We could, but do we want to?