On 14.12.2012 10:20, Vaclav Peroutka wrote: > Hi Philip, > >> 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. > > I just wonder which register allocator is used in Cosmic compiler ? Can you > guess ? The number of used RAM is almost one half to the new allocator in > sdcc... > > Vaclav
Compilers these days typically use a graph-coloring approach (see Chaitin's work on this) or an ILP-based one. I guess Cosmic uses something that for practical purposes is somewhat worse than our new allocator. Our new allocator is provably optimal, and AFAIK the only such allocator currently existing. However there are other areas where sdcc is much worse than the current state of the art in compiler consturction (and worse than the state of the art of 30 years ago). Most likely these are to blame for sdcc generating worse code compared to Cosmic C. Some coming to my mind at once are: * sdcc has no generalized constant propagation. Currently when a programmer uses an int for a loop counter that happens to always be in the range [0, 100], we need 16 bits for this counter (we only know it fits into an int). Generalized constant propagation would allow us to prove that the counter always stays in the range [0, 100], so we could use an 8-bit variable instead. * sdcc has bad pointer alias analysis. This especially hurts redundancy elimination, which practically has to assume that any two pointers might alias. * The peephole optimizer of the hc08 port lacks some functionality already implemented in other ports, see RFE #3528282 for the main point. * The notVolatile() function in the peephole optimizer is overly pessimistic. Basically it assumes that every variable in memory might be volatile. See RFE #1495816. A simple, but already quite effective improvement would be to use the current behaviour, if there is some volatile accessed somewhere in the function, and otherwise always return true. Philipp ------------------------------------------------------------------------------ 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
