Patch to remove L_*U from h8300 opcode table

[Michael Snyder]

Richard Sandiford wrote:

>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?
>

Sorry for the delay. Please check this in.