Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Alternatives to SDCC
24-06-2011, 08:49 PM, (This post was last modified: 24-06-2011, 08:52 PM by funlw65.)
#1
Alternatives to SDCC
Have anyone evaluated recently cpik 0.5.2 ((the C compiler for PIC18 devices)) of Alain Gibaud?

Unlike SDCC, cpik is specially designed for PIC18F microcontrollers.
Recently, I had a discussion with Alain with the subject being: "cpik versus SDCC".
His response was:

Quote:First of all, sdcc is very mature compiler, composed from a front-end
(source parsing and analysis) and a back-end (code generation for a given
target processor). It supports all integer data-types and 32 bit IEEE754
floating point.

From my point of view, the front-end part is very good. It is ANSI conformant
and performs good global optimisation and detect things like non-used or
non-initialised variables, etc..

For example, consider this simple code

int main()
{
int32_t x ;

x = 22 ;

return x ;
}

cpik generates exactly the machine code corresponding to the source code :
variable allocation (on the stack), variable affectation, and return of the
value (casted to appropriate type).

;<+C18_main> int main()
C18_main
movf PREINC0,F,0 ; reserve stack
movf PREINC0,F,0 ; reserve stack
movf PREINC0,F,0 ; reserve stack
movf PREINC0,F,0 ; reserve stack
; int32_t x ;
;
; x = 22 ;
movlw 22
movwf PREINC0,0
movlw -3
movff POSTDEC0,PLUSW0
movlw -2
clrf PLUSW0,0
movlw -1
clrf PLUSW0,0
clrf INDF0,0
;
; return x ;
movlw -3
movff PLUSW0,R0
; }
L18_main_0
movf POSTDEC0,F,0 ; clean stack
movf POSTDEC0,F,0 ; clean stack
movf POSTDEC0,F,0 ; clean stack
movf POSTDEC0,F,0 ; clean stack
return 0
;<-> int main()
END

sdcc generates a really nicer code because it performs value tracking: since x
is never modified nor used (excepted in the return statement), it generates a
simple "return 22;" statement.

S_main2__main code
_main:
; .line 31; main2.c return x ;
CLRF PRODL
MOVLW 0x16
RETURN

But things are not as simple as this school example.

The back-end for pic18 processors is derived from the back-end for pic16
processors.
This part is very bad because is is a hack that try to push the pic18 device
into a frame
that was designed for pic16. Unfortunatly, the pic18 design includes powerful
features
such as deep stack, and indirect, auto incremented or indexed addressing
modes.
These features are not used, or misused.
The management of the data stack (that is the base of a correct C
implementation)
is horrible.

Here is an example (int32_t is a 32 bit signed integer type) :

int32_t arith32( int32_t a, int32_t b, int32_t c)
{
return a * b / c ;
}

The sdcc code:

