RE: Machine description and code generation

["Mathias Roslund" <mathias dot roslund at amidog dot se>]

> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of
> Jeff Law
> Sent: Wednesday, October 29, 2014 9:36 PM
> To: Mathias Roslund; gcc@gcc.gnu.org
> Subject: Re: Machine description and code generation
> 
> On 10/29/14 07:40, Mathias Roslund wrote:
> > Hello,
> >
> > I'm considering attempting a 65816 target but decided it would be a
> > good idea to start with something simple in order to learn how GCC
> > generate code. So I created a minimal machine description with just
> > two instructions (plus the mandatory nop/jump/etc):
> That's ambitious, primarily because something like the 65816's register
file
> does not map well to the types of register files GCC typically works with.
You
> may end up having to do something similar to the virtual registers on the
rl78
> port.

That is/was the plan. I actually took the easy route a while back and create
a MIPS to 65816 recompiler. Works quite well. It wasn't until I started
messing around with tracking register usage and sizes in order to improve
the recompiler that I figured it would be better to attempt a 65816 target
for GCC instead. So I'm basically treating the 65816 as if it were a weird
MIPS like CPU with few instructions, a lot of registers, byte/word
operations and memory to memory operations.

> > What's so special about the first entry in an array that causes this?
> > I have a feeling I'm missing something obvious here :-)
> The best thing to do is to start looking at the various debugging dumps.
>   Probably the most interesting would be the .expand dump which shows
> things as you move from the higher level GIMPLE IL into the initial RTL
IL.  The
> GIMPLE IL will look at lot like C code and should have a form similar to
the
> original input.  The RTL will roughly correspond to instructions.
> 
>  From there you'll either work forward or backwards into gimple or the RTL
> codepaths depending on what your initial analysis shows.

Thanks for the hint. I added the "-da" when compiling and option and had a
look at the output. Was quite interesting and confusing :-) Turned out my
issues were related to costs after all. After implementing TARGET_RTX_COSTS
things started to make a lot more sense.

Since then I've added more instructions and gotten to the point where most
stuff seems to be working. My current issue is that signed divide and all
shift operations insists on sign/zero extending the operands, resulting in
32bit operations even when only 8bit ones would be required. Interestingly,
multiplies and unsigned divides behave as desired, i.e. only operate on the
required number of bits.

Example:

unsigned char data[3];

data[2] = data[0] / data[1];

Is expanded as:

unsigned char _2;
unsigned char _3;
unsigned char _4;
_2 = data[0];
_3 = data[1];
_4 = _2 / _3;
data[2] = _4;

While:

signed char data[3];

data[2] = data[0] / data[1];

Is expanded as:

signed char _4;
int _5;
signed char _6;
int _7;
int _8;
signed char _9;
_4 = data[0];
_5 = (int) _4;
_6 = data[1];
_7 = (int) _6;
_8 = _5 / _7;
_9 = (signed char) _8;
data[2] = _9;

And I really have no idea why the sign extension/truncation does take place
or how to avoid it.

Best regards,

Mathias Roslund