Hi, This is to update you that we have tested "float" and "double" data type computations on m32c hardware (3DKM32C/85U) and found that it is working successfully.
Regards, Ina Pandit KPIT Cummins InfoSystems Ltd. Pune, India ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Free download of GNU based tool-chains for Renesas' SH and H8 Series. The following site also offers free technical support to its users. Visit http://www.kpitgnutools.com for details. Latest versions of KPIT GNU tools were released on October 12, 2005. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: DJ Delorie [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 11, 2006 11:56 PM To: Ina Pandit Cc: gcc@gcc.gnu.org Subject: Re: [M16C-ELF] : Problem with double and float data types. > 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.