S_main__arith32 code
_arith32:
; .line 25; main.c int32_t arith32( int32_t a, int32_t b, int32_t c)
MOVFF FSR2H, POSTDEC1
MOVFF FSR2L, POSTDEC1
MOVFF FSR1H, FSR2H
MOVFF FSR1L, FSR2L
MOVFF r0x00, POSTDEC1
MOVFF r0x01, POSTDEC1
MOVFF r0x02, POSTDEC1
MOVFF r0x03, POSTDEC1
MOVFF r0x04, POSTDEC1
MOVFF r0x05, POSTDEC1
MOVFF r0x06, POSTDEC1
MOVFF r0x07, POSTDEC1
MOVFF r0x08, POSTDEC1
MOVFF r0x09, POSTDEC1
MOVFF r0x0a, POSTDEC1
MOVFF r0x0b, POSTDEC1
MOVLW 0x03
MOVFF PLUSW2, r0x00
MOVLW 0x04
MOVFF PLUSW2, r0x01
MOVLW 0x05
MOVFF PLUSW2, r0x02
MOVLW 0x06
MOVFF PLUSW2, r0x03
MOVLW 0x07
MOVFF PLUSW2, r0x04
MOVLW 0x08
MOVFF PLUSW2, r0x05
MOVLW 0x09
MOVFF PLUSW2, r0x06
MOVLW 0x0a
MOVFF PLUSW2, r0x07
MOVLW 0x0b
MOVFF PLUSW2, r0x08
MOVLW 0x0c
MOVFF PLUSW2, r0x09
MOVLW 0x0d
MOVFF PLUSW2, r0x0a
MOVLW 0x0e
MOVFF PLUSW2, r0x0b
; .line 27; main.c return a * b / c ;
MOVF r0x07, W
MOVWF POSTDEC1
MOVF r0x06, W
MOVWF POSTDEC1
MOVF r0x05, W
MOVWF POSTDEC1
MOVF r0x04, W
MOVWF POSTDEC1
MOVF r0x03, W
MOVWF POSTDEC1
MOVF r0x02, W
MOVWF POSTDEC1
MOVF r0x01, W
MOVWF POSTDEC1
MOVF r0x00, W
MOVWF POSTDEC1
CALL __mullong
MOVWF r0x00
MOVFF PRODL, r0x01
MOVFF PRODH, r0x02
MOVFF FSR0L, r0x03
MOVLW 0x08
ADDWF FSR1L, F
BTFSC STATUS, 0
INCF FSR1H, F
MOVF r0x0b, W
MOVWF POSTDEC1
MOVF r0x0a, W
MOVWF POSTDEC1
MOVF r0x09, W
MOVWF POSTDEC1
MOVF r0x08, W
MOVWF POSTDEC1
MOVF r0x03, W
MOVWF POSTDEC1
MOVF r0x02, W
MOVWF POSTDEC1
MOVF r0x01, W
MOVWF POSTDEC1
MOVF r0x00, W
MOVWF POSTDEC1
CALL __divslong
MOVWF r0x00
MOVFF PRODL, r0x01
MOVFF PRODH, r0x02
MOVFF FSR0L, r0x03
MOVLW 0x08
ADDWF FSR1L, F
BTFSC STATUS, 0
INCF FSR1H, F
MOVFF r0x03, FSR0L
MOVFF r0x02, PRODH
MOVFF r0x01, PRODL
MOVF r0x00, W
MOVFF PREINC1, r0x0b
MOVFF PREINC1, r0x0a
MOVFF PREINC1, r0x09
MOVFF PREINC1, r0x08
MOVFF PREINC1, r0x07
MOVFF PREINC1, r0x06
MOVFF PREINC1, r0x05
MOVFF PREINC1, r0x04
MOVFF PREINC1, r0x03
MOVFF PREINC1, r0x02
MOVFF PREINC1, r0x01
MOVFF PREINC1, r0x00
MOVFF PREINC1, FSR2L
MOVFF PREINC1, FSR2H
RETURN

The reason why this code is awful is clearly visible: sdcc alway try to
perform calculation on "global" variables (r0x00 to r0x0b)
so it saves the values of these variables on to the stack. Then, it copies the
parameters to r0x00 .. r0x0b and perform the calculations.
Then the saved values are written back to r0x00 .. r0x0b. 124 bytes of code
are needed BEFORE any useful calculation, and the total size of this code is
302 bytes.

Now, here is the code generated by cpik

;<+C18_arith32> long32 arith32(long32 a@8,long32 b@4,long32 c@0)
C18_arith32
; return a * b / c ;
movlw -3
movff PLUSW0,PREINC0
movff PLUSW0,PREINC0
movff PLUSW0,PREINC0
movff PLUSW0,PREINC0
movlw -11
movff PLUSW0,R0+0
movlw -10
movff PLUSW0,R0+1
movlw -9
movff PLUSW0,R0+2
movlw -8
movff PLUSW0,R0+3
ICALL mul32
movlw -15
movff PLUSW0,R0+0
movlw -14
movff PLUSW0,R0+1
movlw -13
movff PLUSW0,R0+2
movlw -12
movff PLUSW0,R0+3
ICALL div32
movff POSTDEC0,R0+3
movff POSTDEC0,R0+2
movff POSTDEC0,R0+1
movff POSTDEC0,R0+0
; }
L18_arith32_0
return 0

This code is 46 bytes long !! The code from cpik is not extraordinary, but
uses a consistant scheme for calculation, and uses all the addressing modes
allowed by the processor to make the job directly on the stack.
cpik perform optimization ion a "per-instruction" basis, that is sufficient to
produce a good code.
Both codes use library routines for 32 bit arithmetics.


