sdcc 3.5.0 rc1

[PkK]

sdcc 3.5.0 is to be released soon. Today, there will be release candidate 1.

You can download the release candidate and have a look at it. The more eyes on it, the less likely are hidden bugs.

 

The main changes from previous sdcc 3.4.0 are:

 

• Many fixes and improvements in the stm8 port
• --disable-non-free configure option
• z80 port fixes
• long long fixes
• Changed default language dialect from --std-sdcc89 to --std-sdcc99
• Reorganized and updated manual
• Reduced memory consumption (most noticeable for high --max-allocs-per-node)
• Faster compilation for stm8 (most noticeable for high --max-allocs-per-node)
• atoll() function for conversion of strings to long long
• __z88dk_fastcall and __z88dk_callee calling conventions for more efficient function calls and better compability with z88dk
• --lospre-unsafe-read renamed to --allow-unsafe-read

 

I think all ColecoVision programmers will want to change from 3.4.0 to 3.5.0. Of particular interest are the z80 bug fixes and the long long bug fixes. The z80 port is also affected by the reduced memory consumption, which matters for those compiling at high --max-allocs-per-node for more optimization.

z88dk is another free compiler for the z80; sdcc generates better code when compiling C, and supports more C features. The z88dk philosophy is to have lots of asm-implemented functions, and use C for a glue layer on top. Thus z88dk has features for efficient calls to asm functions from C. We now also support those in sdcc via __z88dk_fstcall and __z88dk_callee.

 

Philipp

 

[digress]

awsome. I'll try it out today. well when it's uploaded.

[PkK]

Sorry, there were some delays due to hardware issues on teh MAcOS X build infrastructure.

The release candidate can now be found at:

http://sourceforge.net/projects/sdcc/files/

 

Philipp

 

[digress]

3.5 Worked great for me. Without changing any code my project dropped from

 

32,191 bytes

to

30,951 bytes

 

Compiled and works as before under 3.4 and seems to be a nice rom savings. On my machine compiled in about 4 minutes.

 

got a bunch of warnings I hadn't gotten previously though

example:

Mr_Turtle.c:690: warning 158: overflow in implicit constant conversion which referrs to this in the code: put_char(x,y,254);

Mr_Turtle.c:759: warning 158: overflow in implicit constant conversion which referrs to this in the code: counter=-1;

Mr_Turtle.c:1971: warning 158: overflow in implicit constant conversion which referrs to this in the code: put_char(pearl_x,pearl_y,175);

Seems to not like when I used hard coded values. The compiled code worked fine though.

Thanks for the update. It has given my project more room for a game over screen I needed.

[PkK]

 

3.5 Worked great for me. Without changing any code my project dropped from

 

32,191 bytes

to

30,951 bytes

 

Compiled and works as before under 3.4 and seems to be a nice rom savings. On my machine compiled in about 4 minutes.

 

got a bunch of warnings I hadn't gotten previously though

example:

Mr_Turtle.c:690: warning 158: overflow in implicit constant conversion which referrs to this in the code: put_char(x,y,254);

Mr_Turtle.c:759: warning 158: overflow in implicit constant conversion which referrs to this in the code: counter=-1;

Mr_Turtle.c:1971: warning 158: overflow in implicit constant conversion which referrs to this in the code: put_char(pearl_x,pearl_y,175);

Seems to not like when I used hard coded values. The compiled code worked fine though.

Thanks for the update. It has given my project more room for a game over screen I needed.

 

 

What are the types of counter and put_char()?

 

Philipp

[digress]

byte counter

 

put_char is from the getput.lib library

void put_char (unsigned char x,unsigned char y,char s);

 

Seems to work fine anyways. I'll play through everything to see if anything behaves differently.

 

put_char(0,y,123); works

but

put_char(0,y,128); does not work. Seems to be because char type is -127 to +127 in values

I noticed a few char updates missing from the screen in my older program when compiled but not in the newer one.

void print_at (byte x, byte y,char *s); seems to work fine though

/* PRINT AT X,Y ON SCREEN */

void print_at (byte x, byte y,char *s)

{

register unsigned i;

//disable_nmi (); /**************/

i = (byte) strlen (s);

put_vram (chrtab+y*32+x,s,i);

//enable_nmi (); /**************/

}

[PkK]

Assuming byte is a typedef to unsigned char, all the warnings are right. unsigned char can't hod -1. signed char cannot hold 254 or 175.

 

Philipp

[digress]

It works though . The put_char(x,y,232); will put the correct 232 tile on the screen.

 

My work around has been simple enough. It's obviously the signed char that's the issue. So I change any value over 127 to the negative equivalent from the pattern table.

 

instead of 255 I use -1 and this removes the warning.