CGEN_WIDE_INT_INSN_P?

[dje@google.com (Doug Evans)]

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.]