This is the mail archive of the
cgen@sources.redhat.com
mailing list for the CGEN project.
Re: Endianness and CGEN_INT_INSN_P
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