> I figured out what the root cause of this is. The SHL.L opcode (32
> bit shift) has a maximum shift count of 16:
This patch (committed) should fix it. I haven't addressed the "large
variable shift count" part of the problem; this addresses the "large
constant shift count" part which is needed
> 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.
Ok, thanks. The m32c allows -32..+32 shifts so it wouldn't have this
particular problem. I'll probably end up splitting the m16c
eased 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
> I would be interested in looking at the data sheet for this chip. I
> didn't see which chip it was. The thing that has me curious is the
> negative shift counts. Can a right shift of a negative count (of
> some type (rotate?)) substitute for a left shift when the shift is
> greater than 16?
On Jan 11, 2006, at 10:11 PM, Ian Lance Taylor wrote:
DJ Delorie <[EMAIL PROTECTED]> writes:
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,
lo
DJ Delorie <[EMAIL PROTECTED]> writes:
> > 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, whichev
> 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 t
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 usi
> 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
