gnupic: Thread: An opensource optimizing C compiler for pic ...

... I wish I had :-) :-).

But seriously. What's there out there? If I find a good one, I
might add support for HLL simulation to gpsim.

I tried mary, but it seems to directly generate hex files and I 
want a possibility for symbolic .cod files, or similar.

I found sdcc. They mention that it's possible to retarget it
to pics, but that sounds like a lot of work.

If it's easy to mix HLL and assembly then perhaps lower
execution speed is of less concern. What about AnyC or SIL? 

Anything that just barely works, and is under development?

Anybody tried the other compilers listed on www.gnupic.org?

 / Ralf

On Thu, 31 Aug 2000 ####@####.#### wrote:

> 
> ... I wish I had :-) :-).

me too.

> But seriously. What's there out there? If I find a good one, I
> might add support for HLL simulation to gpsim.
> 
> I tried mary, but it seems to directly generate hex files and I 
> want a possibility for symbolic .cod files, or similar.
> 
> I found sdcc. They mention that it's possible to retarget it
> to pics, but that sounds like a lot of work.
> 
> If it's easy to mix HLL and assembly then perhaps lower
> execution speed is of less concern. What about AnyC or SIL? 
> 
> Anything that just barely works, and is under development?
> 
> Anybody tried the other compilers listed on www.gnupic.org?

sdcc looks like it's the most actively developed compiler. It already targets
separate processors (avr and 8051 IIRC).

AnyC is directed specifically towards PICs, however the development has been
very sporadic. 

I'd tend to lean toward sdcc. I realize it's a lot of work to add PIC support to
sdcc, but in the long run I think there will be a larger pool of developers to
work with.

Scott

On 31 Aug 00, at 18:56, ####@####.#### wrote:

Ooops I posted this wrong yesterday, sorry ####@####.####

> 
> ... I wish I had :-) :-).
> 
> If it's easy to mix HLL and assembly then perhaps lower
> execution speed is of less concern. What about AnyC or SIL? 
> 
> Anything that just barely works, and is under development?
> 
> Anybody tried the other compilers listed on www.gnupic.org?

I might have the answer.

Have you seen the C compiler, originally by John Favata on the 
GnuPIC
site?
 Originally it produced Pseudo 8051 code, I have made a new code 
gen and
 with some work done by some one else, re-written it for MPASM 
style assemblers.

It is currently in Beta testing. The generated code needs 
optimising, I am starting on new libraries.

I am willing to open source it. The code is a bit untidy though.

Take a look at my web site (listed in the signature), for more 
details.

I will update the source code soon.

Bye,

Ian
Sent by Ian Stedman ####@####.####
Website http://pages.zoom.co.uk/ian.stedman

On Fri, 1 Sep 2000, Ian Stedman wrote:

> > Anybody tried the other compilers listed on www.gnupic.org?
> 
> I might have the answer.
> 
> Have you seen the C compiler, originally by John Favata on the 
> GnuPIC
> site?
>  Originally it produced Pseudo 8051 code, I have made a new code 
> gen and
>  with some work done by some one else, re-written it for MPASM 
> style assemblers.
> 
> It is currently in Beta testing. The generated code needs 
> optimising, I am starting on new libraries.
> 
> I am willing to open source it. The code is a bit untidy though.
> 
> Take a look at my web site (listed in the signature), for more 
> details.
> 
> I will update the source code soon.

Over a year ago I took John's C compiler and made it such that it would compile
under Linux. 

http://www.dattalo.com/gnupic/pic_cc.tar.gz

I guess you can say that it works. However the code generated is grossly
inefficient. This is because Favata's work is based on a free Small C
implementation that had no optimization. 

Consider this example:

GetAD()
{
   char v;
   v=0xff;
   return(v);

}

As an assembly language I'd write:

GetAD:

	retlw  0xff

But look what pic_cc does:

GetAD_
        sub _stackptr, #1
        mov _primary, #0
        add _primary, _stackptr
        call _push_
        mov _primary, #255
        call _pop_
        call _putstk_
        mov _primary, #0
        add _primary, _stackptr
        call _indr_
        jmp _10_
_10_
        add _stackptr, #1
        ret

Sigh.

From this you can see that pic_cc assumes a stack which Favata decided to
emulate in software. Furthermore, you can see how there is no attempt at
optimization. After seeing this code, I decided that there was no hope for
it. This was further confirmed when I examined the source and saw that the
stack assumption is fairly deeply entrenched.

SDCC, OTOH, assumes no stack at all during the optimization phase. It's only
during the 5th or 6th step when code is actually emitted does the use of a
(optional) stack get implemented. 


I don't mean to discourage your efforts, but I think it is going to take a whole
lot of work to get pic_cc to the point of being usable

Scott