You will find attached a source code with variaous tests, (main.c)
and the corresponding output from sdcc (main.asm) and from cpik (main.slb).
I suppose you will be able to make your own opinion.

Another lack of sdcc is about structs: Just consider this code (vector add).

typedef struct vec
{
int16_t x,y ;
} vec ;

vec add(vec a, vec b)
{
vec c ;
c.x = a.x+b.x ;
c.y = a.y+b.y ;
return c ;
}

cpik generates the following:

;<+C18_add> struct vec add(struct vec @4,struct vec @0)
C18_add
movf PREINC0,F,0 ; reserve stack
movf PREINC0,F,0 ; reserve stack
movf PREINC0,F,0 ; reserve stack
movf PREINC0,F,0 ; reserve stack
; vec c ;
; c.x = a.x+b.x ;
movlw -7
movff PLUSW0,PREINC0
movff PLUSW0,PREINC0
movlw -13
movff PLUSW0,R0+0
movlw -12
movff PLUSW0,R0+1
ICALL add16
movlw -3
movff POSTDEC0,PLUSW0
movff POSTDEC0,PLUSW0
; c.y = a.y+b.y ;
movlw -5
movff PLUSW0,PREINC0
movff PLUSW0,PREINC0
movlw -11
movff PLUSW0,R0+0
movlw -10
movff PLUSW0,R0+1
ICALL add16
movlw -1
movff POSTDEC0,PLUSW0
movff POSTDEC0,PLUSW0
; return c ;
movlw -3
movff PLUSW0,R0+0
movlw -2
movff PLUSW0,R0+1
movlw -1
movff PLUSW0,R0+2
movff INDF0,R0+3
; }
L18_add_0
movf POSTDEC0,F,0 ; clean stack
movf POSTDEC0,F,0 ; clean stack
movf POSTDEC0,F,0 ; clean stack
movf POSTDEC0,F,0 ; clean stack
return 0
;<?add16>
;<-> struct vec add(struct vec @4,struct vec @0)

But sdcc fails to compile with the message :

gibaud@taw:~/cpik052/benchmark/p1$ sdcc -S --pstack-model=large -mpic16 main.c
main.c:35: warning 97: structure '_a' passed as function argument changed to
pointer
main.c:35: warning 97: structure '_b' passed as function argument changed to
pointer
main.c:35: error 54: Function cannot return aggregate. Func body ignored

With sdcc you can pass a struct to a function but the standard "pass by value"
semantics is not honoured
because sdcc pass a pointer to structure. Anyway, in the example, the "return
c" fails with a great number of error messages.


Well, sdcc can do thing that cpik does not support :

-switch statement
-FP calculation
-bit variables

You will find in main.c an example of switch statement that needs 121 bytes
for sdcc, and only 60 for cpik, with code based on a simple if statement.

I cannot predict when FP and switch will be available with cpik, because I am
really busy (many very different projects, and a job, and a family). The
design is ready, but the implementation waits since more than one year.

Another difference is about linker: cpik and sdcc are very differents, but
both work correctly.

Hope it will respond to your questions.

There were some attachments but i don't know how to add them here.
Reply
28-06-2011, 06:36 PM,
#2
RE: Alternatives to SDCC
Not yet.
Maybe someone can give it a try.
The first job will be to write a tiny bootloader.
Do you want to do that Vasi ?


(24-06-2011, 08:49 PM)funlw65 Wrote: Have anyone evaluated recently cpik 0.5.2 ((the C compiler for PIC18 devices)) of Alain Gibaud?

Unlike SDCC, cpik is specially designed for PIC18F microcontrollers.
Recently, I had a discussion with Alain with the subject being: "cpik versus SDCC".
His response was:

Quote:First of all, sdcc is very mature compiler, composed from a front-end
(source parsing and analysis) and a back-end (code generation for a given
target processor). It supports all integer data-types and 32 bit IEEE754
floating point.

From my point of view, the front-end part is very good. It is ANSI conformant
and performs good global optimisation and detect things like non-used or
non-initialised variables, etc..

For example, consider this simple code

