Derived Operands

Derived Operands

[Tracy.Kuhrt]

I am trying to use derived operands.  I know that they are still a work in
progress, but this is functionality that will help me with the CPU that I
am porting with CGEN.

Following is a snippet of code:

...

; Derived operands
(define-derived-operand
   (name m3-dst-reg-direct)
   (comment "m3 dst reg direct")
   (mode UINT)
   (args (m3-dst-reg))
   (syntax "${m3-dst-reg}")
   (base-ifield f-m3-dst-operand)
   (encoding (+ m3-dst-reg))
   (getter ())
   (setter (set newval (const #b000)))
)

(define-derived-operand
   (name m3-dst-reg-indirect)
   (comment "m3 dst reg indirect")
   (mode UINT)
   (args (m3-dst-reg))
   (syntax "${m3-dst-reg}")
   (base-ifield f-m3-dst-operand)
   (encoding (+ m3-dst-reg))
   (getter ())
   (setter (set newval (const #b001)))
)

(define-anyof-operand
   (name m3-dst-operand)
   (comment "This is any of the m3 dst operands.")
   (mode UINT)
   (base-ifield f-m3-dst-operand)
   (choices m3-dst-reg-direct m3-dst-reg-indirect)
)

...

(define-insn
   (name mov)
   (syntax "mov ${m3-src-reg},${m3-dst-operand}")
   (format (+ OP1_7 OP2_8 (f-byte-operation 0) m3-src-reg m3-dst-operand))
   (semantics (set m3-dst-operand m3-src-reg))
)

I am receiving the following error when trying to generate <arch>-opinst.c
for the instruction that uses the anyof-operand.

10* [map #<procedure (insn)> (#(# #) #(# #) #(# #) ...)]
11* [#<procedure (insn)> #(#("object" # mov ...) (# #f # ...))]
12* [gen-obj-sanitize #(#("object" # mov ...) (# #f # ...)) ...
13* [string-append "  & " ...
14* [gen-sym #:unbound]
15  [gen-c-symbol ...
16* [obj:name #:unbound]
17  [send #:unbound get-name]
18* [-object-check #:unbound "send"]
19* (if (not (object? maybe-object)) (apply -object-error (append! #
extra-text)))
20  [apply #<procedure -object-error (proc-name x . text)> ("send"
#:unbound "not an object")]
    ...
21  [error "send: not an object" #:unbound]

./cos.scm:256:3: In procedure error in expression (error (string-append
proc-name ": " ...) x):
./cos.scm:256:3: send: not an object #:unbound
ABORT: (misc-error)

Any ideas where the problem might be?

Also, as a side note, is there any timeframe for when derived operands will
be completed?

Tracy

Re: Derived Operands

[Frank Ch. Eigler]

Hi -

On Thu, Oct 05, 2000 at 04:28:15PM -0700, Tracy.Kuhrt@microchip.com wrote:
> I am trying to use derived operands.  I know that they are still a work in
> progress, but this is functionality that will help me with the CPU that I
> am porting with CGEN. [...]
> 
> ; Derived operands
> (define-derived-operand
>    (name m3-dst-reg-direct)
>    [...]
>    (encoding (+ m3-dst-reg))
>    [...]
> 
> (define-derived-operand
>    (name m3-dst-reg-indirect)
>    [...]
>    (encoding (+ m3-dst-reg))
>    [...]
> [...]

It looks wrong for these two encodings to be identical.  The anyof-operand
will have a tough time telling the two alternatives apart.

> [error follows:]
> 13* [string-append "  & " ...
> 14* [gen-sym #:unbound]
> [...]

#14 is the first sign of trouble.

> Any ideas where the problem might be?

Look at the encoding, then at the getter/setter pairs.


> Also, as a side note, is there any timeframe for when derived operands will
> be completed?

We have been completing parts as our various ports have required.  This being
an open-source type project, it is hard to predict timeframes such as this.
Perhaps you might be interested in helping fund the work?


- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE53ow1VZbdDOm/ZT0RAuyXAJ4sAVhrnaSzLliXxkmp41/oCTUefgCeIpnO
3JAR0KKleikk9g1gvIObFgA=
=Nj7j
-----END PGP SIGNATURE-----

derived operands

[J. Johnston]

I recently ran into a problem that I tracked down to a derived-operand I used directly in an
instruction (i.e. did not wrapper it in an anyof-operand).  CGEN generated my opcode files fine,
however, when I attempted to assemble the insn that referred to the dndo, I got an assembler parse
error because it did not recognize the opindex of the dndo operand.  Adding an anyof-operand with
one choice solved the problem and I have since reworked my code so that I use the anyof-operand
properly to encapsulate two choices.

Is it intentional that a derived-operand cannot be used directly as an operand in an instruction? 
If yes, could CGEN at least fail when generating the opcodes files?

-- Jeff J.