Re: [MIPS, committed] Add utility functions for reading and writing insns

["Maciej W. Rozycki" <macro at codesourcery dot com>]

On Sun, 23 Sep 2012, Richard Sandiford wrote:

> The patch I just posted added a function called write_compressed_insn.
> This patch makes full use of it, and also adds read_insn, write_insn
> and read_compressed_insn.

 Good idea, thanks.  One note/question below.

> +/* Read a microMIPS or MIPS16 opcode from BUF, given that it
> +   has length LENGTH.  */
> +
> +static unsigned long
> +read_compressed_insn (char *buf, unsigned int length)
> +{
> +  unsigned long insn;
> +  unsigned int i;
> +
> +  insn = 0;
> +  for (i = 0; i < length; i += 2)
> +    {
> +      insn <<= 16;
> +      if (target_big_endian)
> +	insn |= bfd_getb16 ((char *) buf);
> +      else
> +	insn |= bfd_getl16 ((char *) buf);
> +      buf += 2;
> +    }
> +  return insn;
> +}
> +

 This would handle 48-bit microMIPS instructions just fine, but only on 
64-bit hosts (interestingly enough you've decided to use "unsigned int" 
for a change to hold the instruction for write_compressed_insn).  I think 
to avoid this kind of inconsistencies we should decide on an "instruction 
data" type, call it insn_t or whatever and then use it throughout.

 Also do we have any plans to switch binutils to support 64-bit data types 
on 32-bit hosts anytime soon?  Staying away from such types back in the 
1990's was surely justified, now some 15 years on this is a serious 
hindrance and I find support for years-obsolete vendor compilers a poor 
excuse.  The C99 standard and its 64-bit data types has been around for 
almost 13 years now.

 In the MIPS port we've been wasting lots of space on 64-bit hosts with 
the use of the "long" types throughout (and especially in the opcode 
tables) and no gain from that whatsoever -- the requirement to avoid the 
use of the upper 32 bits made the use of these types pointless, especially 
as elsewhere we assume the "int" type is at least 32-bit wide (so no 
support for 16-bit hosts either).

 In the opcode tables we have now run out of instruction flags again and 
we are about to run ot of CPU flags.  Additionally we have no direct way 
to encode the 48-bit microMIPS LI instruction.  The use of 64-bit data 
types on 32-bit hosts would let us go past these limitations straight away 
without adding more struct members (and wasting yet more space on 64-bit 
hosts).

 Can we please address these issues sooner rather than later?  Do we 
specifically *know* of any hosts that are still in use and yet fail to 
provide a 64-bit data type, is anyone able to list their names?

  Maciej