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.
Regards,
Borut
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.
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.
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.
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------
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