int main()
{
int32_t x ;

x = 22 ;

return x ;
}

cpik generates exactly the machine code corresponding to the source code :
variable allocation (on the stack), variable affectation, and return of the
value (casted to appropriate type).

;<+C18_main> int main()
C18_main
movf PREINC0,F,0 ; reserve stack
movf PREINC0,F,0 ; reserve stack
movf PREINC0,F,0 ; reserve stack
movf PREINC0,F,0 ; reserve stack
; int32_t x ;
;
; x = 22 ;
movlw 22
movwf PREINC0,0
movlw -3
movff POSTDEC0,PLUSW0
movlw -2
clrf PLUSW0,0
movlw -1
clrf PLUSW0,0
clrf INDF0,0
;
; return x ;
movlw -3
movff PLUSW0,R0
; }
L18_main_0
movf POSTDEC0,F,0 ; clean stack
movf POSTDEC0,F,0 ; clean stack
movf POSTDEC0,F,0 ; clean stack
movf POSTDEC0,F,0 ; clean stack
return 0
;<-> int main()
END

sdcc generates a really nicer code because it performs value tracking: since x
is never modified nor used (excepted in the return statement), it generates a
simple "return 22;" statement.

S_main2__main code
_main:
; .line 31; main2.c return x ;
CLRF PRODL
MOVLW 0x16
RETURN

But things are not as simple as this school example.

The back-end for pic18 processors is derived from the back-end for pic16
processors.
This part is very bad because is is a hack that try to push the pic18 device
into a frame
that was designed for pic16. Unfortunatly, the pic18 design includes powerful
features
such as deep stack, and indirect, auto incremented or indexed addressing
modes.
These features are not used, or misused.
The management of the data stack (that is the base of a correct C
implementation)
is horrible.

Here is an example (int32_t is a 32 bit signed integer type) :

int32_t arith32( int32_t a, int32_t b, int32_t c)
{
return a * b / c ;
}

The sdcc code:

S_main__arith32 code
_arith32:
; .line 25; main.c int32_t arith32( int32_t a, int32_t b, int32_t c)
MOVFF FSR2H, POSTDEC1
MOVFF FSR2L, POSTDEC1
MOVFF FSR1H, FSR2H
MOVFF FSR1L, FSR2L
MOVFF r0x00, POSTDEC1
MOVFF r0x01, POSTDEC1
MOVFF r0x02, POSTDEC1
MOVFF r0x03, POSTDEC1
MOVFF r0x04, POSTDEC1
MOVFF r0x05, POSTDEC1
MOVFF r0x06, POSTDEC1
MOVFF r0x07, POSTDEC1
MOVFF r0x08, POSTDEC1
MOVFF r0x09, POSTDEC1
MOVFF r0x0a, POSTDEC1
MOVFF r0x0b, POSTDEC1
MOVLW 0x03
MOVFF PLUSW2, r0x00
MOVLW 0x04
MOVFF PLUSW2, r0x01
MOVLW 0x05
MOVFF PLUSW2, r0x02
MOVLW 0x06
MOVFF PLUSW2, r0x03
MOVLW 0x07
MOVFF PLUSW2, r0x04
MOVLW 0x08
MOVFF PLUSW2, r0x05
MOVLW 0x09
MOVFF PLUSW2, r0x06
MOVLW 0x0a
MOVFF PLUSW2, r0x07
MOVLW 0x0b
MOVFF PLUSW2, r0x08
MOVLW 0x0c
MOVFF PLUSW2, r0x09
MOVLW 0x0d
MOVFF PLUSW2, r0x0a
MOVLW 0x0e
MOVFF PLUSW2, r0x0b
; .line 27; main.c return a * b / c ;
MOVF r0x07, W
MOVWF POSTDEC1
MOVF r0x06, W
MOVWF POSTDEC1
MOVF r0x05, W
MOVWF POSTDEC1
MOVF r0x04, W
MOVWF POSTDEC1
MOVF r0x03, W
MOVWF POSTDEC1
MOVF r0x02, W
MOVWF POSTDEC1
MOVF r0x01, W
MOVWF POSTDEC1
MOVF r0x00, W
MOVWF POSTDEC1
CALL __mullong
MOVWF r0x00
MOVFF PRODL, r0x01
MOVFF PRODH, r0x02
MOVFF FSR0L, r0x03
MOVLW 0x08
ADDWF FSR1L, F
BTFSC STATUS, 0
INCF FSR1H, F
MOVF r0x0b, W
MOVWF POSTDEC1
MOVF r0x0a, W
MOVWF POSTDEC1
MOVF r0x09, W
MOVWF POSTDEC1
MOVF r0x08, W
MOVWF POSTDEC1
MOVF r0x03, W
MOVWF POSTDEC1
MOVF r0x02, W
MOVWF POSTDEC1
MOVF r0x01, W
MOVWF POSTDEC1
MOVF r0x00, W
MOVWF POSTDEC1
CALL __divslong
MOVWF r0x00
MOVFF PRODL, r0x01
MOVFF PRODH, r0x02
MOVFF FSR0L, r0x03
MOVLW 0x08
ADDWF FSR1L, F
BTFSC STATUS, 0
INCF FSR1H, F
MOVFF r0x03, FSR0L
MOVFF r0x02, PRODH
MOVFF r0x01, PRODL
MOVF r0x00, W
MOVFF PREINC1, r0x0b
MOVFF PREINC1, r0x0a
MOVFF PREINC1, r0x09
MOVFF PREINC1, r0x08
MOVFF PREINC1, r0x07
MOVFF PREINC1, r0x06
MOVFF PREINC1, r0x05
MOVFF PREINC1, r0x04
MOVFF PREINC1, r0x03
MOVFF PREINC1, r0x02
MOVFF PREINC1, r0x01
MOVFF PREINC1, r0x00
MOVFF PREINC1, FSR2L
MOVFF PREINC1, FSR2H
RETURN

