hexagon/idef-parser/README.rst

18    A2_add(RdV, in RsV, in RtV) {
46 with a unique identifier, in this case ``A2_add``, which allows to distinguish
48 instruction belongs, in this case ``A2`` corresponds to the Hexagon
53 with ``in`` are already initialized, while the others are output parameters.
57 -  Fill in the output function signature with the correct TCGv registers
58 -  Fill in the output function signature with the immediate integers
62 Let's now observe the actual instruction description code, in this case:
69 application of some macro definitions contained in the ``macros.h`` file.
76 declared by the declaration statements. In this case all the three registers
94 registers, storing the result in the just declared temporary.
100 The result of the addition is now stored in the temporary, we move it into the
109 instruction semantics in ``semantics_generated.pyinc`` that we need to consider.
116 which takes instruction semantics in ``semantics_generated.pyinc`` to C-like
118 ``J2_jumpr`` instruction which jumps to an address stored in a register
129 in ``semantics_generated.pyinc``. Running ``gen_idef_parser_funcs.py``
134     J2_jumpr(in RsV) {
141 These macros are defined in ``idef-parser/macros.h.inc`` and the step is
150     J2_jumpr(in RsV) {
155 signifying a write to the Program Counter ``PC``.  Note, that ``PC`` in
156 this expression is not a variable in the strict C sense since it is not
157 declared anywhere, but rather a symbol which is easy to match in
166 regular expression. The token description is contained in the
169 value in case of an immediate constant, and decorates the token with the
173 description contained in the ``idef-parser.y`` file. The generated parser
182 The tokens are mapped on the source language grammar, defined in the
204                  | IN REG
205                  | IN PRED
234     input register               in RsV
235     input predicate register     in P0
248 Allowed in the input code are C language expressions with a few exceptions
261 macros present in ``macros.h``. As an example, consider the ``fABS`` macro which
262 in plain C is defined as
269 in ``idef-parser/macros.h.inc`` and as such is not expanded and kept as a "call"
272 macros in ``macros.h`` are kept unexpanded to aid in parsing, as seen in the
275 Finally, in mapping these input expressions to tinycode generators, idef-parser
276 tries to perform as much as possible in plain C. Such as, performing binary
277 operations in C instead of tinycode generators, thus effectively constant
283 Similarly to C, variables in the input code must be explicitly declared, such as
285 ``int var2 = 0;`` is also allowed and behaves as expected. In tinycode
296 in. Contrary to C, we only allow variables to be declared with an integer type
297 specified in the following table (without permutation of keywords)
328 In idef-parser, variable names are matched by a generic ``VARID`` token,
331 name, size, and bit width of the newly declared variable. In addition, this
345 For each operation, the type of ``rvalue``\ s influence the way in which the
351 The bit width also influences the outcome of the operations, in particular while
356 ``rvalue``\ s; in that case if one of the two operands is greater than 32 bits
385 statements do not perfectly mirror what would be expected in C, for instance we
387 operator is disallowed. All the predicated instructions, and in general all the
402 possible because the loops will be executed in the QEMU code, leading to the
410 All the helper functions in ``idef-parser.y`` carry two fixed parameters, which
414 therefore the instruction compilation could easily be parallelized in the
425 Compile-time errors in Bison-generated parsers are usually due to conflicts in
436 ``-Wcex`` option to Bison. In general shift/reduce conflicts are solved by
437 redesigning the grammar in an unambiguous way or by setting the token priority
447 parsing error reports the fragment of the input text which was involved in the
464    fail to compile when included in QEMU. The compilation errors are shown by
467    which boil down to errors in the idef-parser type system.
480    An example of debugging this type of failure is provided in the following
490 implementations already present in QEMU. To do so you should obtain a QEMU build
508 Let's first introduce a bug in the tinycode generator of the ``A2_add``
522 Here the bug, albeit hard to spot, is in ``tcg_gen_add_i32(tmp_0, RsV, RsV);``
537 In the output, we find a failure in the very first test case ``float_convs``
561 to diverge on line 141, with an incorrect value in the ``R1`` register
581     117 |  IN: _start_c
594 As such, we are actually interested in the instructions ran before this.
601     55 |  IN: _start
653 able to generate code in the order of evaluation of the various rules, without,
654 in any case, being able to backtrack and alter the generated code.
662 This ternary assignment, when written in this form requires us to emit some
689 found even in the add operation we already saw:
698 consequence of the syntax-driven nature of the parser. In fact when we parse the
712 LLVM IR, which in turn could be compiled using the clang TCG backend. That code