I quickly did code size tests for STM8. I took template from SDCC wiki and
it is atached. I would upload it to Wiki but I do not have rights for it.
Vaclav
"Over time, and especially recently, it seems people want an STM8 port of
sdcc. Vaclav has started such a port, but its incomplete, and, IMO has
some serious design flaws¹, which are not worth fixing.
So, I propose² the following:
* Write a new STM8 sdcc port.
* Use existing assembler.
* Use existing linker.
* Use existing ucsim.
What do you think about this?
Philipp
¹ The flaws are mostly due to the port being based on the hc08 port of
more than a year ago. Here's the two most important ones:
* Back then the hc08 port used the old register allocator, and so does
the stm8 port. Making the hc08 port use the new register allocator
required a rewrite of substantial parts of the code genration. Combined
a huge improvement was achieved: Just look at the drop in generated hc08
code size at
http://sdcc.sourceforge.net/mediawiki/index.php/Hc08_code_size
(http://sdcc.sourceforge.net/mediawiki/index.php/Hc08_code_size). The STM8
has 5 8-Byte registers, which the new register allocator can easily
handle. An STM8 port should be written for the new allocator, not the
old one.
* The hc08 port places local variables and parameters in memory at fixed
addresses by default. Some other ports, such as the z80-related ones use
the stack by default. Typically the first approach results in faster,
but non-compliant (recursion doesn't work) code. There is some
disagreement among sdcc dveelopers as to which should be used by default
due to the trade-off. However let's have a look at the STM8 addressing
modes, for the typical situation of at most 256 bytes of local variables
per function but more than 256 bytes of lcoal variables in all functions
combined. The STM8 would use long direct addressing for local variables
when doing things hc08-style, while it would use sp indexed addressing
mode when doing things z80-style. Now, sp-indexed mode is faster and
results in smaller code. When instead assuming the case of at most 256
bytes of local variables in all functions combined, we would get short
indirect mode for the hc08-style. This mode results in roughly the same
code size and speed as the sp-indexed mode.
This means that for the STM8, doing things hc08-style gives us slower,
non-compliant code. The only exception would be functions which use more
than 256 bytes of local variables without using aggregates or unions;
such functions are very rare. An STM8 port therefore should always place
all local variables on the stack.
² In case you're wondering if there is some agenda behind my proposal:
* I have written the new register allocator, and modified z80 code
generation somewhat for it, and have seen a substantial improvement in
the generated code. Together with Eric, I have made the hc08 port use
the new register allocator, which included making big changes to code
generation there. Combined, these resulted in an about 40% reduction in
generated hc08 code size. The improvement for hc08 was more spectacular
than for Z80, partially because code generation was tailored to the new
allocator more. Writing the code generator with the new allocator in
mind from the start thus seems like the way to go.
* IMO, sdcc should be standard-compliant by default, and only deviate
from compliance if there is good reason to do so and on request of the user.
"
= stm8 (and related ports) code size =
A history of code size in sdcc and a comparison to other compilers.
== STM8 code size comparison (bytes): ==
{| border=1 class="simple"
! File
! Cosmic C² stm8
! sdcc #xxxx stm8
|-
| cvu_vinb.c
| 7
| x
|-
| galois_lfsr.c
| 21
| x
|-
| get_tile.c
| 95
| x
|-
| huffman_iterative.c
| 161
| x
|-
| huffman_recursive.c
| 198
| x
|-
| init_loop.c
| 33
| x
|-
| insertion_sort.c
| 108
| x
|-
| memcpy_compression.c
| 31
| x
|-
| memtovmemcpy.c
| 30
| x
|-
| play_music.c
| 393
| x
|-
| sdcc_divulong.c
| 100
| x
|-
| sdcc_mullong.c
| 132
| x
|-
| set_screen_mode.c
| 49
| x
|-
| set_sprite_x.c
| 66
| x
|-
| z88dk-mktime.c
| 239
| x
|-
| total
| x
| x
|}
The benchmark files can be found at
http://colecovision.eu/stuff/testbench.tar.gz
² C Compiler for STM8 (COSMIC Software); Generator V4.3.4 - 23 Mar 2010
This is a list of feature requests, that combined will probably get code size
down near to the level of the non-free compilers.
{| border=1 class="simple"
! '''Request ID'''
! '''Summary'''
|-
|
|}
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
