forked from openbios/fcode-utils
-
Notifications
You must be signed in to change notification settings - Fork 0
/
TODO
298 lines (261 loc) · 10.7 KB
/
TODO
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
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
fcode-utils/detok/decode.c
Line 46:
*
* Still to be done:
* Handling of indent-level is not correct. Branches should
* balance with their resolvers; constructs like do..loop
* case/of/endof/endcase are a few major examples.
* This will be tricky; the rules need to be carefully thought
* out, and the implementation might be more complex than
* at first meets the eye...
*
Line 280:
*
* Still to be done:
* More sophisticated error-checking for invalid offsets. Look
* at the type of branch, and what should be expected in the
* vicinity of the destination. (This might be best served
* by a separate routine).
* This might also help with handling the indent-level correctly...
* Also, if indentation were to be handled in this routine,
* there would be no need to return the value of the offset.
*
fcode-utils/detok/pcihdr.c
Line 67:
*
* Still to be done:
* Print (as remarks) full descriptions of headers' fields
* Error check for wrong "Format"
* Skip past non-FCode blocks, thru multiple data-blocks
* Recognize PCI header in unexpected place or out-of-place
*
Line 130:
*
* Still to be done:
* Error-check; look for inconsistencies:
* Return a Negative Number if data-stream appears to be a PCI
* header, but has erroneous or inconsistent sub-field contents.
* Value and meaning of the Negative Number yet to be defined.
*
Line 188:
*
* Still to be done:
* Error-check; look for wrong "Code Type" or other inconsistencies:
* Return a Negative Number if data-stream appears to be a
* valid PCI Data Structure, but has erroneous or inconsistent
* sub-field contents.
* Value and meaning of the Negative Number yet to be defined.
* Skip past non-FCode data-blocks, even multiple blocks
*
Line 364:
*
* Still to be done:
* Handle error cases. At present, neither is_pci_header()
* nor is_pci_data_struct() returns a negative number,
* but when they are modified to do so, we must handle it.
*
Line 442:
*
* Still to be done:
* Come up with something more elegant for non-zero filler.
*
fcode-utils/detok/printformats.c
Line 74:
*
* Still to be done:
* Define a routine, call it PrintComment , to print the given
* string surrounded by open-paren-space ... space-close-paren
* Define a single central routine, call it safe_malloc ,
* to do the test for null and print "No Memory" and exit.
* Define a single central routine, call it PrintError , to:
* Print the given error message
* Show the input file and line number
* Collect error-flags for failure-exit at end of operation.
*
fcode-utils/toke/devnode.c
Line 67:
*
* Still to be done:
* Add a pair of fields to the data-structure for the Input File and
* Line Number where "finish-device" occurred. When a device-node
* is "finish"ed, do not delete it, but instead fill in those
* fields and the move the node to a separate linked-list.
* When looking whether a word exists in an ancestor-node, also
* check whether it was in a device-node that was finished and
* print both where it was started and where it was finished.
*
fcode-utils/toke/emit.c
Line 34:
*
* Still to be done:
* Re-arrange routine and variable locations to clarify the
* functions of this file and its companion, stream.c
* This file should be concerned primarily with management
* of the Outputs; stream.c should be primarily concerned
* with management of the Inputs.
* Hard to justify, pragmatically, but will make for easier
* maintainability down the proverbial road...
*
fcode-utils/toke/flowcontrol.c
Line 75:
*
* Still to be done:
* Correct analysis of Return-Stack usage around Flow-Control
* constructs, including within Do-Loops or before Loop
* Elements like I and J or UNLOOP or LEAVE.
* Similarly, Return-Stack usage around IF ... ELSE ... THEN
* statements needs analysis. For instance, the following:
*
* blablabla >R yadayada IF R> gubble ELSE flubble R> THEN
*
* is, in fact, correct, while something like:
*
* blablabla >R yadayada IF R> gubble THEN
*
* is an error.
*
* Implementing an analysis that would be sufficiently accurate
* to justify reporting an ERROR with certainty (rather than
* a mere WARNING speculatively) would probably require full
* coordination with management of Flow-Control constructs,
* and so is noted here.
*
fcode-utils/toke/macros.c
Line 166:
*
* Still to be done:
* If an error is encountered during Macro evaluation, display
* supplemental information giving the name of the Macro
* being run, and the file and line number in which it was
* defined.
* This will require changes to the way user Macros are added
* and retained, and to the way error messages are displayed.
*
fcode-utils/toke/nextfcode.c
Line 90:
*
* Still to be done:
* Detect and report when the Current Range stops overlapping
* one particular Range and starts overlapping another.
*
fcode-utils/toke/scanner.c
Line 1046:
*
* Still to be done:
* Better protection against PC pointer-over-run past END.
* Currently, this works, but it's held together by threads:
* Because init_stream forces a null-byte at the end of
* the input buffer, parse_number() exits immediately upon
* encountering it. This situation could be covered more
* robustly...
*
Line 2192:
*
* Still to be done:
* Full detection of whether the Return-Stack has been cleared
* when required, including analysis of Return-Stack usage
* within Flow-Control constructs, and before Loop elements...
*
Line 2259:
*
* Still to be done:
* Correct analysis of Return-Stack usage around Flow-Control
* constructs. Consider, for instance, the following:
*
* blablabla >R yadayada IF R> gubble ELSE flubble R> THEN
*
* It is, in fact, correct, but the present scheme would
* tag it as a possible error. Conversely, something like:
*
* blablabla >R yadayada IF R> gubble THEN
*
* would not get tagged, even though it is actually an error.
*
* The current simple scheme also does not cover Return-Stack
* usage within Do-Loops or before Loop elements like I and
* J or UNLOOP or LEAVE. Implementing something like that
* would probably need to be integrated in with Flow-Control
* constructs, and will be noted in flowcontrol.c
*
Line 2323:
*
* Still to be done:
* Correct analysis of Return-Stack usage...
*
Line 3299:
*
* Still to be done:
* If the definer-name is not found, we might still look up
* the target name in the various vocabularies and use
* a phrase for those. E.g., if it is a valid token,
* we could say it's defined as a "primitive". (I'm
* not sure what we'd say about an FWord...)
*
Line 4617:
*
* Still to be done:
* Correct analysis of Return-Stack usage within Do-Loops
* or before Loop Elements like I and J or UNLOOP or LEAVE.
*
fcode-utils/toke/stream.c
Line 60:
*
* Still to be done:
* Re-arrange routine and variable locations to clarify the
* functions of this file and its companion, emit.c
* This file should be concerned primarily with management
* of the Inputs; emit.c should be primarily concerned
* with management of the Outputs.
* Hard to justify, pragmatically, but will make for easier
* maintainability down the proverbial road...
*
Line 1070:
*
* Still to be done:
* Set a flag when carr-ret has been replaced by space;
* when a string crosses a line, if this flag is set,
* issue a warning that an extra space has been inserted.
*
fcode-utils/toke/toke.c
Line 363:
*
* Still to be done:
* Devise a syntax to allow the command-line to specify multiple
* input files together with an output file name for each.
* Currently, the syntax allows only one output file name to be
* specified; when multiple input file names are specified,
* the specification of an output file name is disallowed,
* and only the default output file names are permitted.
* While this works around the immediate problem, a more
* elegant solution could be devised...
*
fcode-utils/toke/usersymbols.c
Line 78:
*
* Still to be done:
* Convert the handling of user-defined symbols to the T.I.C.
* data-structure and its support routines. This should
* eliminate any further need of String-Substitution-type
* vocabularies. User-defined symbols will, however, still
* need to be a separate vocabulary from the Global, because
* they are required to stay in effect for the duration of
* the entire batch of tokenizations...
* (Afterthought: This is only true for user-defined symbols that
* were created on the command-line; if we ever allow symbols
* to be defined in the Source file, they should be as volatile
* as anything else that comes from a source file...
* Appending source-file-derived user-defined symbols to the Global
* Vocabulary could be a quasi-simple way to accomplish this.)
*
Line 246:
*
* Still to be done:
* Hook-in this routine to the processing of: ['] F['] H# FLOAD
* etc., and wherever else it might be needed or useful.
*
Line 316:
*
* Still to be done:
* Space the duplicate-name notation evenly; line it up past
* the longest name-with-value.
*