git @ Cat's Eye Technologies SixtyPical / 51b98df
Split TODO off into own file. Chris Pressey 3 years ago
3 changed file(s) with 114 addition(s) and 109 deletion(s). Raw diff Collapse all Expand all
00 History of SixtyPical
11 =====================
2
3 0.17
4 ----
5
6 * Split TODO off into own file.
27
38 0.16
49 ----
00 SixtyPical
11 ==========
22
3 _Version 0.16. Work-in-progress, everything is subject to change._
3 _Version 0.17. Work-in-progress, everything is subject to change._
44
55 **SixtyPical** is a 6502-like programming language with advanced
66 static analysis.
6767 * [Literate test suite for SixtyPical fallthru optimization](tests/SixtyPical%20Fallthru.md)
6868 * [6502 Opcodes used/not used in SixtyPical](doc/6502%20Opcodes.md)
6969 * [Output formats supported by `sixtypical`](doc/Output%20Formats.md)
70
71 TODO
72 ----
73
74 ### `low` and `high` address operators
75
76 To turn `word` type into `byte`.
77
78 Trying to remember if we have a compelling case for this or now. The best I can think
79 of is for implementing 16-bit `cmp` in an efficient way. Maybe we should see if we
80 can get by with 16-bit `cmp` instead though.
81
82 The problem is that once a byte is extracted, putting it back into a word is awkward.
83 The address operators have to modify a destination in a special way. That is, when
84 you say `st a, >word`, you are updating `word` to be `word & $ff | a << 8`, somelike.
85 Is that consistent with `st`? Well, probably it is, but we have to explain it.
86 It might make more sense, then, for it to be "part of the operation" instead of "part of
87 the reference"; something like `st.hi x, word`; `st.lo y, word`. Dunno.
88
89 ### Save multiple values in single block
90
91 As a shortcut for the idiom
92
93 save a { save var {
94 ...
95 } }
96
97 allow
98
99 save a, var {
100 ...
101 }
102
103 ### Save values to other-than-the-stack
104
105 Allow
106
107 save a to temp_a {
108 ...
109 }
110
111 Which uses some other storage location instead of the stack. A local static
112 would be a good candidate for such.
113
114 ### Make all symbols forward-referencable
115
116 Basically, don't do symbol-table lookups when parsing, but do have a more formal
117 "symbol resolution" (linking) phase right after parsing.
118
119 ### Associate each pointer with the buffer it points into
120
121 Check that the buffer being read or written to through pointer, appears in appropriate
122 inputs or outputs set.
123
124 In the analysis, when we obtain a pointer, we need to record, in contect, what buffer
125 that pointer came from.
126
127 When we write through that pointer, we need to set that buffer as written.
128
129 When we read through the pointer, we need to check that the buffer is readable.
130
131 ### Table overlays
132
133 They are uninitialized, but the twist is, the address is a buffer that is
134 an input to and/or output of the routine. So, they are defined (insofar
135 as the buffer is defined.)
136
137 They are therefore a "view" of a section of a buffer.
138
139 This is slightly dangerous since it does permit aliases: the buffer and the
140 table refer to the same memory.
141
142 Although, if they are `static`, you could say, in the routine in which they
143 are `static`, as soon as you've established one, you can no longer use the
144 buffer; and the ones you establish must be disjoint.
145
146 (That seems to be the most compelling case for restricting them to `static`.)
147
148 An alternative would be `static` pointers, which are currently not possible because
149 pointers must be zero-page, thus `@`, thus uninitialized.
150
151 ### Question "consistent initialization"
152
153 Question the value of the "consistent initialization" principle for `if` statement analysis.
154
155 Part of this is the trashes at the end; I think what it should be is that the trashes
156 after the `if` is the union of the trashes in each of the branches; this would obviate the
157 need to `trash` values explicitly, but if you tried to access them afterwards, it would still
158 error.
159
160 ### Tail-call optimization
161
162 More generally, define a block as having zero or one `goto`s at the end. (and `goto`s cannot
163 appear elsewhere.)
164
165 If a block ends in a `call` can that be converted to end in a `goto`? Why not? I think it can.
166 The constraints should iron out the same both ways.
167
168 And - once we have this - why do we need `goto` to be in tail position, strictly?
169 As long as the routine has consistent type context every place it exits, that should be fine.
170
171 ### "Include" directives
172
173 Search a searchlist of include paths. And use them to make libraries of routines.
174
175 One such library routine might be an `interrupt routine` type for various architectures.
176 Since "the supervisor" has stored values on the stack, we should be able to trash them
177 with impunity, in such a routine.
70 * [TODO](TODO.md)
0 TODO for SixtyPical
1 ===================
2
3 ### `low` and `high` address operators
4
5 To turn `word` type into `byte`.
6
7 Trying to remember if we have a compelling case for this or now. The best I can think
8 of is for implementing 16-bit `cmp` in an efficient way. Maybe we should see if we
9 can get by with 16-bit `cmp` instead though.
10
11 The problem is that once a byte is extracted, putting it back into a word is awkward.
12 The address operators have to modify a destination in a special way. That is, when
13 you say `st a, >word`, you are updating `word` to be `word & $ff | a << 8`, somelike.
14 Is that consistent with `st`? Well, probably it is, but we have to explain it.
15 It might make more sense, then, for it to be "part of the operation" instead of "part of
16 the reference"; something like `st.hi x, word`; `st.lo y, word`. Dunno.
17
18 ### Save multiple values in single block
19
20 As a shortcut for the idiom
21
22 save a { save var {
23 ...
24 } }
25
26 allow
27
28 save a, var {
29 ...
30 }
31
32 ### Save values to other-than-the-stack
33
34 Allow
35
36 save a to temp_a {
37 ...
38 }
39
40 Which uses some other storage location instead of the stack. A local static
41 would be a good candidate for such.
42
43 ### Make all symbols forward-referencable
44
45 Basically, don't do symbol-table lookups when parsing, but do have a more formal
46 "symbol resolution" (linking) phase right after parsing.
47
48 ### Associate each pointer with the buffer it points into
49
50 Check that the buffer being read or written to through pointer, appears in appropriate
51 inputs or outputs set.
52
53 In the analysis, when we obtain a pointer, we need to record, in contect, what buffer
54 that pointer came from.
55
56 When we write through that pointer, we need to set that buffer as written.
57
58 When we read through the pointer, we need to check that the buffer is readable.
59
60 ### Table overlays
61
62 They are uninitialized, but the twist is, the address is a buffer that is
63 an input to and/or output of the routine. So, they are defined (insofar
64 as the buffer is defined.)
65
66 They are therefore a "view" of a section of a buffer.
67
68 This is slightly dangerous since it does permit aliases: the buffer and the
69 table refer to the same memory.
70
71 Although, if they are `static`, you could say, in the routine in which they
72 are `static`, as soon as you've established one, you can no longer use the
73 buffer; and the ones you establish must be disjoint.
74
75 (That seems to be the most compelling case for restricting them to `static`.)
76
77 An alternative would be `static` pointers, which are currently not possible because
78 pointers must be zero-page, thus `@`, thus uninitialized.
79
80 ### Question "consistent initialization"
81
82 Question the value of the "consistent initialization" principle for `if` statement analysis.
83
84 Part of this is the trashes at the end; I think what it should be is that the trashes
85 after the `if` is the union of the trashes in each of the branches; this would obviate the
86 need to `trash` values explicitly, but if you tried to access them afterwards, it would still
87 error.
88
89 ### Tail-call optimization
90
91 More generally, define a block as having zero or one `goto`s at the end. (and `goto`s cannot
92 appear elsewhere.)
93
94 If a block ends in a `call` can that be converted to end in a `goto`? Why not? I think it can.
95 The constraints should iron out the same both ways.
96
97 And - once we have this - why do we need `goto` to be in tail position, strictly?
98 As long as the routine has consistent type context every place it exits, that should be fine.
99
100 ### "Include" directives
101
102 Search a searchlist of include paths. And use them to make libraries of routines.
103
104 One such library routine might be an `interrupt routine` type for various architectures.
105 Since "the supervisor" has stored values on the stack, we should be able to trash them
106 with impunity, in such a routine.