> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@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