The reason why this code is awful is clearly visible: sdcc alway try to
perform calculation on "global" variables (r0x00 to r0x0b)
so it saves the values of these variables on to the stack. Then, it copies the
parameters to r0x00 .. r0x0b and perform the calculations.
Then the saved values are written back to r0x00 .. r0x0b. 124 bytes of code
are needed BEFORE any useful calculation, and the total size of this code is
302 bytes.

Now, here is the code generated by cpik

;<+C18_arith32> long32 arith32(long32 a@8,long32 b@4,long32 c@0)
C18_arith32
; return a * b / c ;
movlw -3
movff PLUSW0,PREINC0
movff PLUSW0,PREINC0
movff PLUSW0,PREINC0
movff PLUSW0,PREINC0
movlw -11
movff PLUSW0,R0+0
movlw -10
movff PLUSW0,R0+1
movlw -9
movff PLUSW0,R0+2
movlw -8
movff PLUSW0,R0+3
ICALL mul32
movlw -15
movff PLUSW0,R0+0
movlw -14
movff PLUSW0,R0+1
movlw -13
movff PLUSW0,R0+2
movlw -12
movff PLUSW0,R0+3
ICALL div32
movff POSTDEC0,R0+3
movff POSTDEC0,R0+2
movff POSTDEC0,R0+1
movff POSTDEC0,R0+0
; }
L18_arith32_0
return 0

This code is 46 bytes long !! The code from cpik is not extraordinary, but
uses a consistant scheme for calculation, and uses all the addressing modes
allowed by the processor to make the job directly on the stack.
cpik perform optimization ion a "per-instruction" basis, that is sufficient to
produce a good code.
Both codes use library routines for 32 bit arithmetics.


You will find attached a source code with variaous tests, (main.c)
and the corresponding output from sdcc (main.asm) and from cpik (main.slb).
I suppose you will be able to make your own opinion.

Another lack of sdcc is about structs: Just consider this code (vector add).

typedef struct vec
{
int16_t x,y ;
} vec ;

vec add(vec a, vec b)
{
vec c ;
c.x = a.x+b.x ;
c.y = a.y+b.y ;
return c ;
}

cpik generates the following:

