This repository has been archived by the owner on Sep 10, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 20
/
LAUNDRY
140 lines (109 loc) · 6.08 KB
/
LAUNDRY
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
* The conversion from and to a Bits.bits value is under specified.
* We suspect an impedance mismatch between various representations of
link-time constants. Observation #1: an RTL is built with a
Reladdr.symbol, not a full Reladdr.t. It is unclear to us which is
better.
* To emit assembly language, the recognizer must see an entire
link-time expression at the RTL level and convert it to a
relocatable address. The choice of using Reladdr.symbol puts
the entire burden on the recognizer to find the larger
relocatable address of which the symbol is a part.
Reladdr.t has few clients. Rtleval.eval can create one from
source. Assemblers can use a Reladdr.t in an address-emission
procedure.
* Assuming we have an implementation of Sparc.S that properly uses the
sub-module Reloc : Sledlib.RELOCATABLE, we know how to write BURG
rules that properly emit instructions that use *symbols* (as opposed
to full-blown Reladdr.t):
PC := reloc {: Sparc.ba reloc :}
PC := address {: Sparc.jmp address :}
reloc : symbol {: Sparc.Reloc.late ... :}
reloc : const {: Sparc.Reloc.early ... :}
address : symbol {: special hand-crafted instruction seq
involving sethi and ori (really Sparc.set) :}
There are some mismatches in the details, but we believe the general
outlines are right. It's possible one wants an intermediate
abstraction over the Sparc.Reloc.t
Tentatively we might proceed with this plan and avoid Reladdr.t
* We need escape analysis for continuations. Should have an entry node
to escaping continuations that are otherwise not mentioned?
* Elab does not check the names of calling conventions. Calling
conventions are target dependet, but elab currently does not know
about the target. Any problem with calling conventions are thus
detected later in ast3ir.
* RTL-operators are defined in Rtlop. More precisely, this module
defines types and compile-time implementations of operators. The types
are universal because the type of an implementation is independent
from its implementation. What is the excact connection to Bitops? We
also have to clarify the connection between RTL operators and C--
operators, which are less polymorphic.
* The check of the static semantics does not detect when a link-time
expression uses an operator that is not available at link-time. The
probem is only detected in the [[Ast3ir]] module. One problem is, that
link-time expressions could be target specfic.
* The compiler reserves global memory for global registers. This must be
only by one compilation unit and all others must import the
corresponding symbol. We thus need a flag (-main ?) that tells whether
the memory should be reserved or not.
* Cfg3: transaction-based interface: which operations should be
protected by transactions?
* The implementation of cutto currently lacks all details to find the
activation for the continuation and thus the \emph{incoming} area in
that activations. This is where the [[cut to]] statement puts the
\emph{outgoing} overflow parameters. Some abstraction for a
continuation's runt-time representation, similar to [[Automaton.loc]]
might be appropriate. --CL
* Register.spill/reload needs a review. The RTLs produced may not
respect the machine invariant. Should these functions be moved into
Target.t? Another way would be to pass a code-expander into these
functions.
* We need a uniform way to handle errors after the type-checking phase.
Should we use Error.ErrorExn for this and catch it simply in Driver?
* Error reporting for checked run-time errors is very fractured: I
like to use assert false because if it is raised it includes a
source code position. Some functions use Impossible.impossible
which raises an exception. Tracking the cause of such a location
requires the debugger and backward execution. Another possibility
would be to raise the standard exception Invalid_argument. The
problem of tracking its cause remains the same.
* Spilling hardware registers is not save: if [[spillee]] is a
hardware register, it is re-loaded into a new temporary that
substitutes the hardware register in nodes. However, the hardware
register might the there because a calling convention demands it.
This applies to the Linear Scan Allocator; I'm not sure what the
coloring allocator does.
* I don't know how to find the data-flow annotations/nodes for continuations.
* Since evaluation and type-checking of expressions are separated,
types in nested expressions are checked multiple times. This
introduces a quadratic complexity. The only way to avoid this, as
far as I can see, is a combined bottom-up evaluation and type
checking. --CL
* Does the {\rtl} used for the return depend on $(x,y)$. I believe
so and this means the [[Target]] interface should be changed. --CL
* Expcheck provides code to check the static semantics of an
expression and rtleval code to evaluate a constant. However, elab
does not use this code for constants. I do not remeber why except
that error messages are less precises when expcheck/rtleval are used.
--CL
* Rtleval provides evaluation for constant RTL compile-time and
link-time expressions. The implementation for link-time
expressions is missing.
* look up IEEE 754 floating-point codes and get rid of the worst unimps
in bitops.nw.
* asdlGen:
module m {
foo = (int)
bar = Bar (foo)
}
When a view maps foo to char the M.bar type becomes Bar of char, but
M.foo is still int.
* Implement charset, character, and string handling as proposed by NR
in the changes file. The current handling of characters and
strings must be replaced.
* When a litarl value is scanned (into a Bits.bits) value its width is
unknown. The width cannot be processed in the scanner because it can
be a symbolic value that the scanner cannot know. I consider this
today a design flaw of the language. A possible solution is to store
the string in the AST until the width is known. Once it is known, the
value is stored inside the symbol table. -- CL
intot