[z88dk-dev] sdcc code improvements

Bridge to the z88dk-developers mailing list
Post Reply
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

[z88dk-dev] sdcc code improvements

Post by alvin »

A number of things have come up:

* Quite often looking at sdcc's output it was a mystery (to me) why some optimizations were not carried out by the peepholer. The cause turned out to be a little too relaxed register use indicator in sdcc's peepholer. It would sometimes search hex constants and label names for registers and erroneously find them there, generating incorrect information about whether the registers had been used in a particular instruction. That's been fixed in our sdcc patch and I no longer see these issues in generated code. Code quality has increased a little bit too as a result. There is still some imprecision in dealing with some instructions, eg "ex de,hl" which currently indicates to the peepholer that both de & hl are in use. More accurate information would be gathered by swapping de for hl in the registers being tested for and continuing through the code to find an answer. This is more important for z88dk because our peephole rules generate "ex de,hl" instructions. I usually se!
e a few
places in large programs where "ex de,hl" is erroneously blocking optimizations.

* sdcc has introduced a "__preserves_regs()" attribute for function prototypes. In the brackets you list which registers are unchanged by the called function. Obviously this is intended for assembly functions so it affects our entire library :) and the compiler uses this information to allow registers to persist through function calls. In reality most library functions use all registers but there are many that can make use of the new feature. I've added the attributes already to the header files in cvs and you can see improved code generation in circumstances where this comes into play. Currently sdcc only pays attention to information about bc & de but I've added information on a,b,c,d,e,h,l to the headers. HL especially would be useful so maybe in the future sdcc will expand the set of registers it considers.

* With this new preserves registers feature, it's possible to introduce intrinsics and I've done that tonight. I committed three of them currently: intrinsic_di, intrinsic_ei and intrinsic_halt. sdcc's peepholer normally cannot look into inlined assembly so any inline assembly added by the user interferes with peephole optimization. The intrinsics are a way to inline z80 instructions without interfering with the peepholer and the three intrinsics I added tonight are the most commonly inlined asm instructions in real programs. They work like this: the intrinsics are declared as functions returning void, taking no parameters and preserving all registers. You use the intrinsic like a regular C function eg "intrinsic_di();" and because all registers are preserved, sdcc allows registers to persist through the call which means the intrinsic does not interfere with the peepholer. There is no real function associated with the intrinsics; instead what happens is copt replace!
s the
call to the intrinsic with the corresponding asm instruction. For sdcc this substitution is done when sdcc's output is translated to zilog by copt. For sccz80 this translation is done in ruleset 0 (ie -O0 minimum). I'm also looking at adding intrinsic atomics so that the we can guarantee that, eg, 16-bit loads and stores occur atomically. Right now, with sdcc at least, you can't guarantee a 16-bit load/store won't be done 8-bits at a time.

* We can fix the issues sdcc has with its __critical attribute as well. Currently it determines interrupt enable state using "ld a,i" which only works reliably for cmos z80s. In the new c library, the target declares itself cmos or nmos so we can actually substitute correct code when sdcc's critical pattern appears.

Anyway, the code quality is starting to look fairly good. There is still some weird things going on but overall I think it compares quite well against everything else available.



------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/ ... 1&iu=/4140
Post Reply