gnupic: Thread: Re: [Sdcc-user] Adding PIC support to SDCC

> I think I know the answer, but why was SDCC created separate from gcc? My guess
> is that even though gcc can be retargeted, it makes certain underlying
> assumptions which are invalid for microcontrollers.

I guess so. SDCC was definitely designed for very small
architectures.

> Question 2:
> Is SDCC `really' retargetable to a PIC? The underlying architecture of PICs is

At least Sandeep thinks so. He was actually planning it some
time ago.

> Question 3:
> Have there been any queries/requests of porting SDCC to the PIC before?

You can say that again ! Actually, Sandeep initially was
planning this some time ago, but then there were lots preferring
the Atmel AVR, then there was voting on www.kd0yu.com, where the
AVR fans were in the majority, so Sandeep went for the AVR port.
 
> Question 4:
> Would anyone be interested in pursuing this effort?

Yes, I think so. Look at the voting results at www.kd0yu.com.
PIC was the second strongest architecture after the AVR.

=======================================================================
        "It was hell. They knew it.          Karl-Max Wagner
          But they called it                 ####@####.####
            W-I-N-D-O-Z-E"                   ham radio: DB8CO
            *********Member of No Code International*********
            ***********Visit http://www.nocode.org***********
            ********Membership Number NCI-2563-DB8CO*********
    _
   / /  (_)__  __ ____  __
  / /__/ / _ \/ // /\ \/ /  . . . t h e   c h o i c e   o f   a
 /____/_/_//_/\_,_/ /_/\_\             G N U   g e n e r a t i o n . .

"Et ceterum censeo ut Microsoftem delendum esse" (Cato, adapted)
=======================================================================

>Question 1:
>I think I know the answer, but why was SDCC created separate from gcc? My
guess
>is that even though gcc can be retargeted, it makes certain underlying
>assumptions which are invalid for microcontrollers.

Correct , SDCC addresses several issues which are microcontroller specific.
A) Many address spaces ( Most microcontrollers have multiple address spaces
    accessable using different instructions). SDCC addresses this by adding
    extra (target specific) keywords (so no kludgy intrinsics are needed).
Also
    has three byte generic pointer.
B) Can operate entirely without stack. (Only function calls via pointers
cannot
    be implemented). The local variables and parameters are assumed to be
"static"
    and they can be overlayed for leaf functions.

>Question 2:
>Is SDCC `really' retargetable to a PIC? The underlying architecture of PICs
is
>entirely different than the 8051's. The major difference about which I'm
>concerned is the way the two handle stacks. The PIC (midrange family) has a
hard
>ware code stack that is 8 levels deep. There is no way for this stack to be
>accessed. Furthermore, there is no data stack. So consequently, there sre
no
>push/pop instructions. Does the intermediate code generator make
assumptions
>about the stack architecture?
See above.

>Question 3:
>Have there been any queries/requests of porting SDCC to the PIC before?

Want to do it .. no time :(...


_______________________________________________
Sdcc-user mailing list
####@####.####
http://lists.sourceforge.net/mailman/listinfo/sdcc-user

On Fri, 1 Sep 2000, Sandeep Dutta wrote:

> 
> >Question 1:
> >I think I know the answer, but why was SDCC created separate from gcc? My
> guess
> >is that even though gcc can be retargeted, it makes certain underlying
> >assumptions which are invalid for microcontrollers.
> 
> Correct , SDCC addresses several issues which are microcontroller specific.
> A) Many address spaces ( Most microcontrollers have multiple address spaces
>     accessable using different instructions). SDCC addresses this by adding
>     extra (target specific) keywords (so no kludgy intrinsics are needed).
> Also
>     has three byte generic pointer.
> B) Can operate entirely without stack. (Only function calls via pointers
> cannot
>     be implemented). The local variables and parameters are assumed to be
> "static"
>     and they can be overlayed for leaf functions.

Unfortunately I don't know enough about either gcc or SDCC to make a judgement
in this area. My assumptions were that the differences were more drastic than
you suggest here. For example, most (all?) of the processors gcc targets have
stacks. Most also have 32-bit registers. These two factors could prove to be the
most difficult to overcome.

OTOH, if a port to gcc is possible then one would have (almost) immediate access
to all of the GNU tools that go along with gcc (like the linker, objdump). Some
of these would need patches as well, but my point is that there is a vast
infrastructure present in gcc tool chain that could be leveraged.

> 
> >Question 2:
> >Is SDCC `really' retargetable to a PIC? The underlying architecture of PICs
> is
> >entirely different than the 8051's. The major difference about which I'm
> >concerned is the way the two handle stacks. The PIC (midrange family) has a
> hard
> >ware code stack that is 8 levels deep. There is no way for this stack to be
> >accessed. Furthermore, there is no data stack. So consequently, there sre
> no
> >push/pop instructions. Does the intermediate code generator make
> assumptions
> >about the stack architecture?
> See above.

I'll take a look at this. I think this level of abstraction will be key to a
relatively easy port to the PIC.

> 
> >Question 3:
> >Have there been any queries/requests of porting SDCC to the PIC before?
> 
> Want to do it .. no time :(...

;). I know what you mean. My free time for playing is spent on gpsim. However,
I've had one person express interest in participating in a port such as
this. Perhaps there are a couple of more interested others?

Regards,
Scott

On Fri, 1 Sep 2000, Karl-Max Wagner wrote:

> > Question 4:
> > Would anyone be interested in pursuing this effort?
> 
> Yes, I think so. Look at the voting results at www.kd0yu.com.
> PIC was the second strongest architecture after the AVR.

I hate ballot stuffing :)