8051 C Compiler Recommendation - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Really
snipped-for-privacy@aol.com wrote in news:1118905270.138877.207180
@g44g2000cwa.googlegroups.com:

Quoted text here. Click to load it

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

Re: Really
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.


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

Quoted text here. Click to load it

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

Re: Really



Quoted text here. Click to load it

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.



Re: Really
Quoted text here. Click to load it

I would agree with this. Also RAM usage will drop. I knew of 1 program
that went from 125 bytes of RAM in assembler to 19 in C because of the
data overlaying. IT was all pulled into Data space and therefore there
was a speed increase.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: Really

Quoted text here. Click to load it

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();
}

Regards
   Anton Erasmus




Re: Really
Quoted text here. Click to load it

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



Re: Really

Quoted text here. Click to load it

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


Re: Really

Quoted text here. Click to load it
[snip code]
Quoted text here. Click to load it

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 | snipped-for-privacy@shadow.org.uk
technical director     251 Liverpool Road   |
We've slightly trimmed the long signature. Click to see the full one.
funky robot (was Re: Really)
<snip>
Quoted text here. Click to load it

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




Re: funky robot (was Re: Really)
Quoted text here. Click to load it

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



Re: funky robot

Quoted text here. Click to load it

I'll pass that on to the engineers. (Gentlemen: take a bow!)

Quoted text here. Click to load it

Now my engineers will spend the entire day on this one :-<

Quoted text here. Click to load it

The tactile sensing isn't bad: the primary limitations are the PIC16
scanning the tactile array, and the characteristics of the surface
material.

Movement speed: well, the limitation there (as ever with muscles) is
getting the air in and out: we're using some Lee LHDA-24xxxx valves,
which are pretty d'd small, (see Lee's press stuff with our Hand holding
one of their valves for the obvious quotes) and do slightly limit the
rate of movement.

The kind of movement we're aiming for is "quality normal human" rather
than "Rachmaninoff". I've seen robot hands that can move very very fast,
and they tend to have two major problems: they break things, and they
wear out.

cheers, Rich.

--
rich walker         |  Shadow Robot Company | snipped-for-privacy@shadow.org.uk
technical director     251 Liverpool Road   |
We've slightly trimmed the long signature. Click to see the full one.
Re: Really
On Thu, 16 Jun 2005 13:22:53 +0200, "Meindert Sprang"

Quoted text here. Click to load it

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


Re: Really

Quoted text here. Click to load it

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

Re: Really

Quoted text here. Click to load it

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


Re: Really

Quoted text here. Click to load it

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 | snipped-for-privacy@shadow.org.uk
technical director     251 Liverpool Road   |
We've slightly trimmed the long signature. Click to see the full one.
Re: Really



Quoted text here. Click to load it
can
Quoted text here. Click to load it

About as much as it would in asm.  a function point on the 8052 in Keil can be
tricky.
Unless you do it right the compiler can not overlay it.  So it will use more RAM.
Function parameters are not pushed on to the "stack"
again 8051 != PC.

If you write for a PC, then complain it is too big, then goto ASM.
well do not complain your foot hurts after you shot you self in it.





Re: Really

Quoted text here. Click to load it
can
Quoted text here. Click to load it
RAM.
Quoted text here. Click to load it

Often the reason for using C on a '51 is so that one can use the code
on other projects and MCUs as well. The '51 is not a PC, but neither
is something like an AVR. I have used avr-gcc to write code for a 2K
FLASH,  128 bytes RAM AVR which runs fine and uses about 60% of the
available RAM. The same code compiled to about 3K on the '51 and I
needed a  '52 to get it to run. (i.e. 128 bytes was not enough, I
needed the 256 bytes of the '52)
The code on the '51 was sub-optimal (Reasonably standard C used), but
was quite optimal on an AVR as well as on a PC.
Most PC coders run into problems because their code style assumes lots
of RAM. 64K of RAM is considered insignificant. As long as one
considers the small amount of RAM and program space one often have
when writing for a MCU, one should be able to write reasonably normal
C, and expect the compiler to generate reasonable code. The same code
should be reasonably optimal on a big system such as a PC as well.

Regards
  Anton Erasmus


Re: 8051 C Compiler Recommendation
snipped-for-privacy@aol.com writes
Quoted text here. Click to load it

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.

The C is a little less compact but mush easier to test and prove. There
is no Lint for assembler.

Quoted text here. Click to load it

AVR possibly but not PIC18. However why change processor and all the
tools when all the OP wants to do is move from asm to C onthe same
processor.

Quoted text here. Click to load it

I would not bother with anything 16 bit now. Go for ARM if the 8051 is
not powerful enough. Apart from specialit parts the 16 bit market will
disappear soon.


--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: 8051 C Compiler Recommendation
Quoted text here. Click to load it
<snip>
Quoted text here. Click to load it

That's not quite true - the market for "traditional" 16-bit processors
is getting squeezed out by faster 8-bitters and smaller, cheaper
32-bitters, but there are 16-bit micros that have very clear markets
with plenty of growth.  The msp430 family in particular is like a solid
8-bit microcontroller, except that it has a 16-bit core, which is far
more "C-friendly" than 8-bit cores.

Site Timeline