EmbeddedRelated.com
Forums

8051 C Compiler Recommendation

Started by Arthur Richards June 15, 2005
Arthur Richards wrote:
> I'm finally moving up from assembler. Which compiler do you vote for? I can > probably get away with the Raisonance Lite version but should I shell out > the $'s & go for Keil or something else? > >
Any comments regarding how the Tasking Compiler performs against the Keil compiler? - Richard.W
cbarn24050@aol.com wrote in news:1118943135.615480.114050
@g47g2000cwa.googlegroups.com:

> Hi Richard, when I was using 8051s single chip meant 1k of eprom space. > Huge numbers of applications were written for chips that size back > then. Take a look at the 8052 chip with the basic interpreter in it, I > cant quite remeber if it was a 2 or 4k mask chip but you try writting > one with your C compiler and see what you come up with. >
That's nice, but, given that this discussion is taking place in 2005 when the readily available 8051 variants have significantly more on chip code space, why would I care? We can compare stories about way back when if you'd like, but, that is really not relevant to this discussion. -- Richard
On 16 Jun 2005 13:53:32 GMT, Richard <RichardRapier@netscape.net>
wrote:

>Anton Erasmus <nobody@spam.prevent.net> wrote in >news:1118919213.548a4ac2e2daba518c9bc56bdde53423@teranews: > >> void foo(void) >> { >> } >> >> void bar(void) >> { >> void (*f)(void) =foo; >> f(); >> } >> > >9 bytes of code total, 6 more bytes than if foo had been invoked >directly. Is that small enough for you? > > ; FUNCTION foo (BEGIN) > ; SOURCE LINE # 35 > ; SOURCE LINE # 36 > ; SOURCE LINE # 37 >0000 22 RET > ; FUNCTION foo (END) > > ; FUNCTION bar (BEGIN) > ; SOURCE LINE # 39 > ; SOURCE LINE # 40 > ; SOURCE LINE # 41 >0000 7BFF MOV R3,#0FFH >0002 7A00 R MOV R2,#HIGH foo >0004 7900 R MOV R1,#LOW foo >;---- Variable 'f' assigned to Register 'R1/R2/R3' ---- > ; SOURCE LINE # 42 >0006 0100 E AJMP ?C?ICALL > ; FUNCTION bar (END)
So far the only complete listing was with the sdcc compiler. All the others either calls or jumps to a routine that does the actual function pointer call. It looks like different people also used different memory models. i.e whether XDATA or other memory is used by default. Regards Anton Erasmus
Anton Erasmus <nobody@spam.prevent.net> writes:

> On 16 Jun 2005 13:53:32 GMT, Richard <RichardRapier@netscape.net> > wrote: > >>Anton Erasmus <nobody@spam.prevent.net> wrote in >>news:1118919213.548a4ac2e2daba518c9bc56bdde53423@teranews: >> >>> void foo(void) >>> { >>> } >>> >>> void bar(void) >>> { >>> void (*f)(void) =foo; >>> f(); >>> } >>> > > So far the only complete listing was with the sdcc compiler. All the > others either calls or jumps to a routine that does the actual > function pointer call. It looks like different people also used > different memory models. i.e whether XDATA or other memory is used by > default.
sdcc doesn't handle function-local variables as well as one might like. I changed the code to: void foo (void) { } void (*f)(void) = foo; void bar (void) { f(); } and got: ;-------------------------------------------------------- ; File Created by SDCC : FreeWare ANSI-C Compiler ; Version 2.5.0 #1020 (Jun 15 2005) ; This file generated Thu Jun 16 21:37:42 2005 ;-------------------------------------------------------- .module b .optsdcc -mmcs51 --model-small [snipped defines] .area GSINIT (CODE) ;b.c:2: void (*f)(void) = foo; ; genAssign mov _f,#_foo mov (_f + 1),#(_foo >> 8) ;-------------------------------------------------------- .area CSEG (CODE) ;------------------------------------------------------------ ;Allocation info for local variables in function 'foo' ;------------------------------------------------------------ ;------------------------------------------------------------ ;b.c:1: void foo (void) { } ; ----------------------------------------- ; function foo ; ----------------------------------------- _foo: ar2 = 0x02 ar3 = 0x03 ar4 = 0x04 ar5 = 0x05 ar6 = 0x06 ar7 = 0x07 ar0 = 0x00 ar1 = 0x01 00101$: ret ;------------------------------------------------------------ ;Allocation info for local variables in function 'bar' ;------------------------------------------------------------ ;------------------------------------------------------------ ;b.c:4: void bar (void) { ; ----------------------------------------- ; function bar ; ----------------------------------------- _bar: ;b.c:5: f(); ; genPCall mov a,#00103$ push acc mov a,#(00103$ >> 8) push acc push _f push (_f + 1) ret 00103$: 00101$: ret .area CSEG (CODE) .area XINIT (CODE) sdcc doesn't handle cross-jumping optimisations, unfortunately, which is why it is pushing the label 00103$ onto the stack. <feels bug report coming on> cheers, Rich. -- rich walker | Shadow Robot Company | rw@shadow.org.uk technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml
"Rich Walker" <rw@shadow.org.uk> wrote in message 
news:m3br66jslo.fsf@shadow.org.uk...
<snip>
> -- > rich walker | Shadow Robot Company | rw@shadow.org.uk > technical director 251 Liverpool Road | > need a Hand? London N1 1LX | +UK 20 7700 2487 > www.shadow.org.uk/products/newhand.shtml
I have to say: that hand is funky! I've done quite a bit of work in control loops, mechatronics, microrobotics, and motor control, but nothing as downright jawdroppingly sexy as that. I wish you every success. (Although I have no idea where your market is ;) ). Psst: gissajob ;). Steve http://www.fivetrees.com
Chris Hills <chris@phaedsys.org> wrote:

