From: Scott D. <sc...@da...> - 2000-09-04 17:18:58
|
On Mon, 4 Sep 2000, Raimonds Cicans wrote: > Hi! > > Scott Dattalo wrote: > > The question about open-sourced C compilers for the PIC arises frequently. <snip> > > If you don't need full featured ANSI compatible C compiler, than you can > try > 'Small C'. Somewhere on web I saw port for 16c84 PIC. <snip> Here's my response on the gnupic mailing list to your suggestion: ----------------------- 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. ----------------------- Your comment is true. However, I don't consider it viable. For the Small C port to be useful, I'm sure that there would have to be a massive over haul in the code. If I'm going to spend that effort I'd like to leverage off something that gets me most of the way there. Regards, Scott |