From: Greg McGary <greg@mcgary.org>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: cgen@sourceware.cygnus.com
Subject: Re: defining 2-operand version of 3-operand insns?
Date: Wed, 06 Dec 2000 10:40:00 -0000 [thread overview]
Message-ID: <msg0k1wfzh.fsf@mcgary.org> (raw)
In-Reply-To: <msitoxwghs.fsf@mcgary.org>
Greg McGary <greg@mcgary.org> writes:
> Processing decoder for bits 31 30 29 28 27 26 ...
> Filtering 2 instructions.
> Instruction add2rambiguity-filtered by add3r
> Instruction add3rambiguity-filtered by add2r
> Processing decode entry 0 in decode_table_0, invalid ...
First, Here's a patch to add a space:
Index: insn.scm
===================================================================
RCS file: /usr/rback/release/tools-src/cygnus-unified/src/cgen/insn.scm,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 insn.scm
--- insn.scm 2000/12/05 17:50:18 1.1.1.1
+++ insn.scm 2000/12/06 18:34:40
@@ -729,7 +729,7 @@
(keep? (not superset-insn)))
(if (not keep?)
(logit 2
- "Instruction " (obj:name insn) "ambiguity-filtered by "
+ "Instruction " (obj:name insn) " ambiguity-filtered by "
(obj:name superset-insn) "\n"))
keep?))
insn-list)
> All of the instructions for which I have 2 & 3 operand versions
> defined as above are excluded from the sim decoder as ambiguous.
> 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 have an idea. filter-harmlessly-ambiguous-insns drops insns that
have fewer mask bits, retaining the most specific format. A solution
to my problem would be to also compare number of operands and consider
the insn with more operands to be more specific.
Doug, does that sound reasonable to you, or are you philosophically
opposed to the entire 2/3 operand insn hack?
Greg
next prev parent reply other threads:[~2000-12-06 10:40 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 [this message]
2000-12-06 10:45 ` Doug Evans
2000-12-06 10:42 ` Frank Ch. Eigler
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=msg0k1wfzh.fsf@mcgary.org \
--to=greg@mcgary.org \
--cc=cgen@sourceware.cygnus.com \
--cc=fche@redhat.com \
/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).