Re: [M16C-ELF] : Problem with double and float data types.

[Ian Lance Taylor <ian at airs dot com>]

DJ Delorie <dj@redhat.com> writes:

> > I have observed the following behavior while using "float" and
> > "double" data types for m16c target. Any computation involving a
> > "float" or a "double" data type does not work on the m16c hardware.
> > However, the correct values can be observed using GDB simulator.
> 
> I figured out what the root cause of this is.  The SHL.L opcode (32
> bit shift) has a maximum shift count of 16:
> 
> * If src is a register and you selected (.W) or (.L) for the size
>   specifier (.size), the number of shifts is -16 to +16. Although you
>   can set 0, no bits are shifted and no flags are changed. If you set
>   a value less than -16 or greater than +16, the result of shift
>   is indeterminate.
> 
> Indeed, the chip masks the shift count by 0x1f (it's signed) so a
> shift by (say) 23 ends up shifting by 7 instead.  Hmmm, that would
> imply a count range of -16..15, not -16..16.  I'll have to experiment
> and find out for sure.  The simulator doesn't mask the count.
> 
> Do any other chips have a shift opcode which cannot shift by the max
> size of the operand?  Does gcc know how to deal with this?
> 
> Note: the m32c chips don't have this limitation.  The m16c is a 16 bit
> chip.

I don't know whether any other chip has this particular limitation,
but it's not hard to handle.  ashlsi3 and friends should be a
define_expand which turn an overly large CONST_INT into two shifts,
load the shift count into a register, whichever is likely to be
better.  The MIPS16 does this, for example (search for any_shift:GPR
in mips.md).  Then the real insn should use an operand predicate which
only accepts CONST_INTs which are in range.

Ian