8051 C Compiler Recommendation

On Wed, 15 Jun 2005 19:33:41 +0000, Ian Bell wrote:
> ssc@remove_me.copelandelectronics.com wrote:
>
> I hope your software is better than your English grammar.
>
>> Take a look here....I use they're compilers 
>
> 'their' compilers - possessive

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

>> for 8051 and pic almost 
>> daily....I also sell them, so I'm only a little biased :->.  They do have
>> demo's 
>
> 'demos - plural of demo not possesive as implied by the apostrophe

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?

>> on their site.  
>
>> You can try them out and see how it works for you.  
>> 
>
> 'try them' plural - and 'see how it works' - singular

"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

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

On Thu, 16 Jun 2005 13:22:53 +0200, Meindert Sprang wrote:

> "Anton Erasmus" <nobody@spam.prevent.net> wrote in message
> news:1118919213.548a4ac2e2daba518c9bc56bdde53423@teranews...
>> It has been a while since I have used an 8051 with C. (Old IAR
>> Compiler V4.x). This compiler generated more than a page (50 lines per
>> page) of assembler to implement a call through a function pointer.
>> How much code does a modern Keil compiler generate for a simple
>> void, void function pointer call ? i.e.
>>
>> void foo(void)
>> {
>> }
>>
>> void bar(void)
>> {
>>    void (*f)(void) =foo;
>>    f();
>> }
>>
> 
> 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

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

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)

-- 
Richard

cbarn24050@aol.com wrote in news:1118905270.138877.207180
@g44g2000cwa.googlegroups.com:

> Hi Niel, it is very dependent on what you are doing. You will notice
> the biggest difference on the small jobs ie. single chip apps. Have you
> ever done a comparason? I have, not with the Kiel it's true but then I
> stopped using 8051's at least 8 years ago maybe longer. If you would
> like to write one of my small projects from back then just to see I'll
> be happy to give you details.
> 

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

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

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

killfiles work wonders if someone becomes a nuisance.

-- 
Richard

"Meindert Sprang" <mhsprang@NOcustomSPAMware.nl> writes:

> "Anton Erasmus" <nobody@spam.prevent.net> wrote in message
> news:1118919213.548a4ac2e2daba518c9bc56bdde53423@teranews...
>> It has been a while since I have used an 8051 with C. (Old IAR
>> Compiler V4.x). This compiler generated more than a page (50 lines per
>> page) of assembler to implement a call through a function pointer.
>> How much code does a modern Keil compiler generate for a simple
>> void, void function pointer call ? i.e.
>>
>> void foo(void)
>> {
>> }
>>
>> void bar(void)
>> {
>>    void (*f)(void) =foo;
>>    f();
>> }
>>
[snip code] 
> 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).

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   |
need a Hand?           London  N1 1LX       | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml

On Thu, 16 Jun 2005 13:22:53 +0200, "Meindert Sprang"
<mhsprang@NOcustomSPAMware.nl> wrote:

>"Anton Erasmus" <nobody@spam.prevent.net> wrote in message
>news:1118919213.548a4ac2e2daba518c9bc56bdde53423@teranews...
>> It has been a while since I have used an 8051 with C. (Old IAR
>> Compiler V4.x). This compiler generated more than a page (50 lines per
>> page) of assembler to implement a call through a function pointer.
>> How much code does a modern Keil compiler generate for a simple
>> void, void function pointer call ? i.e.
>>
>> void foo(void)
>> {
>> }
>>
>> void bar(void)
>> {
>>    void (*f)(void) =foo;
>>    f();
>> }
>>
>
>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).

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

ssc@remove_me.copelandelectronics.com wrote:

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

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.

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.