Working with BITS_PER_WORD == 0x10

["First Name Last Name" <jshammond at my-deja dot com>]

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.