Re: [sdcc-devel] PIC16 code generation question

[Vangelis R. <vr...@ot...>]

----- Original Message ----- 
From: "Aaron Colwell" <mar...@ho...>
To: <sdc...@li...>
Subject: Re: [sdcc-devel] PIC16 code generation question


> >Just for the record, the generation of only these 2 instructions is a
> >great improvement!:-) You can see the old code if you try to compile
> >something like: temp = PORTAbits.RA0; which reads bit 0...
> >Then imagine something similar for setting bit 0. (Hint: I haven't
> >optimized
> >the bit reading function!)

Before the message I above, I did send another one explaining the nature
of the problem, but I didn't make it to the list, I don't know why! I quote
it below...

---------------------------------------------------------------------------
> > Here is what is generated.
> >
> > LFSR    0x00, _INTCONbits
> > BSF     INDF0,6
> >
> > Here is what could be generated instead
> > BSF INTCON, 6
> >
> > I've tried looking into the cause of this myself, but I don't know where to
> > start. It looks like
> > genPackBits() is responsible for the BSF instruction, but I don't know where
> > the LFSR instruction
> > is coming from.
>
> You are correct, the BSF is generated by the genPackBits() function.
> The LFSR is generated by the genSet*Pointer functions prior to calling
> genPackBits(). This of course should be optimized and it is in my todo list,
> I just didn't wanted to mess with this in the past months cause I had other
> things to do. Now I am thinking of a major reorgnization of the pointer
> functions and this inefficiency will surely be optimized out...
>
> Perhaps, I could try a quick workaround for the gen*Bits functions...
>
> regards,
> Vangelis
--------------------------------------------------------------------------


> I appreciate the work you have done. I've been quite happy with the results
> so far. I never realized what sorts of things I take for granted in the other
> compilers I use on a daily basis. I see how hard of a problem it is. :)
>
> I tried to compile the suggested statement, just to see what the old code
> looked like. The
> compiler crashed. On line 1122 in gen.c. It looks like sym->usl.spillLoc is
> NULL and gets dereferenced. I'll file a bug and look at the code to see if
> I can get an idea of what is going on.

Interesting, I've tried that example by my self but no error occured...
What command line did you use?

> I want to help fix problems I find and not just be the type of person that
> says "It's broken. Fix it."

Perhaps you could help with pic16 port....


> I thought that was likely part of the reason. Is there still active
> development on the pic port? I may want to do some 16FXXX
> work a little later.

There seems to be a growing interest on the pic port lately... See
the ChangeLog file.

> Sounds good to me. I can totally understand that stability should come
> first.
>
> I'll continue to post any problems I have along with solutions if I can
> figure out what is going wrong. I'm going to try to use sdcc for my current
> project. I'm trying to create a 18FXXX based dsPIC programmer.
> I'm currently using a 18F242 for the project for now.

Good, it doesn't seem to be a complicated task. Have you created any
library for driving the USART? I am trying to gather sources to create
a peripheral's library for controlling ADC (that is ready), USART, PWM,
timers, PORTB etc... (almost everything Microchip C18 libraries do and
more...!)
Are you interested to take over this task?

> Which file changed? I'm interested in getting an idea of how all the code
> generation code works.
> I'll let you know if I run into any problems with the change.

Generally all code generation functions are placed in gen.c (some which
has to do with arithmetic are placed in genarith.c and some helper functions
are in genutils.c)

regards,
Vangelis