This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Working with BITS_PER_WORD == 0x10



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.






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]