This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Working with BITS_PER_WORD == 0x10
- To: "First Name Last Name" <jshammond at my-deja dot com>
- Subject: Re: Working with BITS_PER_WORD == 0x10
- From: Michael Collison <collison at isisinc dot net>
- Date: Tue, 3 Oct 2000 21:12:10 -0400
- Cc: gcc at gcc dot gnu dot org,gcc-owner at gcc dot gnu dot org
I guarantee that gcc works on systems where BITS_PER_WORD and BITS_PER_UNIT
are both 16. See my dsp16xx port in the config/dsp16xx directory for an
example. I can think of many reasons that your 16-bit quantities are being
sign-extended to 32-bits: among them are defining the PROMOTE_ family of
macros (see the documentation), an incorrect HARD_REGNO_NREGS, etc. Take a
long hard look at your '.h', especially the sizes of the C datatypes, etc.
and i'm sure you'll discover the problem.
I'm not sure about your multiply problem. It's probably a bug in your
machine description file.
Mike
Michael Collison
collison@isisinc.net
"First Name
Last Name" To: gcc@gcc.gnu.org
<jshammond@my cc:
-deja.com> Subject: Working with BITS_PER_WORD == 0x10
Sent by:
gcc-owner@gcc
.gnu.org
10/03/00
08:40 PM
I have been using a system where BITS_PER_WORD and BITS_PER_UNIT
are both equal to 16. There have been two instances of
unusual behavior which I think are related to BITS_PER_WORD being
16 bits rather than the more typical 32.
The first problem was related to functions that are supposed to
return 16 bit quantities.
short foo() { return 1; }
void bar()
{
short rval;
rval = foo();
..
It turns out that foo would extend the return value to 32 bits
(2 registers) instead of returning the value in a single register.
This causes a problem because when it came time to assign a value
to rval only a single register was used, the one containing the
MS half of the 32 bit return value which was always zero. The
workaround I put into the .md file would generate an extra
instruction to move the LS half of the 32 bit return value into
the MS half when a 16 bit return value was expected. Certainly
not an ideal solution.
The other problem involved 16 multiplies with a constant like,
..
short a=3;
a = a * (short)5;
..
This would always cause a compile time error. According to the
RTL statements it tried to extend the constant 5 to a 32
bit quantity, which would cause a failure because there is no
pattern which would allow multiplication of a 16 bit register
and a 32 bit immediate. This happened even though there was
a pattern for a 16 bit register times a 16 bit immediate. The
work around here was to remove the 16 bit register times
immediate pattern. Now that sequence generates a move immediate
to register and then a register * register multiply.
I was wondering if this tendency to extend 16 bit values to 32
bit values unnecessarily for BITS_PER_WORD == 16 was a gcc bug
or my bug?
Thanks,
Jeff Hammond
------------------------------------------------------------
--== Sent via Deja.com http://www.deja.com/ ==--
Before you buy.