From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Evans To: Dave Brolley Cc: Richard Sandiford , cgen@sources.redhat.com Subject: Re: Endianness and CGEN_INT_INSN_P Date: Tue, 02 Jan 2001 09:21:00 -0000 Message-id: <14930.3569.407518.729928@casey.transmeta.com> References: <3A520486.9060300@redhat.com> X-SW-Source: 2001-q1/msg00005.html 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?