This patch removes the L_*U sizes from the h8300 opcode description.
It's mostly a clean-up, although it would also fix the same bug as:
http://sources.redhat.com/ml/gdb-patches/2003-07/msg00053.html
Before the h8sx stuff went in, all L_16|IMM operands were used in
word instructions and all L_8|IMMs were used in byte instructions.
The code that handled these operands therefore allowed both signed
and unsigned values.
However, the h8sx allows 32-bit instructions to have 16-bit immediates.
The immediate is then zero-extended, so -1 in:
mov.l #-1,er0
must not be treated as a 16-bit value.
As I understand it, the L_*U sizes were added to express this.
But they seem to have made the code more confusing (cf. the bug
linked above).
I think previous practice was to use L_* only to work out the
size of the operand field. Things like the MODE bits decided
how that field translated into the final operand value. Now,
everything that handles L_16 has to decide whether it should
also handle L_16U (and if so, how). It gives the impression
that there are more variations than there really are.
We already have a separate flag (NO_SYMBOLS) that indicates whether
an IMM operand is a short immediate. So I think it would be more
consistent to use L_16 and L_8 for all IMMs and (where necessary)
look at NO_SYMBOLS to decide whether an IMM is short or not.
[In fact, there only seems to be one place in the source code
where we care, namely gas/config/tc-h8300.c:get_specific().]
Tested on h8300-elf and h8300-coff (binutils & sim). I also tested
it with the WIP h8sx gcc port. Michael said he was OK with sim side
if tests passed.
OK to install?