* CGEN_WIDE_INT_INSN_P?
@ 2009-09-26 0:50 Doug Evans
2009-09-26 1:37 ` CGEN_WIDE_INT_INSN_P? Frank Ch. Eigler
0 siblings, 1 reply; 3+ messages in thread
From: Doug Evans @ 2009-09-26 0:50 UTC (permalink / raw)
To: cgen
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.]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: CGEN_WIDE_INT_INSN_P?
2009-09-26 0:50 CGEN_WIDE_INT_INSN_P? Doug Evans
@ 2009-09-26 1:37 ` Frank Ch. Eigler
2009-09-26 2:50 ` CGEN_WIDE_INT_INSN_P? Doug Evans
0 siblings, 1 reply; 3+ messages in thread
From: Frank Ch. Eigler @ 2009-09-26 1:37 UTC (permalink / raw)
To: Doug Evans; +Cc: cgen
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: CGEN_WIDE_INT_INSN_P?
2009-09-26 1:37 ` CGEN_WIDE_INT_INSN_P? Frank Ch. Eigler
@ 2009-09-26 2:50 ` Doug Evans
0 siblings, 0 replies; 3+ messages in thread
From: Doug Evans @ 2009-09-26 2:50 UTC (permalink / raw)
To: Frank Ch. Eigler; +Cc: cgen
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 :-)).
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-09-26 2:50 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-26 0:50 CGEN_WIDE_INT_INSN_P? Doug Evans
2009-09-26 1:37 ` CGEN_WIDE_INT_INSN_P? Frank Ch. Eigler
2009-09-26 2:50 ` CGEN_WIDE_INT_INSN_P? Doug Evans
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).