Small Device C Compiler (SDCC) 3.6.0 (http://www.octoate.de/wp/2016/07/14/small-device-c-compiler-sdcc-3-6-0/?pk_campaign=feed&pk_kwd=small-device-c-compiler-sdcc-3-6-0)
14 July 2016, 8:00 pmA new version of the SDCC C compiler is available. You can use SDCC to develop for the Amstrad CPC, e.g. with using the SDCC Code::Blocks template (http://www.octoate.de/wp/2011/09/04/sdcc-codeblocks-template-v1-2/) or the programming tutorials by Mochilote (http://www.octoate.de/wp/2012/03/03/various-amstrad-cpc-programming-tutorials/) or with the new CPCtelera framework (http://www.octoate.de/wp/2016/04/20/cpctelera-v1-4-amstrad-cpc-game-engine-for-c-developers/). The new version contains also some features for the Z80 port, so be sure to update it. You can download it from http://sdcc.sourceforge.net.
Changes:- Merged upstream binutils 2.25
- New memory management with lower overhead
- Changed default language dialect to –std-sdcc11
- Diagnostic for missing type specifier: No implicit int outside of C90 mode anymore
- C11 generic selections
- char type is now unsigned by default (old behaviour can be restored using –fsigned-char)
- Character constants are now of type int instead of char.
- ISO C95 and ISO C11 wide character constants
- ISO C95 and ISO C11 wide string literals
- Basic standard library support for wide characters: c16rtomb(), mbrtoc16(), mbsinit(), mbtowc(), mbrlen(), mbrtoc32, c32rtomb(), mbrtowc(), wcrtomb(), mblen(), wctomb()
- Treat all ports the same in the manual (i.e. mcs51-specific stuff is now clearly described as such)
- Reorganized interrupt handling for z80, z180, r2k, r3ka, tlcs90, gbz80 backends
- Workaround for stm8 division hardware bug
- ELF/DWARF support for stm8
- Output symbol table for ELF
- pic16 port now uses standard-compliant crt0iz that initializes static and globals to 0 by default
- Numerous feature requests and bug fixes
© Octoate for The Amstrad CPC news portal (http://www.octoate.de/wp), 2016. | Permalink (http://www.octoate.de/wp/2016/07/14/small-device-c-compiler-sdcc-3-6-0/?pk_campaign=feed&pk_kwd=small-device-c-compiler-sdcc-3-6-0) | No comment (http://www.octoate.de/wp/2016/07/14/small-device-c-compiler-sdcc-3-6-0/?pk_campaign=feed&pk_kwd=small-device-c-compiler-sdcc-3-6-0#comments) | Add to del.icio.us (http://del.icio.us/post?url=http://www.octoate.de/wp/2016/07/14/small-device-c-compiler-sdcc-3-6-0/?pk_campaign=feed&pk_kwd=small-device-c-compiler-sdcc-3-6-0&title=Small%20Device%20C%20Compiler%20(SDCC)%203.6.0) Post tags: 2016 (http://www.octoate.de/wp/tag/2016/), c-compiler (http://www.octoate.de/wp/tag/c-compiler/), cross-development (http://www.octoate.de/wp/tag/cross-development/), development (http://www.octoate.de/wp/tag/development/), programming (http://www.octoate.de/wp/tag/programming/), sdcc (http://www.octoate.de/wp/tag/sdcc/)
(http://cpc-live.com/topsites/button.php?u=Octoate) (http://cpc-live.com/topsites/) Related posts:
- Small Device C Compiler (SDCC) 3.4.0 (http://www.octoate.de/wp/2014/04/12/small-device-c-compiler-sdcc-3-4-0/?pk_campaign=feed&pk_kwd=small-device-c-compiler-sdcc-3-4-0)
- Small Device C Compiler (SDCC) 3.2.0 (http://www.octoate.de/wp/2012/07/12/small-device-c-compiler-sdcc-3-2-0/?pk_campaign=feed&pk_kwd=small-device-c-compiler-sdcc-3-2-0)
- Small Device C Compiler (SDCC) 3.5.0 (http://www.octoate.de/wp/2015/06/27/2809/?pk_campaign=feed&pk_kwd=2809)
Source: The Amstrad CPC news portal (http://www.octoate.de/wp)
---
This news item first appeared on Octoate's Blog and was aggregated through RSS for the forum.
[attachimg=1]
....
@ronaldo (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1227) : update for cpctelera to latest sdcc ? or is it to early ?
Yes, @SRS (http://www.cpcwiki.eu/forum/index.php?action=profile;u=805) , next release of CPCtelera (http://lronaldo.github.io/cpctelera) will include SDCC 3.6.0 for sure :D
I've been running some tests and so far I'm not sure I'll move to 3.6 until I understand some of the changes.
For example, my binary is bigger now, and I don't know why :(
EDIT: actually, optimising for speed I get a smaller binary than optimising for size :o
In this case the result is 540 bytes smaller than the same project compiled with 3.5.0 (ignoring the fact that it doesn't make sense that optimising for speed I get a smaller binary than optimising for size).
I haven't found any issue so far. I'll continue with 3.6.0 and if I found anything weird in the generated code, I can always go back to 3.5.
Quote from: reidrac on 13:52, 16 July 16
I've been running some tests and so far I'm not sure I'll move to 3.6 until I understand some of the changes.
For example, my binary is bigger now, and I don't know why :(
EDIT: actually, optimising for speed I get a smaller binary than optimising for size :o
In this case the result is 540 bytes smaller than the same project compiled with 3.5.0 (ignoring the fact that it doesn't make sense that optimising for speed I get a smaller binary than optimising for size).
I haven't found any issue so far. I'll continue with 3.6.0 and if I found anything weird in the generated code, I can always go back to 3.5.
It looks like someone needs to start revising this page:
SDCC vs z88dk: Comparing size and speed of the binaries generated for Amstrad CPC (http://www.cpcmania.com/Docs/Programming/SDCC_vs_z88dk_Comparing_size_and_speed.htm)
Sure it's mostly a comparative between z88dk and SDCC, though at the bottom of the page it also shows the improvements SDCC goes though from v3.1.0 to v3.3.0. v3.2.0 shows the best results for speed, though v.3.3.0 improves the size of the code, with a slight drop back in performance.EDIT: For some reason I thought I was looking at a Home Page of SDCC, but now I realise it's @Mochilote Tutorial page with other stuff on it! ???
The SDCC doesn't appear to have any comparative results between the different versions of SDCC. Information like that is extremely handy to know.