DJ Delorie <[EMAIL PROTECTED]> 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