;<+C18_add> struct vec add(struct vec @4,struct vec @0)
C18_add
movf PREINC0,F,0 ; reserve stack
movf PREINC0,F,0 ; reserve stack
movf PREINC0,F,0 ; reserve stack
movf PREINC0,F,0 ; reserve stack
; vec c ;
; c.x = a.x+b.x ;
movlw -7
movff PLUSW0,PREINC0
movff PLUSW0,PREINC0
movlw -13
movff PLUSW0,R0+0
movlw -12
movff PLUSW0,R0+1
ICALL add16
movlw -3
movff POSTDEC0,PLUSW0
movff POSTDEC0,PLUSW0
; c.y = a.y+b.y ;
movlw -5
movff PLUSW0,PREINC0
movff PLUSW0,PREINC0
movlw -11
movff PLUSW0,R0+0
movlw -10
movff PLUSW0,R0+1
ICALL add16
movlw -1
movff POSTDEC0,PLUSW0
movff POSTDEC0,PLUSW0
; return c ;
movlw -3
movff PLUSW0,R0+0
movlw -2
movff PLUSW0,R0+1
movlw -1
movff PLUSW0,R0+2
movff INDF0,R0+3
; }
L18_add_0
movf POSTDEC0,F,0 ; clean stack
movf POSTDEC0,F,0 ; clean stack
movf POSTDEC0,F,0 ; clean stack
movf POSTDEC0,F,0 ; clean stack
return 0
;<?add16>
;<-> struct vec add(struct vec @4,struct vec @0)

But sdcc fails to compile with the message :

gibaud@taw:~/cpik052/benchmark/p1$ sdcc -S --pstack-model=large -mpic16 main.c
main.c:35: warning 97: structure '_a' passed as function argument changed to
pointer
main.c:35: warning 97: structure '_b' passed as function argument changed to
pointer
main.c:35: error 54: Function cannot return aggregate. Func body ignored

With sdcc you can pass a struct to a function but the standard "pass by value"
semantics is not honoured
because sdcc pass a pointer to structure. Anyway, in the example, the "return
c" fails with a great number of error messages.


Well, sdcc can do thing that cpik does not support :

-switch statement
-FP calculation
-bit variables

You will find in main.c an example of switch statement that needs 121 bytes
for sdcc, and only 60 for cpik, with code based on a simple if statement.

I cannot predict when FP and switch will be available with cpik, because I am
really busy (many very different projects, and a job, and a family). The
design is ready, but the implementation waits since more than one year.

Another difference is about linker: cpik and sdcc are very differents, but
both work correctly.

Hope it will respond to your questions.

There were some attachments but i don't know how to add them here.

It is easier to complain than it is to do, but it is better to do than it is to complain.
Reply
28-06-2011, 09:24 PM,
#3
RE: Alternatives to SDCC
(28-06-2011, 06:36 PM)regis Wrote: Not yet.
Maybe someone can give it a try.
The first job will be to write a tiny bootloader.
Do you want to do that Vasi ?

Hi Regis,
What kind of bootloader? An USB one is already written in Jal language (2Kb)... is not good enough? AFAIK, SDCC have problems in relocating the code for an USB Bootloader... (one of the reasons I think we need an alternative to SDCC).

Vasi
Reply
07-10-2011, 02:46 AM, (This post was last modified: 07-10-2011, 02:50 AM by funlw65.)
#4
RE: Alternatives to SDCC
Excellent news guys,

Things started to move again for cpik C compiler!!!

alain gibaud Wrote:Josef Pavlik is a new contributor to the cpik project who has developed a lot of new features for version 0.5.3. Thanks to Josef, this version is a real improvement over the previous one.

-in version 0.5.3 (Marie Jeanne Gabrielle):

* Bug fixes in code and run-time library,
* Run-time library improvement,
* New pin.h header for easy manipulation of I/O ports thru symbolic names,
* Improved LCD library with pin configuration from C code,
* Dead code elimination in the case of loops or test with constant conditions,
* Optimisation of static data initialization, using the program sections concept,
* Post-compilation branch optimizer that generally reduces the code by 10%,
* Implementation of the enum declarator,
* Implementation of the switch instruction: this implementation is efficient and provides a near * constant-time case selection,
* Support for data located in ROM, with different access mechanisms,
* And more..
Reply
08-10-2011, 12:34 PM,
#5
RE: Alternatives to SDCC
Hi Vasile

Very good news !!

