This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [MIPS, committed] Add utility functions for reading and writing insns
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: <binutils at sourceware dot org>
- Date: Mon, 24 Sep 2012 19:36:49 +0100
- Subject: Re: [MIPS, committed] Add utility functions for reading and writing insns
- References: <87k3vlultv.fsf@talisman.home>
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