>In article <1118843009.132766.10710@f14g2000cwb.googlegroups.com>, >cbarn24050@aol.com writes >> >>Arthur Richards wrote: >>> I'm finally moving up from assembler. Which compiler do you vote for? I can >>> probably get away with the Raisonance Lite version but should I shell out >>> the $'s & go for Keil or something else? >> >>As you must know the 8051 is a great processor for assembly programs >>but it's not so good for C. You can expect a tripleing, or even more, >>size of rom space, at least doubleng of ram space and a reduction in >>speed of 3to 10 times. > >This is completely incorrect. Due to the aggressive data overlaying etc >RAM space is often a lit less using the C compiler than using assembler.
Overlaid variables are static, so the code is not re-entrant. What kind of code would you get from an 8051 C compiler if you tried to compile a multi-threaded TCP/IP stack? (My guess: huge, slow, and ugly code; full of errors caused by compiler bugs.)
Chris Giese wrote:
> Chris Hills <chris@phaedsys.org> wrote: >
... snip ...
>> >> This is completely incorrect. Due to the aggressive data >> overlaying etc RAM space is often a lit less using the C >> compiler than using assembler. > > Overlaid variables are static, so the code is not re-entrant.
Not necessarily: void foo(void) { .... while (cond1) { int fee; .... } while (cond2) { int fum; .... } } fee and fum may well be overlaid in the automatic frame for foo. In fact I would expect the compiler to do so regardless of optimization level. Everything remains re-entrant. Of course the assembly programmer can do that too. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!
"Chris Giese" <NoEmailAds@execpc.com> wrote in message 
news:42b22c93.1391725@news.voyager.net...
> > What kind of code would you get from an 8051 C compiler if you > tried to compile a multi-threaded TCP/IP stack?
<flail>Warning, Will Robinson, warning - CPU/task mismatch! Warning! Bzeep!</flail> Steve http://www.fivetrees.com
"Steve at fivetrees" <steve@NOSPAMTAfivetrees.com> wrote in message 
news:EMWdnWLRzKeasS_fRVnyhA@pipex.net...
>> www.shadow.org.uk/products/newhand.shtml > > I have to say: that hand is funky!
Been watching the videos - very nicely done, sir. <tips hat> Just curious - how fast is it? Would it be able to cope with: http://www.fivetrees.com/images/lategroove2.wmv I can foresee a problem - guitar hammer-ons and pull-offs are not simply mechanical motions, but effectively string-plucking/striking motions... which require tactile and audio feedback to get right.... Please impress me further ;). Steve http://www.fivetrees.com

cbarn24050@aol.com wrote:

> Hi Richard, when I was using 8051s single chip meant 1k of eprom space. > Huge numbers of applications were written for chips that size back > then. Take a look at the 8052 chip with the basic interpreter in it, I > cant quite remeber if it was a 2 or 4k mask chip but you try writting > one with your C compiler and see what you come up with.
8751 = 4K 8752 = 8K I have done Projects from 2K to 24K. I inherited a 32K project that could be 25 to 50% smaller if it was not written like it was a PC. I have seen a 1K project. C has startup overhead, so a tiny project will look bigger. No all C compilers treat the '52 right. It is not C friendly. That is why Keil has been around so long, and others are gone.