From: Doug Evans <dje@sebabeach.org>
To: cgen@sourceware.org
Subject: [patch] support (ifield enum) in instruction formats
Date: Tue, 07 Jul 2009 18:54:00 -0000 [thread overview]
Message-ID: <20090707185440.65C646E3D0@sebabeach.org> (raw)
Hi.
Instruction formats support "ifield enums", e.g. (+ OP1_4 OP2_3 dr sr),
but one can't do (+ (f-op1 OP1_4) (f-op2 OP2_3) dr sr),
which seems unnecessarily restrictive.
[The "play.cpu" file is just to play around with.
I have a testsuite in the works. When it's checked in
I think it'll be time to retire play.{cpu.opc}.]
2009-07-07 Doug Evans <dje@sebabeach.org>
* cpu/play.cpu (add): Use (ifield enum) for one format element.
* cpu/play.opc: New file.
Allow arbitrary enums in instruction formats, e.g. (f-op1 OP1_4).
* insn.scm (-parse-insn-format-ifield-spec): Recognize (ifield enum).
* doc/rtl.texi (Instructions): Update.
Index: insn.scm
===================================================================
RCS file: /cvs/src/src/cgen/insn.scm,v
retrieving revision 1.16
diff -u -p -r1.16 insn.scm
--- insn.scm 24 Jun 2009 15:03:09 -0000 1.16
+++ insn.scm 7 Jul 2009 18:38:46 -0000
@@ -546,9 +546,15 @@
; ??? This use to allow (ifield-name operand-name). That's how
; `operand-name' elements are handled, but there's no current need
; to handle (ifield-name operand-name).
- (if (not (integer? value))
- (parse-error errtxt "ifield value not an integer" ifld-spec))
- (ifld-new-value ifld value))
+ (cond ((integer? value)
+ (ifld-new-value ifld value))
+ ((symbol? value)
+ (let ((e (enum-lookup-val value)))
+ (if (not e)
+ (parse-error errtxt "symbolic ifield value not an enum" ifld-spec))
+ (ifld-new-value ifld (car e))))
+ (else
+ (parse-error errtxt "ifield value not an integer or enum" ifld-spec))))
)
; Subroutine of -parse-insn-format to parse an
Index: cpu/play.cpu
===================================================================
RCS file: /cvs/src/src/cgen/cpu/play.cpu,v
retrieving revision 1.3
diff -u -p -r1.3 play.cpu
--- cpu/play.cpu 22 Dec 2002 02:06:47 -0000 1.3
+++ cpu/play.cpu 7 Jul 2009 18:38:46 -0000
@@ -175,7 +175,8 @@
(dni add "add"
()
"add $dr,$sr"
- (+ OP1_4 OP2_0 dr sr)
+ ; Use (f-op1 OP1_4) to exercise it.
+ (+ (f-op1 OP1_4) OP2_0 dr sr)
(sequence ()
(set vbit (add-oflag dr sr (const 0)))
(set cbit (add-cflag dr sr (const 0)))
Index: cpu/play.opc
===================================================================
RCS file: cpu/play.opc
diff -N cpu/play.opc
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ cpu/play.opc 7 Jul 2009 18:38:46 -0000
@@ -0,0 +1,18 @@
+/* Play opcode support. -*- C -*-
+ Copyright (C) 2009 Red Hat, Inc.
+ This file is part of CGEN. */
+
+/* This file is an addendum to play.cpu. Heavy use of C code isn't
+ appropriate in .cpu files, so it resides here. This especially applies
+ to assembly/disassembly where parsing/printing can be quite involved.
+ Such things aren't really part of the specification of the cpu, per se,
+ so .cpu files provide the general framework and .opc files handle the
+ nitty-gritty details as necessary.
+
+ Each section is delimited with start and end markers.
+
+ <arch>-opc.h additions use: "-- opc.h"
+ <arch>-opc.c additions use: "-- opc.c"
+ <arch>-asm.c additions use: "-- asm.c"
+ <arch>-dis.c additions use: "-- dis.c"
+ <arch>-ibd.h additions use: "-- ibd.h" */
Index: doc/rtl.texi
===================================================================
RCS file: /cvs/src/src/cgen/doc/rtl.texi,v
retrieving revision 1.24
diff -u -p -r1.24 rtl.texi
--- doc/rtl.texi 21 Jun 2009 06:54:49 -0000 1.24
+++ doc/rtl.texi 7 Jul 2009 18:38:47 -0000
@@ -1867,9 +1867,10 @@ The ordering of the fields is not import
Format elements can be any of:
@itemize @bullet
-@item instruction field specifiers with a value (e.g. @code{(f-r1 14)})
-@item an instruction field enum, as in @code{OP1_4}
-@item an operand
+@item an instruction field name with an integer, e.g. @code{(f-op1 4)}
+@item an instruction field name with an enum, e.g. @code{(f-op1 OP1_4)}
+@item an instruction field enum, e.g. @code{OP1_4}
+@item an operand name, e.g. @code{dr}
@end itemize
@subsection semantics
reply other threads:[~2009-07-07 18:54 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20090707185440.65C646E3D0@sebabeach.org \
--to=dje@sebabeach.org \
--cc=cgen@sourceware.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).