public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
From: "Frank Ch. Eigler" <fche@redhat.com>
To: Greg McGary <greg@mcgary.org>
Cc: cgen@sourceware.cygnus.com
Subject: Re: defining 2-operand version of 3-operand insns?
Date: Wed, 06 Dec 2000 10:42:00 -0000	[thread overview]
Message-ID: <20001206134159.A30198@redhat.com> (raw)
In-Reply-To: <msitoxwghs.fsf@mcgary.org>

Hi -

Greg McGary <greg@mcgary.org> wrote:
: > I got this to work by employing a dirty trick.  [...]
: > (df  f-dest2   "dest dup'ed into src1"      () 25 10 UINT
: >      ((value pc) (add UWI value (sll UWI value (const 5))))
: >      ((value pc) (srl UWI value 5)))
: > 
: > The decode part is actually unused, since the insn that uses
: > dest2 has a NO-DIS attribute.
: 
: Whereas this works for the assembler, it causes trouble for the
: simulator:
: [...]
: Since the 2-operand versions are exclusively an assembler-language
: convenience, they should be ignored from the simulator.
: Unfortunately, I don't see a `NO-SIM' attribute.  Should I add one, or
: is there a better way out of this jam?

I think there are two or three good longer term options:

* an extension to the insn macro code that would allow one to copy
  ifield values
* a generalization of insn ifield-assertions (the "(+ ENUM op (f-foo 1))"
  clauses) to permit specialization to override other alternatives, both
  for disassembly and for sim decoding

In the short term, another way would be to combine the two alternative
instructions into one, taking a special operand that stands for the
required/optional pair.  This operand would be associated with a parser
function in *.opc that consumes one or two comma-separated fields (depending
on the input string), and fills in the optional field in the former case.
(An associated printer routine can do the inverse transformation.)

Do I need to complete this sketch with an example?


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

iD8DBQE6Loh3VZbdDOm/ZT0RAgT3AJ9t7YCItTsKJoxXYQuDVcWSIKQv9wCfWIh8
mhqnUWtt61QLvlps/s3uN4g=
=5fdH
-----END PGP SIGNATURE-----

  parent reply	other threads:[~2000-12-06 10:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-01 14:17 Greg McGary
2000-12-01 14:33 ` Frank Ch. Eigler
2000-12-01 15:55   ` Greg McGary
2000-12-06 10:29     ` Greg McGary
2000-12-06 10:40       ` Greg McGary
2000-12-06 10:45         ` Doug Evans
2000-12-06 10:42       ` Frank Ch. Eigler [this message]
2000-12-06 11:13     ` Doug Evans
2000-12-06 11:26       ` Frank Ch. Eigler
2000-12-06 11:51         ` Doug Evans
2000-12-06 11:40       ` Greg McGary

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20001206134159.A30198@redhat.com \
    --to=fche@redhat.com \
    --cc=cgen@sourceware.cygnus.com \
    --cc=greg@mcgary.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).