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
