CGEN_WIDE_INT_INSN_P?

CGEN_WIDE_INT_INSN_P?

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

Re: CGEN_WIDE_INT_INSN_P?

[Frank Ch. Eigler]

Hi -

On Fri, Sep 25, 2009 at 05:50:44PM -0700, Doug Evans wrote:
> 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.
> [...]

The hard part seems to be not the representation typedefs, but the
operations thereupon.  Fetching, masking, printing, comparing,
constitute a little API that hand-written (e.g. simulator) code
needs to be aware of, and perhaps flexible with regards to.

- FChE

Re: CGEN_WIDE_INT_INSN_P?

[Doug Evans]

On Fri, Sep 25, 2009 at 6:37 PM, Frank Ch. Eigler <fche@redhat.com> wrote:
> Hi -
>
> On Fri, Sep 25, 2009 at 05:50:44PM -0700, Doug Evans wrote:
>> 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.
>> [...]
>
> The hard part seems to be not the representation typedefs, but the
> operations thereupon.  Fetching, masking, printing, comparing,
> constitute a little API that hand-written (e.g. simulator) code
> needs to be aware of, and perhaps flexible with regards to.

No disagreement there.  My only intention was to give enough to
present the flavor of the change (once that's done the rest readily
presents itself for inspection :-)).