STM8 is cheap and amazing MCU.Why can't sdcc trunk to support this chip?
The stm8 port is not yet up to the quality standard of the other ports in sdcc (unless you count the pic ports, which are broken). Once the stm8 port passes most of the regression tests, it will be included in trunk.
Thanks.I want to make it more stable.
If you want to help with the stm8 port, please subscribe to the sdcc-user and sdcc-devel mailing lists, and send an email to the latter. There are some tasks that need to be done; both Valentin and me are working on the port, but more help is always welcome, and would result in the port becoming useful quicker.
Once the port is stable enough, the next step would be doing more optimizations: Currently, the stm8 port generates code about twice as big and slow compared to Cosmic C.
can you give some news about the STM8 port...?
is it better now, is there still many things to do before an eventual release, why no more infos about it...?
don't want to stress you about it, I thank you for your work on it ! :-)
but I just found these very little infos and I'm really curious to know how it's evolving..
I've put some effort into the stm8 port last year. It is not perfect yet; there are some rough edges, but IMO it is definitely ready for production use. It will be included in the 3.4.0 release.
The stm8 port passes the regression tests, and thus code quality is similar to other stable ports (mcs51, hc08, z80, etc) and better than the pics. There are a few open stm8 bug reports, but their number is similar to the number of open bug reports for other stable ports.
sdcc still lacks support for some important standard features, such as VLAs and struct and union passing and assignment. sdcc also still lacks somehigh-level optimizations. sdcc does have lospre, but our pointer analysis is wuite bad, and we don't have interval analysis at all. This affects all ports, and how bad it really is depends on the programming style.
The stm8 port has uses some cutting-edge technology in the backend, such an optimal register allocator based on tree-decompositions and bytewise register allocation. There is still a bit of potential for further optimization in the backend, but not much.
The IAR C compiler gives an about 20% smaller code size than sdcc.
sdcc is definitely useable for stm8. There are some users, and recently, I compiled dhrystone and coremark using sdcc and ran them on STM8/128-EVAL evaluation board. Code size looked good, I didn't run into any bugs or issues. The scores left abit to be desired though; When creating the stm8 port I've definitely put more effort into optimization for code size than into optimization for speed.
Wow, great news, thanks Philipp..!
well, I understand that SDCC could be better and there still are some good things to add, but it's really good news to know that we can have an option now for a STM8 open source compiler.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.