This is the mail archive of the
cgen@sourceware.org
mailing list for the CGEN project.
CGEN_WIDE_INT_INSN_P?
- From: dje at google dot com (Doug Evans)
- To: cgen at sourceware dot org
- Date: Fri, 25 Sep 2009 17:50:44 -0700 (PDT)
- Subject: CGEN_WIDE_INT_INSN_P?
Hi.
On the opcodes-like size of things,
I remember ages ago talk of not having a choice between representing
instructions as an int or as a byte stream,
and just having a byte stream.
I kinda like using an int for targets where it feels like the
obvious choice (e.g. sparc, etc.).
Wrappers could fold CGEN_INT_INSN_P targets into byte streams.
Well, there are targets that would like to use an int but
32 bits isn't enough and 64 is enough.
Should we add CGEN_WIDE_INSN_INT (or some such)
and allow targets to use that?
[I don't have a strong opinion. The topic will come up,
so I'd like us to start thinking about it.]
I wouldn't necessarily specify it the following way, but to illustrate:
[from include/opcodes/cgen.h]
typedef unsigned int CGEN_INSN_INT;
typedef mumble_wide_int_mumble CGEN_WIDE_INSN_INT;
#if CGEN_WIDE_INT_INSN_P
typedef CGEN_WIDE_INSN_INT CGEN_INSN_BYTES;
typedef CGEN_WIDE_INSN_INT *CGEN_INSN_BYTES_PTR;
#elif CGEN_INT_INSN_P
typedef CGEN_INSN_INT CGEN_INSN_BYTES;
typedef CGEN_INSN_INT *CGEN_INSN_BYTES_PTR;
#else
typedef unsigned char *CGEN_INSN_BYTES;
typedef unsigned char *CGEN_INSN_BYTES_PTR;
#endif
There'd be ramifications throughout binutils.
Eventually I'd like to rework cgen.h and opcodes support anyway.
Maybe this could be part of that.
[One thing I'd like to do is at least split cgen.h into two
(possibly more) pieces: the parts that are target independent,
and the parts that are target dependent.]
[btw, I don't like the names CGEN_INSN_BYTES{,_PTR} much,
I'd love to change them if a better ones came along.]