Re: Endianness and CGEN_INT_INSN_P

[Doug Evans <dje at transmeta dot com>]

Dave Brolley writes:
 >  From what I understand, CGEN_INT_INSN_P will not be true if there is at 
 > least one insn which will not fit into the word.

But suppose a word is 32 bits, the "base insn size" is 8 bits,
and the maximum insn size is 24 bits ...
How do you lay out an insn that, say, takes a 16 bit immediate?
If we call the insn bytes op, hi, lo (having the obvious meanings),
then big endian it could (though not necessarily - gotta watch out
for those pedants) be op,hi,lo; and for little endian it could be
op,lo,hi.

The supposition is (I'm guessing) that the code can't handle this if
CGEN_INT_INSN_P is true.

I suspect one could get that to work.  There should be enough info
in the description file to get it to work.  Whether one makes the
effort to get it to work (if it already doesn't) I don't have a strong
opinion on, modulo the result not being excessively complicated.

 > 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.  Is this
 > > right?  If so, would it be better to restrict CGEN_INT_INSN_P to that
 > > case, or would it better to handle the multi-word case when
 > > CGEN_INT_INSN_P is true?

I'm guessing that when you said "multi-word" here you actually meant
a case like the above example, right?