Re: Endianness and CGEN_INT_INSN_P

[Doug Evans <dje at transmeta dot com>]

Frank Ch. Eigler writes:
 > On Tue, Jan 02, 2001 at 01:48:37PM +0000, Richard Sandiford wrote:
 > : When CGEN_INT_INSN_P is true, the instruction gets written as a single
 > : integer with the bytes arranged according to the target endianness.  This
 > : only seems appropriate when every instruction is one word long.  
 > 
 > The code checks for all instructions being at most one word (32 bits)
 > long, not exactly one word long.
 > 
 > 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.
Remember that this discussion can't be based on the premise
that we're only talking about GAS (at least that is how I'm
proceeding ...)

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).
While I wasn't trying to make cgen a drop-in replacement,
I wanted to preserve the int-ness of the representation to not
close any doors.

One could present the case that such apps are separate apps and that
INT_INSN_P is a GAS only thing I suppose.  While one can continually
write source generators, I wanted libcgen to obviate the need to
always have to do that.

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