The self-registartion to the wiki is
disabled due to spam attacks. If anybody needs the write access,
please let me know: send me your prefer use name and I'll give you
On 18. 12. 2012 22:33, Vaclav Peroutka wrote:
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.
Over time, and especially recently, it seems people
want an STM8 port of
sdcc. Vaclav has started such a port, but its incomplete, and,
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?
¹ The flaws are mostly due to the port being based on the hc08
more than a year ago. Here's the two most important ones:
* Back then the hc08 port used the old register allocator, and
the stm8 port. Making the hc08 port use the new register
required a rewrite of substantial parts of the code genration.
a huge improvement was achieved: Just look at the drop in
code size at
has 5 8-Byte registers, which the new register allocator can
handle. An STM8 port should be written for the new allocator,
* The hc08 port places local variables and parameters in memory
addresses by default. Some other ports, such as the z80-related
the stack by default. Typically the first approach results in
but non-compliant (recursion doesn't work) code. There is some
disagreement among sdcc dveelopers as to which should be used by
due to the trade-off. However let's have a look at the STM8
modes, for the typical situation of at most 256 bytes of local
per function but more than 256 bytes of lcoal variables in all
combined. The STM8 would use long direct addressing for local
when doing things hc08-style, while it would use sp indexed
mode when doing things z80-style. Now, sp-indexed mode is faster
results in smaller code. When instead assuming the case of at
bytes of local variables in all functions combined, we would get
indirect mode for the hc08-style. This mode results in roughly
code size and speed as the sp-indexed mode.
This means that for the STM8, doing things hc08-style gives us
non-compliant code. The only exception would be functions which
than 256 bytes of local variables without using aggregates or
such functions are very rare. An STM8 port therefore should
all local variables on the stack.
² In case you're wondering if there is some agenda behind my
* I have written the new register allocator, and modified z80
generation somewhat for it, and have seen a substantial
the generated code. Together with Eric, I have made the hc08
the new register allocator, which included making big changes to
generation there. Combined, these resulted in an about 40%
generated hc08 code size. The improvement for hc08 was more
than for Z80, partially because code generation was tailored to
allocator more. Writing the code generator with the new
mind from the start thus seems like the way to go.
* IMO, sdcc should be standard-compliant by default, and only
from compliance if there is good reason to do so and on request
of the user.
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
Sdcc-user mailing list