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 access.
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, 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?
> ¹ 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.
> a huge improvement was achieved: Just look at the drop in
> generated hc08
> code size at
> 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
> 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
> 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
> 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 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
> 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
> 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
> 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.
> 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