8051 C Compiler Recommendation

I cannot vouch for Keil, but Raisonance produces this:

ASSEMBLY LISTING OF GENERATED OBJECT CODE

; FUNCTION foo (BEGIN) ; SOURCE LINE # 3

0000 22 RET

; FUNCTION foo (END)

; FUNCTION main (BEGIN) ; R2R3 is assigned to f ; SOURCE LINE # 8

0000 758300 R MOV DPH,#HIGH (foo) 0003 758200 R MOV DPL,#LOW (foo) 0006 120000 R LCALL ?C_INDCALL ; SOURCE LINE # 9 0009 22 RET

; FUNCTION main (END)

And the resulting hex file contains 34 bytes of code while the same "program" without the call to foo compiles into 23 bytes. So this function pointer call produces 11 bytes. Compact enough ? :-)) (and all that for a 400 euro compiler).

Meindert

Reply to
Meindert Sprang
Loading thread data ...

That is a sentence fragment, and is incorrectly punctuated. If it were C it would not compile, would it.

That is also a sentence fragment, and seems to have a hanging apostrophe as well as no correct punctuation. It wouldn't compile either, would it?

"Them" is indeed plural, but there is potentially only one trial, so if you take the meaning from the structure of the sentence, rather than your expectation of the meaning of the sentence, it's gramatically pretty well correct, albeit clumsy.

If you're going to throw stones it's really not a good idea to do it from a glass house, is it?

--
Nobby
Reply to
Nobody Here

Thank you for reminding me why I don't participate in groups.

Reply to
ssc

Here's Keil's version

ASSEMBLY LISTING OF GENERATED OBJECT CODE

; FUNCTION foo (BEGIN) ; SOURCE LINE # 1 ; SOURCE LINE # 2 ; SOURCE LINE # 3

0000 22 RET ; FUNCTION foo (END)

; FUNCTION bar (BEGIN) ; SOURCE LINE # 5 ; SOURCE LINE # 6 ; SOURCE LINE # 7

0000 7A00 R MOV R2,#HIGH foo 0002 7900 R MOV R1,#LOW foo ;---- Variable 'f' assigned to Register 'R1/R2/R3' ---- ; SOURCE LINE # 8 0004 0100 E AJMP ?C?ICALL ; FUNCTION bar (END)

Bob

Reply to
Bob Stephens

Anton Erasmus wrote in news:1118919213.548a4ac2e2daba518c9bc56bdde53423@teranews:

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)
--
Richard
Reply to
Richard

snipped-for-privacy@aol.com wrote in news:1118905270.138877.207180 @g44g2000cwa.googlegroups.com:

With a good C compiler, Kiel for example, ram usage will typically drop significantly due to overlaying variables, and the code produced is actually quite decent. Sure, I could handcraft better by spending a lot of time at it, and likely end up with code that is noticably harder for someone else to come along and modify later on.

For the types of projects I have done, I have found Kiel C in particular to work perfectly for the applications, Single chip apps, with 8k to 16k of flash memory on board for the code.

--
Richard
Reply to
Richard

ssc@remove_me.copelandelectronics.com wrote in news:xxese.40822$JX5.22482 @tornado.ohiordc.rr.com:

killfiles work wonders if someone becomes a nuisance.

--
Richard
Reply to
Richard

[snip code]

I tried the same thing on sdcc for fun.

Options: -mmcs51 --peep-asm

Relevant code:

;------------------------------------------------------------ ;a.c:1: void foo (void) ; ----------------------------------------- ; function foo ; ----------------------------------------- _foo: ar2 = 0x02 ar3 = 0x03 ar4 = 0x04 ar5 = 0x05 ar6 = 0x06 ar7 = 0x07 ar0 = 0x00 ar1 = 0x01 ;a.c:3: }

00101$: ret ;------------------------------------------------------------ ;Allocation info for local variables in function 'bar' ;------------------------------------------------------------ ;f Allocated to registers r2 r3 ;------------------------------------------------------------ ;a.c:5: void bar (void) ; ----------------------------------------- ; function bar ; ----------------------------------------- _bar: ;a.c:7: void (*f) (void) = foo; ; genAssign mov r2,#_foo mov r3,#(_foo >> 8) ;a.c:8: f(); ; genPCall push ar2 push ar3 mov a,#00103$ push acc mov a,#(00103$ >> 8) push acc push ar2 push ar3 ret 00103$: pop ar3 pop ar2 00101$: ret

So not quite up there. Mind you, the code it generates for function pointers on a PIC looks pretty similar.

cheers, Rich.

--
rich walker         |  Shadow Robot Company | rw@shadow.org.uk
technical director     251 Liverpool Road   |
 Click to see the full signature
Reply to
Rich Walker

So what code is in the C_INDCALL routine ? The code above only loads the function address into DP, and the actual function call is done by a subroutine. It would also be interesting to know whether such a function call routine is thread safe.

Regards Anton Erasmus

Reply to
Anton Erasmus

There is a way to get the most out of newsgroups that works well, and another way that has never worked no matter how many people have tried it.

What works: Post articles on the topic you wish to see discussed, and participate in the resulting discussion. Use killfiles and filters so that you don't see the articles/posters that you dislike. If you don't know how to use a killfile, use good old fashioned discipline and don't read the articles that you dislike. Never, ever respond to articles that you dislike.

What doesn't work: Respond to articles that you dislike, complain about articles that you dislike, complain about posters that you dislike, complain about how terrible everyone else is for not posting what you want them to post. Talk about how to respond to articles that you dislike. Make the articles that you dislike the center of attention and the main topic of discussion.

Reply to
Guy Macon

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.

Reply to
cbarn24050

Any comments regarding how the Tasking Compiler performs against the Keil compiler?

- Richard.W

Reply to
Richard Willis

snipped-for-privacy@aol.com wrote in news:1118943135.615480.114050 @g47g2000cwa.googlegroups.com:

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
Reply to
Richard

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

Reply to
Anton Erasmus

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.

cheers, Rich.

--
rich walker         |  Shadow Robot Company | rw@shadow.org.uk
technical director     251 Liverpool Road   |
 Click to see the full signature
Reply to
Rich Walker

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

formatting link

Reply to
Steve at fivetrees

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.)

Reply to
Chris Giese

... snip ...

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.
 Click to see the full signature
Reply to
CBFalconer

Warning, Will Robinson, warning - CPU/task mismatch! Warning! Bzeep!

Steve

formatting link

Reply to
Steve at fivetrees

Been watching the videos - very nicely done, sir.

Just curious - how fast is it? Would it be able to cope with:

formatting link

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

formatting link

Reply to
Steve at fivetrees

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.