Re: Endianness and CGEN_INT_INSN_P

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

dje wrote:
:  [...]
:  > I must admit that I would prefer to see a single general mechanism
:  > (byte strings) as opposed to that PLUS a reasonable but tricky
:  > optimization.  Doug, do you have any sense of how much processing
:  > time the INT_INSN_P flag saves when present?
: 
: The intent was in part to save processing time, but not of GAS per se.

That's true -- the simulators also like to pass instruction words around.

: [...]
: When I did INT_INSN_P I was thinking of the various RISC chips
: that all have 32 bit insns, and I wanted cgen to be used in _all_ the
: various apps where people were encoding and decoding insns
: (not that that is the only intended use of cgen of course).

But none of these (future / mythical?) applications would be precluded
if byte-strings were the canonical representation, and the apps were to
use to/from-int32 conversions.

I'm arguing more from a software engineering perspective.  By having
the INT_INSN_P option, two forks of target support runtimes must be
kept functional with changes such as variable-length instructions.
Where the option is not a clear & convincing optimization that 
justifies the burden of dual maintenance, it should be deprecated.


: [...]
: refresher: libcgen is a (still mythical) generalized and spiffed up
: libopcodes

To me, an important requirement would be to support multiple targets
concurrently.  The fewer compile-time target-dependent macros (INT_INSN_P)
the better. :-)


- FChE

PGP signature