1 | 4) How do you model I/O operations? |
---|
2 | 5) How do you plan to run the assembler? Can you extract an executable assembler from the Matita implementation? |
---|
3 | 6) Right now, the proofs and specifications are mixed together in the Matita files. Is there a way to isolate and quantify the definitions that you trust for correctness (the "trusted computing base")? |
---|
4 | |
---|
5 | ----------------------- REVIEW 4 --------------------- |
---|
6 | 1. The title talks about an _optimising_ assembler, but the only |
---|
7 | optimisation seems to be in calculating branch displacements and this |
---|
8 | question is only partially resolved in the paper. Can assemblers be |
---|
9 | expected to perform any other optimisations? |
---|
10 | |
---|
11 | 2. The abstract talks about "the efficient expansion of |
---|
12 | psuedoinstructions---particularly jumps---is complex", but given that |
---|
13 | this is the sole optimisation, it would seem more accurate to say |
---|
14 | "...---namely jumps". Furthermore, the word "complex" is perhaps |
---|
15 | overreaching. |
---|
16 | |
---|
17 | 3. Some parts of the text lack precision. Namely: |
---|
18 | |
---|
19 | a. p.2: The MCS51 is memory constrained by the fact that |
---|
20 | it is an 8-bit microcontroller; but there would seem to be sufficient |
---|
21 | memory for the tasks it is expected to perform. This does not mean |
---|
22 | that the calculation of jumping instructions is not a worthy problem, |
---|
23 | but I question whether it is as critical as stated. |
---|
24 | |
---|
25 | f. p.6: "... markedly different ways": well, all of the instructions jump |
---|
26 | to one place or another, so they're not that different! |
---|
27 | |
---|
28 | 4. The paper talks about "costing" in the encompassing CerCo project, but |
---|
29 | few precise details are given. In particular, whenever "cost" is used in |
---|
30 | the paper, does it just refer to the number of cycles required to execute |
---|
31 | a sequence of instructions? If so, why use the more abstract term? |
---|
32 | |
---|
33 | 5. The paper does not mention the issue of placing assembler subroutines in |
---|
34 | memory? Is this not an issue? Could placement choices affect code size |
---|
35 | (from jump instructions) significantly? |
---|
36 | |
---|
37 | 7. p.5: It would be nice to see the type of the "preamble"; is it just a |
---|
38 | DATA section? |
---|
39 | |
---|
40 | 8. The paper does not discuss the complete tool chain. Does the verified |
---|
41 | development parse MCS51 assembler and spit out a binary image? |
---|
42 | |
---|
43 | 9. p.5: Why is "Word" and not "Identifier" or "nat" used to index psuedo |
---|
44 | instructions? Or maybe even a type synonym so there is no risk of |
---|
45 | confusion with the type used to index instructions. |
---|
46 | |
---|
47 | For instance, it would be nice if the statement "The function sigma maps |
---|
48 | pseudo program counters to program counters" were better reflected in the |
---|
49 | type of sigma. |
---|
50 | |
---|
51 | CSC: because the semantics is shared! |
---|
52 | |
---|
53 | 11. pp.7--9: this text talks about "program counters", when I think it |
---|
54 | means "addresses" (i.e., values that the program counter may take). |
---|
55 | |
---|
56 | 13. p.8: I didn't understand why it is sometimes necessary to force the |
---|
57 | expansion of jumps to the largest size possible. |
---|
58 | |
---|
59 | 15. The paper states that the work may be usable in the context of verified |
---|
60 | operating systems kernels. This is a point worth discussing, but the |
---|
61 | text could be more precise. The seL4 kernel requires memory protection |
---|
62 | but the MCS51 has no MMU. Furthermore, the verification was specific to |
---|
63 | the arm assembly language, where it would seem that the issue of branch |
---|
64 | displacement is less significant. |
---|
65 | |
---|
66 | Similarly, the paper discusses compilers like CompCert and the issue of |
---|
67 | well-formedness. Again, this is a worthy point, but the discussion seems |
---|
68 | to neglect the possibility that well formedness may be guaranteed by the |
---|
69 | conversion from the high-level language, i.e. that all C programs may |
---|
70 | compile into "well behaved" assembly programs. Is this true? |
---|
71 | |
---|
72 | 18. Research Questions |
---|
73 | |
---|
74 | a. Did you consider "running" your model in parallel with a real or |
---|
75 | emulated MCS-51 to validate its correctness? |
---|
76 | (as in the work of Peter Sewell et al's work on TCP/IP and memory |
---|
77 | weak models; where they compare their models against real |
---|
78 | implementations.) |
---|
79 | |
---|
80 | b. Rather than verifying a branch displacement algorithm, did you |
---|
81 | consider showing refinement between the input (assembler with labels) and |
---|
82 | the output (modified assembler with offsets)? That way, the algorithm |
---|
83 | could use whatever strategy it liked and the results would still be |
---|
84 | verified. From my understanding, this is one of the approaches taken |
---|
85 | in Xavier Leroy et al's CompCert project. |
---|
86 | |
---|
87 | x. Minor typos / issues |
---|
88 | |
---|
89 | c. p.4: It would be helpful if the abbreviated definitions of |
---|
90 | preinstruction, instruction, and pseudoinstruction included more |
---|
91 | elements in common with themselves and with the other examples |
---|
92 | (notably DEC). |
---|
93 | |
---|
94 | CSC: there is nothing in common; we could put MUL/DEC |
---|