1 |
6 |
jlechner |
; Operands
|
2 |
|
|
; Copyright (C) 2000, 2001, 2005, 2009 Red Hat, Inc.
|
3 |
|
|
; This file is part of CGEN.
|
4 |
|
|
; See file COPYING.CGEN for details.
|
5 |
|
|
|
6 |
|
|
; or other indexing mechanism. Operands are also how the semantic code refers
|
7 |
|
|
; to hardware elements.
|
8 |
|
|
; The `<operand>' class.
|
9 |
|
|
|
10 |
|
|
; ??? Need a new lighterweight version for instances in semantics.
|
11 |
|
|
; This should only contain the static elements from the description file.
|
12 |
|
|
;
|
13 |
|
|
; ??? Derived operands don't use all the current class members. Perhaps
|
14 |
|
|
; split <operand> into two.
|
15 |
|
|
; Name as used in semantic code.
|
16 |
|
|
; Generally this is the same as NAME. It is changed by the
|
17 |
|
|
|
18 |
|
|
; name in tracing output (most useful in memory operands).
|
19 |
|
|
; A more important reason is to help match semantic operands
|
20 |
|
|
; with function unit input/output arguments.
|
21 |
|
|
; Pretty name as used in tracing code.
|
22 |
|
|
; Generally this is the same as the hardware element's name.
|
23 |
|
|
; Semantic name of hardware element refered to by this operand.
|
24 |
|
|
; Hardware type of operand, a subclass of <hardware-base>.
|
25 |
|
|
; This is computed lazily from HW-NAME as many hardware
|
26 |
|
|
; elements can have the same semantic name. Applications
|
27 |
|
|
; that require a unique hardware element to be refered to are
|
28 |
|
|
; required to ensure duplicates are discarded (usually done
|
29 |
|
|
|
30 |
|
|
; FIXME: Rename to hw.
|
31 |
|
|
; Name of mode, as specified in description file.
|
32 |
|
|
; This needn't be the actual mode, as WI will get coerced
|
33 |
|
|
|
34 |
|
|
; The mode TYPE is being referenced in.
|
35 |
|
|
; This is also looked up lazily for the same reasons as TYPE.
|
36 |
|
|
|
37 |
|
|
; A number or #f used to select a variant of the hardware
|
38 |
|
|
; element. An example is ASI's on sparc.
|
39 |
|
|
; ??? I really need to be better at picking names.
|
40 |
|
|
; Index into type, class <hw-index>.
|
41 |
|
|
; For example in the case of an array of registers
|
42 |
|
|
; it can be an instruction field or in the case of a memory
|
43 |
|
|
; reference it can be a register operand (or general rtx).
|
44 |
|
|
; ??? At present <hw-index> is a facade over the real index
|
45 |
|
|
|
46 |
|
|
; Code to run when the operand is read or #f meaning pass
|
47 |
|
|
; the request on to the hardware object.
|
48 |
|
|
; Code to run when the operand is written or #f meaning pass
|
49 |
|
|
; the request on to the hardware object.
|
50 |
|
|
|
51 |
|
|
; Each entry maps an operation to its handler (which is up to
|
52 |
|
|
; the application but is generally a function name).
|
53 |
|
|
; Ordinal number of the operand in an insn's semantic
|
54 |
|
|
|
55 |
|
|
; where in the semantics the operand appears. An operand that
|
56 |
|
|
; is both read and written are given separate ordinal numbers
|
57 |
|
|
; (inputs are treated separately from outputs).
|
58 |
|
|
; Boolean indicating if the operand is conditionally
|
59 |
|
|
; referenced. #f means the operand is always referenced by
|
60 |
|
|
|
61 |
|
|
; whether (and by how much) this instance of the operand is
|
62 |
|
|
; delayed.
|
63 |
|
|
; The default make! assigns the default h/w selector.
|
64 |
|
|
; FIXME: The prefix field- doesn't seem right. Indices needn't be
|
65 |
|
|
; ifields, though for operands defined in .cpu files they usually are.
|
66 |
|
|
; Accessor fns
|
67 |
|
|
; FIXME: op:index should be named op:hwindex.
|
68 |
|
|
|
69 |
|
|
; FIXME: op:type should be named op:hwtype or some such.
|
70 |
|
|
"cannot resolve h/w reference"; Compute the operand's mode lazily (depends on hardware type which is
|
71 |
|
|
; computed lazily).
|
72 |
|
|
|
73 |
|
|
; Result is the <ifield> object or #f if there is none.
|
74 |
|
|
" op-ifield op= "", indx= ""\n"" ifld=""\n"; Return mode to use for index or #f if scalar.
|
75 |
|
|
; This can't use method-make-forward! as we need to call op:type to
|
76 |
|
|
|
77 |
|
|
; Return the operand's enum.
|
78 |
|
|
"@ARCH@_OPERAND_"; Return a boolean indicating if X is an operand.
|
79 |
|
|
; Default gen-pretty-name method.
|
80 |
|
|
; Return a C string of the name intended for users.
|
81 |
|
|
|
82 |
|
|
; FIXME: The current implementation is a quick hack. Parallel execution
|
83 |
|
|
; support can create operands with long names. e.g. h-memory-add-WI-src2-slo16
|
84 |
|
|
; The eventual way this will be handled is to record with each operand the
|
85 |
|
|
; entry number (or some such) in the operand instance table so that for
|
86 |
|
|
; registers we can compute the register's name.
|
87 |
|
|
"h-memory""memory""h-""\"""\""; PC support.
|
88 |
|
|
|
89 |
|
|
; hang a couple of methods.
|
90 |
|
|
; At the moment we only support one pc, a reasonable place to stop for now.
|
91 |
|
|
"program counter""make! of pc""cgen_operand"; handlers
|
92 |
|
|
; getter setter
|
93 |
|
|
|
94 |
|
|
; This must not call op:type. op:type will try to resolve a hardware
|
95 |
|
|
; element that may be multiply specified, and this is used in contexts
|
96 |
|
|
; where that's not possible.
|
97 |
|
|
; Mode support.
|
98 |
|
|
; Create a copy of operand OP in mode NEW-MODE-NAME.
|
99 |
|
|
; NOTE: Even if the mode isn't changing this creates a copy.
|
100 |
|
|
|
101 |
|
|
; (e.g. the behaviour of `object-copy-top').
|
102 |
|
|
|
103 |
|
|
; " class=" (object-class-name op)
|
104 |
|
|
; " hw-name=" (op:hw-name op)
|
105 |
|
|
; " mode=" (op:mode op)
|
106 |
|
|
; " newmode=" new-mode-name)
|
107 |
|
|
; temporary: for upward compatibility
|
108 |
|
|
; Mode isn't changing.
|
109 |
|
|
; See if new mode is supported by the hardware.
|
110 |
|
|
"op:new-mode: internal error, bad mode""op:new-mode""invalid mode for operand `""'"; Return #t if operand OP references its h/w element in its natural mode.
|
111 |
|
|
; Ifield support.
|
112 |
|
|
; Return list of ifields used by OP.
|
113 |
|
|
; else
|
114 |
|
|
; The `hw-index' class.
|
115 |
|
|
; [Was named `index' but that conflicts with the C library function and caused
|
116 |
|
|
; problems when using Hobbit. And `index' is too generic a name anyway.]
|
117 |
|
|
;
|
118 |
|
|
; An operand combines a hardware object with its index.
|
119 |
|
|
; e.g. in an array of registers an operand serves to combine the register bank
|
120 |
|
|
; with the instruction field that chooses which one.
|
121 |
|
|
; Hardware elements are accessed via other means as well besides instruction
|
122 |
|
|
|
123 |
|
|
; The `hw-index' class does that. It serves as a facade to the underlying
|
124 |
|
|
; details.
|
125 |
|
|
; ??? Not sure whether this is the best way to handle this or not.
|
126 |
|
|
|
127 |
|
|
; NAME is the name of the index or 'anonymous.
|
128 |
|
|
|
129 |
|
|
; structure member.
|
130 |
|
|
; TYPE is a symbol that indicates what VALUE is.
|
131 |
|
|
; scalar: the hardware object is a scalar, no index is required
|
132 |
|
|
; [MODE and VALUE are #f to denote "undefined" in this case]
|
133 |
|
|
; constant: a (non-negative) integer
|
134 |
|
|
; str-expr: a C expression as a string
|
135 |
|
|
; rtx: an rtx to be expanded
|
136 |
|
|
; ifield: an ifield object
|
137 |
|
|
; operand: an operand object
|
138 |
|
|
; ??? A useful simplification may be to always record the value as an rtx
|
139 |
|
|
; [which may require extensions to rtl so is deferred].
|
140 |
|
|
; ??? We could use runtime type identification, but doing things this way
|
141 |
|
|
; adds more structure.
|
142 |
|
|
;
|
143 |
|
|
; MODE is the mode of VALUE. If DFLT, mode must be obtained from VALUE.
|
144 |
|
|
; DFLT is only allowable for rtx and operand types.
|
145 |
|
|
; Accessors.
|
146 |
|
|
|
147 |
|
|
; Allow the mode to be specified by its name.
|
148 |
|
|
; get-name handler
|
149 |
|
|
|
150 |
|
|
; ??? Until other things settle.
|
151 |
|
|
; There only ever needs to be one of these objects, so create one.
|
152 |
|
|
; We can't use `make' here as the make! method calls mode:lookup which
|
153 |
|
|
; (a) doesn't exist if we're compiled with Hobbit and mode.scm isn't
|
154 |
|
|
; and (b) will fail anyway since #f isn't a valid mode.
|
155 |
|
|
; Placeholder for indices of "anyof" operands.
|
156 |
|
|
; There only needs to be one of these, so we create one and always use that.
|
157 |
|
|
; We can't use `make' here as the make! method calls mode:lookup which
|
158 |
|
|
; (a) doesn't exist if we're compiled with Hobbit and mode.scm isn't
|
159 |
|
|
; and (b) will fail anyway since #f isn't a valid mode.
|
160 |
|
|
; We can't use `make' here as the make! method calls mode:lookup which
|
161 |
|
|
; (a) doesn't exist if we're compiled with Hobbit and mode.scm isn't
|
162 |
|
|
; and (b) will fail anyway since #f isn't a valid mode.
|
163 |
|
|
|
164 |
|
|
;
|
165 |
|
|
; A hardware "selector" is like an index except is along an atypical axis
|
166 |
|
|
|
167 |
|
|
; What to pass to indicate "default selector".
|
168 |
|
|
; (??? value is temporary choice to be revisited).
|
169 |
|
|
; Hardware support.
|
170 |
|
|
; Return list of hardware elements refered to in OP-LIST
|
171 |
|
|
; with no duplicates.
|
172 |
|
|
; Build a list of hw elements.
|
173 |
|
|
; FIXME: hw-ref? is undefined
|
174 |
|
|
; Now build an alist of (name . obj) elements, take the nub, then the cdr.
|
175 |
|
|
; ??? These lists tend to be small so sorting first is probably overkill.
|
176 |
|
|
; Parsing support.
|
177 |
|
|
; Utility of -operand-parse-[gs]etter to build the expected syntax,
|
178 |
|
|
; for use in error messages.
|
179 |
|
|
"("" index"" newval""newval"""") (expression)"; Parse a getter spec.
|
180 |
|
|
; The syntax is (([index-names]) (... code ...)).
|
181 |
|
|
|
182 |
|
|
; {rank} is the required number of elements in {index-names}.
|
183 |
|
|
|
184 |
|
|
"invalid getter, should be ""invalid rtx expression"; Parse a setter spec.
|
185 |
|
|
; The syntax is (([index-names] newval) (... code ...)).
|
186 |
|
|
|
187 |
|
|
; {rank} is the required number of elements in {index-names}.
|
188 |
|
|
; use default
|
189 |
|
|
"invalid setter, should be ""invalid rtx expression"; Parse an operand definition.
|
190 |
|
|
; This is the main routine for building an operand object from a
|
191 |
|
|
; description in the .cpu file.
|
192 |
|
|
; All arguments are in raw (non-evaluated) form.
|
193 |
|
|
; The result is the parsed object or #f if object isn't for selected mach(s).
|
194 |
|
|
; ??? This only takes insn fields as the index. May need another proc (or an
|
195 |
|
|
; enhancement of this one) that takes other kinds of indices.
|
196 |
|
|
"Processing operand "" ...\n";; Pick out name first to augment the error context.
|
197 |
|
|
"cgen_operand""unknown mode""unknown insn field"; Disallow some obviously invalid numeric indices.
|
198 |
|
|
"invalid integer index"; Don't validate HW until we know whether this operand will be kept
|
199 |
|
|
; or not. If not, HW may have been discarded too.
|
200 |
|
|
"unknown hardware element"; At this point IFLD-VAL is either an integer or an <ifield> object.
|
201 |
|
|
|
202 |
|
|
; [well, actually we should be able to with a bit of work],
|
203 |
|
|
; we determine scalarness from the index.
|
204 |
|
|
; FIXME: constant -> const
|
205 |
|
|
|
206 |
|
|
; PCREL-ADDR, etc. An operand inherits the attributes of
|
207 |
|
|
; its field. They are overridable of course, which is why we use
|
208 |
|
|
; `atlist-append' here.
|
209 |
|
|
; note that this is the hw's name, not an object
|
210 |
|
|
|
211 |
|
|
"Ignoring "".\n"; Read an operand description.
|
212 |
|
|
|
213 |
|
|
; CONTEXT is a <context> object for error messages.
|
214 |
|
|
; ARG-LIST is an associative list of field name and field value.
|
215 |
|
|
; -operand-parse is invoked to create the <operand> object.
|
216 |
|
|
|
217 |
|
|
"invalid operand arg"; Now that we've identified the elements, build the object.
|
218 |
|
|
|
219 |
|
|
"define-operand"; Define an operand object, all arguments specified.
|
220 |
|
|
|
221 |
|
|
;
|
222 |
|
|
; Derived operands are used to implement operands more complex than just
|
223 |
|
|
; the mapping of an instruction field to a register bank. Their present
|
224 |
|
|
; raison d'etre is to create a new axis on which to implement the complex
|
225 |
|
|
; addressing modes of the i386 and m68k. The brute force way of describing
|
226 |
|
|
; these instruction sets would be to have one `dni' per addressing mode
|
227 |
|
|
; per instruction. What's needed is to abstract away the various addressing
|
228 |
|
|
; modes within something like operands.
|
229 |
|
|
|
230 |
|
|
; ??? While internally we end up with the "brute force" approach, in and of
|
231 |
|
|
; itself that's ok because it's an internal implementation issue.
|
232 |
|
|
; See <multi-insn>.
|
233 |
|
|
;
|
234 |
|
|
; ??? Another way to go is to have one dni per addressing mode. That seems
|
235 |
|
|
; less clean though as one dni would be any of add, sub, and, or, xor, etc.
|
236 |
|
|
;
|
237 |
|
|
; ??? Some addressing modes have side-effects (e.g. pre-dec, etc. like insns).
|
238 |
|
|
; This can be represented, but if two operands have side-effects special
|
239 |
|
|
; trickery may be required to get the order of side-effects right. Need to
|
240 |
|
|
; avoid any "trickery" at all.
|
241 |
|
|
;
|
242 |
|
|
; ??? Not yet handled are modelling parameters.
|
243 |
|
|
|
244 |
|
|
;
|
245 |
|
|
; ??? Division of class members b/w <operand> and <derived-operand> is wip.
|
246 |
|
|
; ??? As is potential introduction of other classes to properly organize
|
247 |
|
|
; things.
|
248 |
|
|
|
249 |
|
|
; Syntax string.
|
250 |
|
|
|
251 |
|
|
; ??? experiment
|
252 |
|
|
; <derived-ifield> object.
|
253 |
|
|
; Assertions of any ifield values or #f if none.
|
254 |
|
|
; "anyof" operands are subclassed from derived operands.
|
255 |
|
|
; They typically handle multiple addressing modes of CISC architectures.
|
256 |
|
|
; Base ifield, common to all choices.
|
257 |
|
|
; FIXME: wip
|
258 |
|
|
; List of <derived-operand> objects.
|
259 |
|
|
; ??? Maybe allow <operand>'s too?
|
260 |
|
|
; Set index to a special marker value.
|
261 |
|
|
; Derived/Anyof parsing support.
|
262 |
|
|
; Subroutine of -derived-operand-parse to parse the encoding.
|
263 |
|
|
; The result is a <derived-ifield> object.
|
264 |
|
|
; The {owner} member still needs to be set!
|
265 |
|
|
|
266 |
|
|
; It's an internal routine of some other file.
|
267 |
|
|
; (string-append "<derived-ifield> for " operand-name)
|
268 |
|
|
; owner
|
269 |
|
|
; subfields
|
270 |
|
|
|
271 |
|
|
; The ifield assertion is either () or an RTL expression asserting something
|
272 |
|
|
|
273 |
|
|
; Operands are specified by name, but what is used is their indices (there's
|
274 |
|
|
|
275 |
|
|
; FIXME: for now
|
276 |
|
|
; Parse a derived operand definition.
|
277 |
|
|
; This is the main routine for building a derived operand object from a
|
278 |
|
|
; description in the .cpu file.
|
279 |
|
|
|
280 |
|
|
; The result is the parsed object or #f if object isn't for selected mach(s).
|
281 |
|
|
;
|
282 |
|
|
; ??? Currently no support for handlers(,???) found in normal operands.
|
283 |
|
|
; Later, when necessary.
|
284 |
|
|
"Processing derived operand "" ...\n";; Pick out name first to augment the error context.
|
285 |
|
|
"cgen_operand""unknown mode""arg not a symbol""not an operand"; FIXME: validate
|
286 |
|
|
;(elm-set! result 'hw-name (obj:name parsed-encoding))
|
287 |
|
|
;(elm-set! result 'hw-name base-ifield)
|
288 |
|
|
; (elm-set! result 'index (hw-index-derived)) ; A temporary dummy
|
289 |
|
|
" new derived-operand; name= "", hw-name= "", index=""\n""Ignoring "".\n"; Read a derived operand description.
|
290 |
|
|
; This is the main routine for analyzing derived operands in the .cpu file.
|
291 |
|
|
; CONTEXT is a <context> object for error messages.
|
292 |
|
|
; ARG-LIST is an associative list of field name and field value.
|
293 |
|
|
; -derived-operand-parse is invoked to create the <derived-operand> object.
|
294 |
|
|
; use default mode of TYPE
|
295 |
|
|
"invalid derived-operand arg"; Now that we've identified the elements, build the object.
|
296 |
|
|
; Define a derived operand object, name/value pair list version.
|
297 |
|
|
"define-derived-operand"; Define a derived operand object, all arguments specified.
|
298 |
|
|
; ??? Not supported (yet).
|
299 |
|
|
;
|
300 |
|
|
;(define (define-full-derived-operand name comment attrs mode ...)
|
301 |
|
|
; (let ((op (-derived-operand-parse (make-current-context "define-full-derived-operand")
|
302 |
|
|
; name comment attrs
|
303 |
|
|
; mode ...)))
|
304 |
|
|
; (if op
|
305 |
|
|
; (current-op-add! op))
|
306 |
|
|
; op)
|
307 |
|
|
|
308 |
|
|
; Parse an "anyof" choice, which is a derived-operand name.
|
309 |
|
|
|
310 |
|
|
"anyof choice not a symbol""anyof choice not a derived-operand"; Parse an "anyof" derived operand.
|
311 |
|
|
; This is the main routine for building a derived operand object from a
|
312 |
|
|
; description in the .cpu file.
|
313 |
|
|
; All arguments are in raw (non-evaluated) form.
|
314 |
|
|
|
315 |
|
|
;
|
316 |
|
|
|
317 |
|
|
; Later, when necessary.
|
318 |
|
|
|
319 |
|
|
"cgen_operand""unknown mode""Ignoring "".\n"; Read an anyof operand description.
|
320 |
|
|
; This is the main routine for analyzing anyof operands in the .cpu file.
|
321 |
|
|
; CONTEXT is a <context> object for error messages.
|
322 |
|
|
; ARG-LIST is an associative list of field name and field value.
|
323 |
|
|
; -anyof-operand-parse is invoked to create the <anyof-operand> object.
|
324 |
|
|
; use default mode of TYPE
|
325 |
|
|
"invalid anyof-operand arg"; Now that we've identified the elements, build the object.
|
326 |
|
|
; Define an anyof operand object, name/value pair list version.
|
327 |
|
|
"define-anyof-operand"; Utilities to flatten out the <anyof-operand> derivation heirarchy.
|
328 |
|
|
; Utility class used when instantiating insns with derived operands.
|
329 |
|
|
|
330 |
|
|
; instantiated "anyof" operand.
|
331 |
|
|
; <anyof-operand> object we were instantiated from.
|
332 |
|
|
; Return initial list of known ifield values in {anyof-instance}.
|
333 |
|
|
; Return true if {anyof-instance} satisfies its ifield assertions.
|
334 |
|
|
; {known-values} is the {known} argument to rtx-solve.
|
335 |
|
|
; FIXME: context
|
336 |
|
|
; owner
|
337 |
|
|
; Subroutine of -anyof-merge-subchoices.
|
338 |
|
|
; Merge syntaxes of VALUE-NAMES/VALUES into SYNTAX.
|
339 |
|
|
;
|
340 |
|
|
; Example:
|
341 |
|
|
; If SYNTAX is "$a+$b", and VALUE-NAMES is (b), and VALUES is
|
342 |
|
|
; ("$c+$d"-object), then return "$a+$c+$d".
|
343 |
|
|
"Name "" not one of "; Subroutine of -anyof-merge-subchoices.
|
344 |
|
|
; Merge syntaxes of {value-names}/{values} into <derived-ifield> {encoding}.
|
345 |
|
|
; The result is a new <derived-ifield> object with subfields matching
|
346 |
|
|
; {value-names} replaced with {values}.
|
347 |
|
|
; {container} is the containing <anyof-operand>.
|
348 |
|
|
;
|
349 |
|
|
; Example:
|
350 |
|
|
; If {encoding} is (a-ifield-object b-anyof-ifield-object), and {value-names}
|
351 |
|
|
; is (b), and {values} is (c-choice-of-b-object), then return
|
352 |
|
|
; (a-ifield-object c-choice-of-b-ifield-object).
|
353 |
|
|
; Delete all the elements that are being replaced with ifields from
|
354 |
|
|
; {values} and add the new ifields.
|
355 |
|
|
; Subroutine of -anyof-merge-subchoices.
|
356 |
|
|
; Merge semantics of VALUE-NAMES/VALUES into GETTER.
|
357 |
|
|
;
|
358 |
|
|
; Example:
|
359 |
|
|
; If GETTER is (mem QI foo), and VALUE-NAMES is (foo), and VALUES is
|
360 |
|
|
; ((add a b)-object), then return (mem QI (add a b)).
|
361 |
|
|
|
362 |
|
|
; ??? This implementation is a quick hack, intended to evolve or be replaced.
|
363 |
|
|
|
364 |
|
|
; Subroutine of -anyof-merge-subchoices.
|
365 |
|
|
; Merge semantics of VALUE-NAMES/VALUES into SETTER.
|
366 |
|
|
;
|
367 |
|
|
; Example:
|
368 |
|
|
; If SETTER is (set (mem QI foo) newval), and VALUE-NAMES is (foo),
|
369 |
|
|
|
370 |
|
|
; (set (mem QI (add a b)) newval).
|
371 |
|
|
;
|
372 |
|
|
; ??? `newval' in this context is a reserved word.
|
373 |
|
|
;(debug-repl-env setter value-names values)
|
374 |
|
|
; ??? This implementation is a quick hack, intended to evolve or be replaced.
|
375 |
|
|
"-anyof-merge-setter: unsupported form"; Subroutine of -sub-insn-make!.
|
376 |
|
|
; Merge semantics of VALUE-NAMES/VALUES into SEMANTICS.
|
377 |
|
|
; Defined here and not in insn.scm to keep it with the getter/setter mergers.
|
378 |
|
|
;
|
379 |
|
|
; Example:
|
380 |
|
|
|
381 |
|
|
; ((add a b)-object), then return (mem QI (add a b)).
|
382 |
|
|
;(debug-repl-env semantics value-names values)
|
383 |
|
|
; ??? This implementation is a quick hack, intended to evolve or be replaced.
|
384 |
|
|
; (op:sem-name (list-ref values indx))
|
385 |
|
|
; pair? -> cheap non-null-list?
|
386 |
|
|
" merged semantics: [""] -> [""]\n"; Subroutine of -anyof-merge-subchoices.
|
387 |
|
|
|
388 |
|
|
;
|
389 |
|
|
; Example:
|
390 |
|
|
; If ASSERTION is (ne f-base-reg 5), and VALUE-NAMES is
|
391 |
|
|
; (foo), and VALUES is ((ne f-mod 0)), then return
|
392 |
|
|
; (andif (ne f-base-reg 5) (ne f-mod 0)).
|
393 |
|
|
;
|
394 |
|
|
; FIXME: Perform simplification pass, based on combined set of known
|
395 |
|
|
; ifield values.
|
396 |
|
|
|
397 |
|
|
; Return a copy of <derived-operand> CHOICE with NEW-ARGS from ANYOF-ARGS
|
398 |
|
|
; merged in. This is for when a derived operand is itself composed of
|
399 |
|
|
; anyof operands.
|
400 |
|
|
; ANYOF-ARGS is a list of <anyof-operand>'s to be replaced in CHOICE.
|
401 |
|
|
; NEW-ARGS is a corresponding list of values (<derived-operands>'s) of each
|
402 |
|
|
; element in ANYOF-ARGS.
|
403 |
|
|
; CONTAINER is the <anyof-operand> containing CHOICE.
|
404 |
|
|
; Creating the link from {encoding} to {result}.
|
405 |
|
|
; Subroutine of -anyof-all-choices-1.
|
406 |
|
|
; Return a list of all possible subchoices of <derived-operand> ANYOF-CHOICE,
|
407 |
|
|
; known to use <anyof-operand>'s itself.
|
408 |
|
|
; CONTAINER is the containing <anyof-operand>.
|
409 |
|
|
; Split args into anyof and non-anyof elements.
|
410 |
|
|
; Iterate over all combinations.
|
411 |
|
|
; {todo} is a list with one element for each anyof argument.
|
412 |
|
|
|
413 |
|
|
; <anyof-operand>. The result we want is every possible combination.
|
414 |
|
|
|
415 |
|
|
; If {todo} is ((1 2 3) (a) (B C)) the result we want is
|
416 |
|
|
; ((1 a B) (1 a C) (2 a B) (2 a C) (3 a B) (3 a C)).
|
417 |
|
|
;
|
418 |
|
|
; Note that some of these values may be derived from nested
|
419 |
|
|
; <anyof-operand>'s which is why we recursively call -anyof-all-choices-1.
|
420 |
|
|
; ??? -anyof-all-choices-1 should cache the results.
|
421 |
|
|
; ??? One might prefer a `do' loop here, but every time I see one I
|
422 |
|
|
; have to spend too long remembering its syntax.
|
423 |
|
|
;(display "new-args: " (current-error-port))
|
424 |
|
|
;(display (map obj:name new-args) (current-error-port))
|
425 |
|
|
;(newline (current-error-port))
|
426 |
|
|
|
427 |
|
|
; choice of {anyof-operand}.
|
428 |
|
|
; Creating the link from {encoding} to {result}.
|
429 |
|
|
|
430 |
|
|
; ANYOF-OPERAND.
|
431 |
|
|
;
|
432 |
|
|
; One could move this up into the cpu description file using pmacros.
|
433 |
|
|
; However, that's not the right way to go. How we currently implement
|
434 |
|
|
; the notion of derived operands is separate from the notion of having them
|
435 |
|
|
; in the description language. pmacros are not "in" the language (to the
|
436 |
|
|
; extent that the cpu description file reader "sees" them), they live
|
437 |
|
|
; above it. And the right way to do this is with something "in" the language.
|
438 |
|
|
; Derived operands are the first cut at it. They'll evolve or be replaced
|
439 |
|
|
; (and it's the implementation of them that will evolve first).
|
440 |
|
|
; For each choice, scan the operands for further derived operands.
|
441 |
|
|
|
442 |
|
|
; If not found, create an <anyof-instance> object for it. This is
|
443 |
|
|
; basically just a copy of the object, but {anyof-operand} is recorded
|
444 |
|
|
; with it so that we can later resolve `follows' specs.
|
445 |
|
|
; This operand has "anyof" operands so we need to turn this
|
446 |
|
|
; choice into a list of all possible subchoices.
|
447 |
|
|
; No <anyof-operand> arguments.
|
448 |
|
|
; Cover fn of -anyof-all-choices-1.
|
449 |
|
|
; Return list of <anyof-instance> objects, one for each possible variant of
|
450 |
|
|
; ANYOF-OPERAND.
|
451 |
|
|
; We want to delete choices that fail their ifield assertions, but since
|
452 |
|
|
; -anyof-all-choices-1 can recursively call itself, assertion checking is
|
453 |
|
|
|
454 |
|
|
; Delete ones that fail their ifield assertions.
|
455 |
|
|
; Sometimes there isn't enough information yet to completely do this.
|
456 |
|
|
; When that happens it is the caller's responsibility to deal with it.
|
457 |
|
|
; However, it is our responsibility to assert as much as we can.
|
458 |
|
|
|
459 |
|
|
; Look up operand NAME in the operand table.
|
460 |
|
|
; This proc isolates the strategy we use to record operand objects.
|
461 |
|
|
; Look up an operand via SEM-NAME.
|
462 |
|
|
|
463 |
|
|
; Note that the field isn't necessarily contiguous.
|
464 |
|
|
|
465 |
|
|
; Note that the field isn't necessarily contiguous.
|
466 |
|
|
|
467 |
|
|
; Return a sorted list of operand lists.
|
468 |
|
|
; Each element in the inner list is an operand with the same name, but for
|
469 |
|
|
|
470 |
|
|
; The outer list is sorted by name.
|
471 |
|
|
; We assume there is at least one operand.
|
472 |
|
|
"op-sort: no operands!"; First sort by name.
|
473 |
|
|
; Current set of operands with same name.
|
474 |
|
|
; Reverse things to keep them in file order (minimizes random
|
475 |
|
|
; changes in generated files).
|
476 |
|
|
; Not done. Check for new set.
|
477 |
|
|
; FIXME: Not used anymore but leave in for now.
|
478 |
|
|
; Objects used in assembler syntax ($0, $1, ...).
|
479 |
|
|
;
|
480 |
|
|
;(define <syntax-operand>
|
481 |
|
|
; (class-make '<syntax-operand> nil '(number value) nil))
|
482 |
|
|
;(method-make-make! <syntax-operand> '(number))
|
483 |
|
|
|
484 |
|
|
;(define $0 (make <syntax-operand> 0))
|
485 |
|
|
|
486 |
|
|
;(define $2 (make <syntax-operand> 2))
|
487 |
|
|
;(define $3 (make <syntax-operand> 3))
|
488 |
|
|
|
489 |
|
|
; Builtins.
|
490 |
|
|
; The pc operand used in rtl expressions.
|
491 |
|
|
; Called before reading a .cpu file in.
|
492 |
|
|
"\
|
493 |
|
|
Define an operand, name/value pair list version.
|
494 |
|
|
""\
|
495 |
|
|
Define an operand, all arguments specified.
|
496 |
|
|
""\
|
497 |
|
|
Define a derived operand, name/value pair list version.
|
498 |
|
|
""\
|
499 |
|
|
Define an anyof operand, name/value pair list version.
|
500 |
|
|
|
501 |
|
|
; Standard operand attributes.
|
502 |
|
|
; ??? Some of these can be combined into one.
|
503 |
|
|
"value is negative"; Operand plays a part in RELAXABLE/RELAXED insns.
|
504 |
|
|
"operand is the relax participant"; ??? Might be able to make SEM-ONLY go away (or machine compute it)
|
505 |
|
|
|
506 |
|
|
"operand is for semantic use only"; Also (defined elsewhere): PCREL-ADDR ABS-ADDR.
|
507 |
|
|
; Called after a .cpu file has been read in.
|
508 |
|
|
|