Maybe now we can try another solution for Pinguino compiler. Cpik project seems to move and it could be a good candidate to replace SDCC. I contacted Alain a long time ago but if all those new features are incorporated to Cpik, maybe it's time to give it a try !!

Jean-Pierre

(07-10-2011, 02:46 AM)funlw65 Wrote: Excellent news guys,

Things started to move again for cpik C compiler!!!

alain gibaud Wrote:Josef Pavlik is a new contributor to the cpik project who has developed a lot of new features for version 0.5.3. Thanks to Josef, this version is a real improvement over the previous one.

-in version 0.5.3 (Marie Jeanne Gabrielle):

* Bug fixes in code and run-time library,
* Run-time library improvement,
* New pin.h header for easy manipulation of I/O ports thru symbolic names,
* Improved LCD library with pin configuration from C code,
* Dead code elimination in the case of loops or test with constant conditions,
* Optimisation of static data initialization, using the program sections concept,
* Post-compilation branch optimizer that generally reduces the code by 10%,
* Implementation of the enum declarator,
* Implementation of the switch instruction: this implementation is efficient and provides a near * constant-time case selection,
* Support for data located in ROM, with different access mechanisms,
* And more..

Reply
08-10-2011, 01:34 PM,
#6
RE: Alternatives to SDCC
Especially since we now have the GCC preprocessor for all OS.
I downloaded 0.5.3 to give it a try. Libraries wouldn't be too difficult to translate.
Talking with him yesterday about how it could be difficult to do it, he said (sorry it's in french) :
Une des rares fonctionnalités a ne pas être implementée sont les champs de bits, et le type bit. Cependant, les classiques opérations & | etc .. permettent toujours une solution efficace. Si vous avez besoin d'assistance pour le portage, je suis à votre disposition. Je suis en train d'implémenter le calcul flottant. Josef Pavlik cherche à implémenter des "pointeurs universels" RAM/ROM. Cpik est compilable sous windows (avec mingw). Je suis en relation avec Jean-Marie Leroy, qui s'en sert régulièrement sous windows. Seule la procédure d'install est manquante mais il suffit de tout laisser dans un dossier et cpik "renifle" les fichiers dont il a besoin (assez peu en fait) dans ce dossier (je simplifie, mais en gros c'est ça). En ce qui concerne mac osX, c'est un unix, donc je ne prévois pas de gros problème.

Régis
It is easier to complain than it is to do, but it is better to do than it is to complain.
Reply
15-11-2011, 01:26 AM,
#7
RE: Alternatives to SDCC
I hope you guys have time to look over 0.6 version of cpik...

Vasi
Reply
15-11-2011, 11:26 PM,
#8
RE: Alternatives to SDCC
Hi Vasi,
I have now very simple Cpik (0.5.3 and 0.6.0) codes running on a 26J50.
I'm now busy with the Diolan bootloader.
I'm modifying it to work with 26j50.
Its size is now 1645 bytes !
Régis

(15-11-2011, 01:26 AM)funlw65 Wrote: I hope you guys have time to look over 0.6 version of cpik...

Vasi

It is easier to complain than it is to do, but it is better to do than it is to complain.
Reply
14-04-2012, 02:05 PM,
#9
RE: Alternatives to SDCC
Wow, cpik seems very promising. I'm using pinguino on a 8-bit (18f4550) board and currently have some problems using structures, unions and bitfields. The code compiles fine, but the routine hangs up. I think cpik could handle a little bit complex structures, but I haven't tried yet. It would be nice to have another "backend" for pinguino.
Reply
14-04-2012, 05:34 PM,
#10
RE: Alternatives to SDCC
(14-04-2012, 02:05 PM)Otamay Wrote: Wow, cpik seems very promising. I'm using pinguino on a 8-bit (18f4550) board and currently have some problems using structures, unions and bitfields. The code compiles fine, but the routine hangs up. I think cpik could handle a little bit complex structures, but I haven't tried yet. It would be nice to have another "backend" for pinguino.

Yes, I am for cpik! I had enough from SDCC (I'm keeping it for 8051 only), But today I'm using MPLAB C18 v3.40 for linux and I'm content. I'm doing it because I work with USB and I intent to use SD-Card on few applications.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)