sid semantic with derived-operands

sid semantic with derived-operands

[Aurelien Buhrig]

Hi,
I have an issue when generating the sid semantic of derived-operands.
When printing C code for sid semantic, cgen tries to generate a
hardware index (in /gen-hw-index) from a derived ifield, which is not
supported by /gen-hw-index.
I'm not sure if this is a valid case and if the subfields shall be
parsed in /gen-hw-index to find the correct subfield (how?) or if it
should be handled earlier...

Any idea how to solve this issue ?
Thanks,
Aurélien

Backtrace:
In [..]/cgen/sid.scm:
 860:  0  [error "/gen-hw-index: invalid index:" # "
 type: " ...]
 844:  1  (case type ((scalar) "") ...)
 841:  2  (let ((type #) (mode #) (value #)) (case type (# "") (# #) ...))
1001:  3  [/gen-hw-index # #]
1001:  4* (if index (/gen-hw-index index estate) "")
 996:  5  (let* (# # # ...) (logit 4 "<operand> cxmake-get self=" ...) ...)
In unknown file:
   ?:  6  [#<procedure #f #> # # # ...]
    ...
In [..]/cgen/rtl-c.scm:
 450:  7  (cond (# #) (# #) (else #))
 446:  8  (begin (message "MODE=" mode ...) (if (symbol? src) (set! src #)) ...)
 418:  9  (cond ((c-expr? src) (cond # # ...)) ((rtx? src) (let* # # ...)) ...)
 416: 10  (let* ((mode mode)) (cond (# #) (# #) (# #) ...))
 441: 11  [/rtl-c-get # # #]
 438: 12  (let* ((evald-src #)) (if (not #) (error assert-fail-msg #)) ...)
 418: 13  (cond ((c-expr? src) (cond # # ...)) ((rtx? src) (let* # # ...)) ...)
 416: 14  (let* ((mode mode)) (cond (# #) (# #) (# #) ...))
 506: 15* [/rtl-c-get # # #]
 506: 16  (let* ((result #)) (logit 4 (spaces #) "(rtl-c-get " ...) result)
 503: 17  (let* (#) (if # #) (let* # # result))
 571: 18* [rtl-c-get # # #]
 569: 19* [send #("object" <operand> 47 ...) gen-set-trace ... ...
 569: 20  [cx:make #("object" <mode> 30 ...) ...
    ...
1672: 21  [rtl-c-set-trace #("object" <rtl-c-eval-state> 60 ...) UHI ...]
1671: 22  (if (estate-for-insn? *estate*) (rtl-c-set-trace *estate*
mode ...) ...)
In unknown file:
   ?: 23  [#<procedure #f #> # () UHI ...]
In [..]/cgen/rtl-traverse.scm:
2160: 24  [apply #<procedure #f (*estate* options mode dst ...)> (# ()
UHI # ...)]
2159: 25  (if (procedure? fn) (apply fn (cons estate (cdr expr))) fn)
2158: 26  (if fn (if (procedure? fn) (apply fn (cons estate #)) fn) expr)
2156: 27  (let* ((rtx-obj #) (fn #)) (if fn (if # # fn) expr))
2154: 28  (if (pair? expr) (let* ((rtx-obj #) (fn #)) (if fn (if # #
...) ...)) ...)
In [..]/cgen/rtl-c.scm:
 296: 29* [rtx-eval-with-estate (set () UHI ...) #("object" <mode> 30 ...) ...]
 296: 30* [rtl-c-get # # ...
 296: 31  [cx:c ...
 381: 32  [rtl-c-with-estate # # #]
 379: 33  (let* ((estate #)) (rtl-c-with-estate estate mode expr))
In [...]/cgen/sid-cpu.scm:
 716: 34  [rtl-c++-parsed #("object" <mode> 30 ...) (set () UHI ...) ...]
 714: 35  [#<procedure #f (sem)> (set () UHI ...)]
 764: 36* [gen-semantic-code #("object" <insn> 53 ...)]
 740: 37  [list "// ********** " move.w-pipd-rn-srcAnPiHI ... ...
 738: 38  (let (# #) (string-list "// ********** " # ": " ...))

Re: sid semantic with derived-operands

[Frank Ch. Eigler]

Hi -

On Thu, Jun 02, 2016 at 11:34:04AM +0200, Aurelien Buhrig wrote:
> I have an issue when generating the sid semantic of derived-operands.
> When printing C code for sid semantic, cgen tries to generate a
> hardware index (in /gen-hw-index) from a derived ifield, which is not
> supported by /gen-hw-index.
> [...]

Could you share a relevant usable extract of your .cpu file?
Maybe there is a better way to express what you have in mind.


- FChE

Re: sid semantic with derived-operands

[Aurélien Buhrig]

Hi,

Thank you for your answer and sorry for my late reply.

> I have an issue when generating the sid semantic of derived-operands.
>> When printing C code for sid semantic, cgen tries to generate a
>> hardware index (in /gen-hw-index) from a derived ifield, which is not
>> supported by /gen-hw-index.
>> [...]
> Could you share a relevant usable extract of your .cpu file?
> Maybe there is a better way to express what you have in mind.
> The cpu file is quite complex. But I think I found why it is not supported.

One operand (encoded in a 3-bit ifield) encode a reg file. There are 7
registers & 7 possibles values for this operand. For some insns/opcodes,
the 8th encoding is reserved to encode additional operands (exact
operand depends on another opcode).
Without derived operands, it leads to decode ambiguity. When defining a
derived operands with all operands, there are asm/syntax issues, and It
seems also decode issue (i looks like the "impossible" 8th value of the
reg file is not is correctly decoded and is considered as a valid index
for reg file).
So I defined a virtual hardware and an associated operand to describe
the right operand name for the 8th encoding, with the 7 regs. But this
leads to this semantic generation issue ...

I finally found a way to make asm, disassembly, sid decode and sid
semantic to work by creating one operand & virtual hardware per each
ifield encoding. It defines many insns, but there is no more ambiguity.

Thank you for your reply,
Cheers,
Aurélein