1 |
6 |
jlechner |
; Standard RTL functions.
|
2 |
|
|
; Copyright (C) 2000, 2009 Red Hat, Inc.
|
3 |
|
|
; This file is part of CGEN.
|
4 |
|
|
; See file COPYING.CGEN for details.
|
5 |
|
|
|
6 |
|
|
;
|
7 |
|
|
; It is ok for this file to use procs "internal" to rtl.scm.
|
8 |
|
|
;
|
9 |
|
|
; Each rtx functions has two leading operands: &options, &mode;
|
10 |
|
|
; though `&mode' may be spelled differently.
|
11 |
|
|
; The "&" prefix is to indicate that the parsing of these operands is handled
|
12 |
|
|
; differently. They are optional and are written with leading colons
|
13 |
|
|
; (e.g. :SI). The leading ":" is to help the parser - all leading optional
|
14 |
|
|
; operands begin with ":". The order of the arguments is &options then &mode
|
15 |
|
|
; though there is no imposed order in written RTL.
|
16 |
|
|
; Do not change the indentation here.
|
17 |
|
|
|
18 |
|
|
; The reason for the odd indenting above is so that emacs begins indenting the
|
19 |
|
|
|
20 |
|
|
; Error reporting.
|
21 |
|
|
; MODE is present for use in situations like non-VOID mode cond's.
|
22 |
|
|
"error in rtl"; Enums
|
23 |
|
|
; Default mode is INT.
|
24 |
|
|
; When computing a value, return the enum's value.
|
25 |
|
|
; Instruction fields
|
26 |
|
|
; These are used in the encode/decode specs of other ifields as well as in
|
27 |
|
|
; instruction semantics.
|
28 |
|
|
; Ifields are normally specified by name, but they are subsequently wrapped
|
29 |
|
|
|
30 |
|
|
" used as operand"; Specify an operand.
|
31 |
|
|
; Operands are normally specified by name, but they are subsequently wrapped
|
32 |
|
|
|
33 |
|
|
; Operand naming/numbering.
|
34 |
|
|
; Operands are given names so that the operands as used in the semantics can
|
35 |
|
|
|
36 |
|
|
; operands and function unit arguments, this is rarely necessary, but
|
37 |
|
|
; sometimes it is.
|
38 |
|
|
;
|
39 |
|
|
; ??? This obfuscates the semantic code a fair bit. Another way to do this
|
40 |
|
|
; would be to add new elements to <insn> to specify operands outside of
|
41 |
|
|
|
42 |
|
|
; (define-insn ...
|
43 |
|
|
; (inputs (in-gr1 src1) (in-gr2 src2))
|
44 |
|
|
|
45 |
|
|
; ...)
|
46 |
|
|
; The intent here is to continue to allow the semantic code to use names
|
47 |
|
|
; of operands, and not overly complicate the input/output description.
|
48 |
|
|
;
|
49 |
|
|
; In instructions, operand numbers are recorded as well, to implement
|
50 |
|
|
; profiling and result writeback of parallel insns.
|
51 |
|
|
|
52 |
|
|
; VALUE is an expression whose result is an object of type <operand>.
|
53 |
|
|
; It can be the name of an existing operand.
|
54 |
|
|
; ??? Might also support numbering by allowing NEW-NAME to be a number.
|
55 |
|
|
; Operands are generally compiled to an internal form first.
|
56 |
|
|
; There is a fair bit of state associated with them, and it's easier to
|
57 |
|
|
|
58 |
|
|
; it expresses all the state].
|
59 |
|
|
; Compiled operands are wrapped in this so that they still look like rtx.
|
60 |
|
|
;(dron (opspec: &options &mode op-name op-num hw-ref attrs)
|
61 |
|
|
; (OPTIONS ANYMODE SYMBOL NUMBER RTX ATTRS) (NA NA NA NA ANY NA)
|
62 |
|
|
; ARG
|
63 |
|
|
; (let ((opval (rtx-eval-with-estate hw-ref mode *estate*)))
|
64 |
|
|
; (assert (operand? opval))
|
65 |
|
|
; ; Set the specified mode, ensuring it's ok.
|
66 |
|
|
; ; This also makes a copy as we don't want to modify predefined
|
67 |
|
|
; ; operands.
|
68 |
|
|
; (let ((operand (op:new-mode opval mode)))
|
69 |
|
|
; (op:set-sem-name! operand op-name)
|
70 |
|
|
; (op:set-num! operand op-num)
|
71 |
|
|
|
72 |
|
|
; operand))
|
73 |
|
|
;)
|
74 |
|
|
; Specify a reference to a local variable.
|
75 |
|
|
|
76 |
|
|
; wrapped in this.
|
77 |
|
|
; FIXME: This doesn't work. See s-operand.
|
78 |
|
|
;(define (s-dup estate op-name)
|
79 |
|
|
; (if (not (insn? (estate-owner estate)))
|
80 |
|
|
; (error "dup: not processing an insn"))
|
81 |
|
|
|
82 |
|
|
; (op:lookup-num (insn:operands (estate-owner estate)) op-name))
|
83 |
|
|
;)
|
84 |
|
|
;
|
85 |
|
|
; ??? Since operands are given names and not numbers this isn't currently used.
|
86 |
|
|
;
|
87 |
|
|
;(drsn (dup &options &mode op-name)
|
88 |
|
|
; (OPTIONS DFLTMODE SYMBOL) (NA NA NA)
|
89 |
|
|
; ;(s-dup *estate* op-name)
|
90 |
|
|
; (begin
|
91 |
|
|
; (if (not (insn? (estate-owner *estate*)))
|
92 |
|
|
; (error "dup: not processing an insn"))
|
93 |
|
|
; (vector-ref (insn:operands (estate-owner *estate*))
|
94 |
|
|
; (op:lookup-num (insn:operands (estate-owner *estate*)) op-name)))
|
95 |
|
|
; #f
|
96 |
|
|
;)
|
97 |
|
|
; Returns non-zero if operand NAME was referenced (read if input operand
|
98 |
|
|
; and written if output operand).
|
99 |
|
|
; ??? What about input/output operands.
|
100 |
|
|
|
101 |
|
|
; For registers this is the register number.
|
102 |
|
|
; ??? Mode handling incomplete.
|
103 |
|
|
; (send (op:type op) 'get-index-mode)
|
104 |
|
|
; Same as index-of, but improves readability for registers.
|
105 |
|
|
|
106 |
|
|
; Describe a random hardware object.
|
107 |
|
|
; If INDX is missing, assume the element is a scalar. We pass 0 so s-hw
|
108 |
|
|
; doesn't have to unpack the list that would be passed if it were defined as
|
109 |
|
|
; (hw mode hw-name . indx). This is an internal implementation detail
|
110 |
|
|
; and thus harmless to the description language.
|
111 |
|
|
; These are implemented as syntax nodes as we must pass INDX to `s-hw'
|
112 |
|
|
; unevaluated.
|
113 |
|
|
|
114 |
|
|
;(drsn (hw &options &mode hw-elm . indx-sel)
|
115 |
|
|
; (OPTIONS ANYMODE SYMBOL . RTX) (NA NA NA . INT)
|
116 |
|
|
; ARG
|
117 |
|
|
; (let ((indx (if (pair? indx-sel) (car indx-sel) 0))
|
118 |
|
|
; (selector (if (and (pair? indx-sel) (pair? (cdr indx-sel)))
|
119 |
|
|
|
120 |
|
|
; hw-selector-default))))
|
121 |
|
|
; (s-hw *estate* mode hw-elm indx selector)
|
122 |
|
|
;)
|
123 |
|
|
; Register accesses.
|
124 |
|
|
; INDX-SEL is an optional index and possible selector.
|
125 |
|
|
|
126 |
|
|
; getter/setter definitions.
|
127 |
|
|
; Memory accesses.
|
128 |
|
|
; Instruction execution support.
|
129 |
|
|
; There are no jumps, per se. A jump is a set of `pc'.
|
130 |
|
|
; The program counter.
|
131 |
|
|
; ??? Hmmm... needed? The pc is usually specified as `pc' which is shorthand
|
132 |
|
|
; for (operand pc).
|
133 |
|
|
; Fetch bytes from the instruction stream of size MODE.
|
134 |
|
|
; FIXME: Later need to augment this by passing an indicator to the mem-fetch
|
135 |
|
|
; routines that we're doing an ifetch.
|
136 |
|
|
; ??? wip!
|
137 |
|
|
; hw-selector-ispace
|
138 |
|
|
; NUM is the instruction number. Generally it is zero but if more than one
|
139 |
|
|
; insn is decoded at a time, it is non-zero. This is used, for example, to
|
140 |
|
|
|
141 |
|
|
; ??? wip!
|
142 |
|
|
; NUM is the same number passed to `decode'.
|
143 |
|
|
; ??? wip!
|
144 |
|
|
|
145 |
|
|
; Sets of pc are handled like other sets so there are no branch rtx's.
|
146 |
|
|
; Indicate there are N delay slots in the processing of RTX.
|
147 |
|
|
; N is a `const' node.
|
148 |
|
|
; ??? wip!
|
149 |
|
|
; (s-sequence *estate* VOID '() rtx) ; wip!
|
150 |
|
|
|
151 |
|
|
; PC is the address of the annuling insn.
|
152 |
|
|
; The target is required to define SEM_ANNUL_INSN.
|
153 |
|
|
; ??? wip!
|
154 |
|
|
; The pc reference here is hidden in c-code to not generate a spurious
|
155 |
|
|
; pc input operand.
|
156 |
|
|
"SEM_ANNUL_INSN""pc"; Skip the following insn if YES? is non-zero.
|
157 |
|
|
; The target is required to define SEM_SKIP_INSN.
|
158 |
|
|
; ??? This is similar to annul. Deletion of one of them defered.
|
159 |
|
|
; ??? wip!
|
160 |
|
|
; Attribute support.
|
161 |
|
|
; Return a boolean indicating if attribute named ATTR is VALUE in OWNER.
|
162 |
|
|
; If VALUE is a list, return "true" if ATTR is any of the listed values.
|
163 |
|
|
; ??? Don't yet support !VALUE.
|
164 |
|
|
; OWNER is the result of either (current-insn) or (current-mach)
|
165 |
|
|
; [note that canonicalization will turn them into
|
166 |
|
|
; (current-{insn,mach} () DFLT)].
|
167 |
|
|
; The result is always of mode INT.
|
168 |
|
|
; FIXME: wip
|
169 |
|
|
;
|
170 |
|
|
; This is a syntax node so the args are not pre-evaluated.
|
171 |
|
|
|
172 |
|
|
; FIXME: Hmmm... it currently isn't a syntax node.
|
173 |
|
|
; Get the value of attribute ATTR-NAME.
|
174 |
|
|
; OBJ is the result of either (current-insn) or (current-mach)
|
175 |
|
|
|
176 |
|
|
; (current-{insn,mach} () DFLT)].
|
177 |
|
|
; FIXME:wip
|
178 |
|
|
; Same as `quote', for use in attributes cus "quote" sounds too jargonish.
|
179 |
|
|
; [Ok, not a strong argument for using "symbol", but so what?]
|
180 |
|
|
; Return the current instruction.
|
181 |
|
|
|
182 |
|
|
; This can either be a compile-time or run-time value.
|
183 |
|
|
; Constants.
|
184 |
|
|
; FIXME: Need to consider 64 bit hosts.
|
185 |
|
|
|
186 |
|
|
; Large mode support.
|
187 |
|
|
; Combine smaller modes into a larger one.
|
188 |
|
|
; Arguments are specified most significant to least significant.
|
189 |
|
|
; ??? May also want an endian dependent argument order. That can be
|
190 |
|
|
; implemented on top of or beside this.
|
191 |
|
|
; ??? Not all of the combinations are supported in the simulator.
|
192 |
|
|
; They'll get added as necessary.
|
193 |
|
|
; FIXME: Ensure correct number of args for in/out modes.
|
194 |
|
|
; FIXME: Ensure compatible modes.
|
195 |
|
|
; GCC's subreg.
|
196 |
|
|
; Called subword 'cus it's not exactly subreg.
|
197 |
|
|
; Word numbering is from most significant (word 0) to least (word N-1).
|
198 |
|
|
; ??? May also want an endian dependent word ordering. That can be
|
199 |
|
|
; implemented on top of or beside this.
|
200 |
|
|
; ??? GCC plans to switch to SUBREG_BYTE. Keep an eye out for the switch
|
201 |
|
|
; (which is extensive so probably won't happen anytime soon).
|
202 |
|
|
;
|
203 |
|
|
; The mode spec of operand0 use to be OP0, but subword is not a normal rtx.
|
204 |
|
|
; The mode of operand0 is not necessarily the same as the mode of the result,
|
205 |
|
|
|
206 |
|
|
; `&mode') for the mode of operand0.
|
207 |
|
|
|
208 |
|
|
; What's there now is just "thoughts put down on paper."
|
209 |
|
|
; FIXME: Ensure compatible modes
|
210 |
|
|
;(list 'c-raw-call 'BLK (string-append "SPLIT" in-mode split-mode) di)
|
211 |
|
|
|
212 |
|
|
; (= (length modes) (length (cons arg1 arg-rest))).
|
213 |
|
|
|
214 |
|
|
; Support for explicit C code.
|
215 |
|
|
; ??? GCC RTL calls this "unspec" which is arguably a more application
|
216 |
|
|
; independent name.
|
217 |
|
|
; Invoke C functions passing them arguments from the semantic code.
|
218 |
|
|
; The arguments are passed as is, no conversion is done here.
|
219 |
|
|
; Usage is:
|
220 |
|
|
; (c-call mode name arg1 arg2 ...)
|
221 |
|
|
; which is converted into a C function call:
|
222 |
|
|
; name (current_cpu, arg1, arg2, ...)
|
223 |
|
|
; Mode is the mode of the result.
|
224 |
|
|
; If it is VOID this call is a statement and ';' is appended.
|
225 |
|
|
; Otherwise it is part of an expression.
|
226 |
|
|
; Same as c-call but without implicit first arg of `current_cpu'.
|
227 |
|
|
; Set/get/miscellaneous
|
228 |
|
|
; Clobber - mark an object as modified without explaining why or how.
|
229 |
|
|
; The `set' rtx.
|
230 |
|
|
; MODE is the mode of DST. If DFLT, use DST's default mode.
|
231 |
|
|
|
232 |
|
|
;
|
233 |
|
|
; ??? It might be more consistent to rename set -> set-trace, but that's
|
234 |
|
|
; too wordy. The `set' rtx is the normal one and we want the normal one to
|
235 |
|
|
; be the verbose one (prints result tracing messages). `set-quiet' is the
|
236 |
|
|
; atypical one, it doesn't print tracing messages. It may also turn out that
|
237 |
|
|
; a different mechanism (rather than the name "set-quiet") is used some day.
|
238 |
|
|
; One way would be to record the "quietness" state with the traversal state and
|
239 |
|
|
; use something like (with-quiet (set foo bar)) akin to with-output-to-string
|
240 |
|
|
; in Guile.
|
241 |
|
|
;
|
242 |
|
|
; i.e. set -> gen-set-trace
|
243 |
|
|
|
244 |
|
|
;
|
245 |
|
|
; ??? One might want a `!' suffix as in `set!', but methinks that's following
|
246 |
|
|
|
247 |
|
|
; Standard arithmetic operations.
|
248 |
|
|
; It's nice emitting macro calls to the actual C operation in that the RTX
|
249 |
|
|
; expression is preserved, albeit in C. On the one hand it's one extra thing
|
250 |
|
|
; the programmer has to know when looking at the code. But on the other it's
|
251 |
|
|
; trivial stuff, and having a layer between RTX and C allows the
|
252 |
|
|
; macros/functions to be modified to handle unexpected situations.
|
253 |
|
|
;
|
254 |
|
|
; We do emit C directly for cases other than cpu semantics
|
255 |
|
|
; (e.g. the assembler).
|
256 |
|
|
;
|
257 |
|
|
; The language is defined such that we assume ANSI C semantics while avoiding
|
258 |
|
|
|
259 |
|
|
;
|
260 |
|
|
; Current exceptions:
|
261 |
|
|
; - signed shift right assumes the sign bit is replicated.
|
262 |
|
|
;
|
263 |
|
|
; Additional notes [perhaps repeating what's in ANSI C for emphasis]:
|
264 |
|
|
; - callers of division and modulus fns must test for 0 beforehand
|
265 |
|
|
; if necessary
|
266 |
|
|
|
267 |
|
|
; [yes I know the C standard says implementation defined, here its
|
268 |
|
|
; unspecified]
|
269 |
|
|
|
270 |
|
|
; - signedness is part of the rtx operation name, and is not determined
|
271 |
|
|
; from the arguments [elsewhere is a description of the tradeoffs]
|
272 |
|
|
; - ???
|
273 |
|
|
; For integer values this is a bitwise operation (each bit inverted).
|
274 |
|
|
|
275 |
|
|
; ??? Might want different names.
|
276 |
|
|
; This is a boolean operation.
|
277 |
|
|
; MODE is the mode of S1. The result always has mode BI.
|
278 |
|
|
; ??? Perhaps `mode' shouldn't be here.
|
279 |
|
|
|
280 |
|
|
; "s3" here must have type BI.
|
281 |
|
|
; For the *flag rtx's, MODE is the mode of S1,S2; the result always has
|
282 |
|
|
; mode BI.
|
283 |
|
|
|
284 |
|
|
; Usurp these names so that we have consistent rtl should a program generator
|
285 |
|
|
; ever want to infer more about what the semantics are doing.
|
286 |
|
|
; For now these are just macros that expand to real rtl to perform the
|
287 |
|
|
; operation.
|
288 |
|
|
|
289 |
|
|
; mode value)
|
290 |
|
|
; mode missing?
|
291 |
|
|
; Return bit indicating if VALUE is negative/non-negative.
|
292 |
|
|
|
293 |
|
|
; mode missing?
|
294 |
|
|
; Multiply/divide.
|
295 |
|
|
|
296 |
|
|
; ??? Need two variants, one that avoids implementation defined situations
|
297 |
|
|
; [both host and target], and one that specifies implementation defined
|
298 |
|
|
; situations [target].
|
299 |
|
|
|
300 |
|
|
; various floating point routines
|
301 |
|
|
|
302 |
|
|
; These are bitwise operations.
|
303 |
|
|
|
304 |
|
|
; ??? In non-sim case, ensure s1 is in right C type for right result.
|
305 |
|
|
; Rotates don't really have a sign, so doesn't matter what we say.
|
306 |
|
|
; ??? Will also need rotate-with-carry [duh...].
|
307 |
|
|
|
308 |
|
|
; The result always has mode BI.
|
309 |
|
|
; ??? 'twould be more Schemey to take a variable number of args.
|
310 |
|
|
; ??? 'twould also simplify several .cpu description entries.
|
311 |
|
|
; On the other hand, handling an arbitrary number of args isn't supported by
|
312 |
|
|
; ISA's, which the main goal of what we're trying to represent.
|
313 |
|
|
|
314 |
|
|
; IF?
|
315 |
|
|
; `bitfield' is an experimental operation.
|
316 |
|
|
; It's not really needed but it might help simplify some things.
|
317 |
|
|
;
|
318 |
|
|
|
319 |
|
|
; ...
|
320 |
|
|
; ...
|
321 |
|
|
;)
|
322 |
|
|
; Conversions.
|
323 |
|
|
; Comparisons.
|
324 |
|
|
|
325 |
|
|
; ??? In non-sim case, ensure s1,s2 is in right C type for right result.
|
326 |
|
|
; ??? In non-sim case, ensure s1,s2 is in right C type for right result.
|
327 |
|
|
; Set membership.
|
328 |
|
|
; Useful in ifield assertions.
|
329 |
|
|
|
330 |
|
|
; VALUE is any constant rtx. SET is a `number-list' rtx.
|
331 |
|
|
"`member rtx'""value is not a constant""`member' rtx""set is not a `number-list' rtx"; Conditional execution.
|
332 |
|
|
; FIXME: make syntax node?
|
333 |
|
|
; ??? The syntax here isn't quite that of Scheme. A condition must be
|
334 |
|
|
; followed by a result expression.
|
335 |
|
|
|
336 |
|
|
; the same mode as the result.
|
337 |
|
|
|
338 |
|
|
; the same mode as the result.
|
339 |
|
|
; parallel, sequence, do-count
|
340 |
|
|
; This has to be a syntax node as we don't want EXPRS to be pre-evaluated.
|
341 |
|
|
; All semantic ops must have a mode, though here it must be VOID.
|
342 |
|
|
; IGNORE is for consistency with sequence. ??? Delete some day.
|
343 |
|
|
; ??? There's no real need for mode either, but convention requires it.
|
344 |
|
|
; This has to be a syntax node to handle locals properly: they're not defined
|
345 |
|
|
; yet and thus pre-evaluating the expressions doesn't work.
|
346 |
|
|
; ??? This should create a closure.
|
347 |
|
|
; This has to be a syntax node to handle iter-var properly: it's not defined
|
348 |
|
|
; yet and thus pre-evaluating the expressions doesn't work.
|
349 |
|
|
; Internal rtx to create a closure.
|
350 |
|
|
|
351 |
|
|
; End of def-rtx-funcs
|
352 |
|
|
|