Subject:
PIC port status
From:
Scott Dattalo ####@####.####
Date:
19 Mar 2001 07:39:52 -0000
Message-Id: <Pine.LNX.4.21.0103190049330.16022-100000@tempest2.blackhat.net>
(My latest changes are not in CVS yet).
As most of you know I'm working on the PIC port SDCC. Here lately I've been
concentrating on pCode optimization. pCode, as you may recall, is "post" code
(SDCC already has intermediate code called iCode). There are pCode objects for
the various types of code that can be generated. For example, labels, assembly
instructions, and comments are the common pCode types. For the assembly
instructions, there is a one-to-one correspondence between one pCode object and
one instruction. This is useful for analyzing program flow.
The first step in pCode optimization was to mimick, but enhance the peep hole
optimization that SDCC already performs. The example that I like to give is
this:
movwf reg
movf reg,w
In this example, it's not obvious that the second instruction can be
removed. True, W is not changed by the second instruction, but the Z bit in the
status register is. The pCode peep hole optimizer handles this situation by
examining the instructions that follow the "movf reg,w" instruction. If it's
determined that the Z bit is modified by a subsequent instruction before it is
tested as an input (e.g. btfsc status,z), then the "movf" can be removed.
The pCode peep hole optimizer works well, but is not completed. The big piece
missing is the parsing of peephole definition files. When the pCode stabilizes,
I'll integrate it into the src/ directory and will modify SDCCpeeph.c to
generate pCode too.
The second step in pCode optimization is register optimization. This is working
now! Essentially what it does is traverse the entire call tree and look for
register collisions. If a register is being used in a function that is called,
then the callee will relocate its register(s). There are at least two major
benefits with this feature. First, all local storage can be predetermined and
allocated from a pool of registers. Second, a function's local storage doesn't
have to be pushed onto a stack when ever another function is called. This is
especially good for the pic since it doesn't have a data stack (in fact that was
the primary motivation for adding this feature).
The example I've been using to develop the code is:
void inc(unsigned char k)
{
uchar0 = uchar0 + k;
}
void f1(void)
{
uchar2++;
}
void nested_call(unsigned char u)
{
f1();
uchar1 = uchar1 + u;
inc(uchar1);
}
'nested_call' is called from main().
It might appear that there is no local storage in these functions. However `inc'
and `nested_call' save the calling parameter in a local register. (Or more
accurately, the parameter is passed to the function via W and saved locally.)
The code that is generated (and which has a bunch of room to be optimized) is:
_nested_call ;Function start
MOVWF r0x0D
CALL _f1
MOVF r0x0D,W
ADDWF _uchar1,F
MOVF _uchar1,W
CALL _inc
_00201_DS_
RETURN
_f1 ;Function start
INCF _uchar2,F
_00181_DS_
RETURN
_inc ;Function start
MOVWF r0x0C
ADDWF _uchar0,F
_00161_DS_
RETURN
In this example, the local variable `r0x0D' in nested_call was originally r0x0C
(originally, that is, before register optimization kicked in).
The next step will be to add `live ranges' to the logic. In some respects, the
above example is poor because the local variables don't actually
collide. Furthermore, the example also clearly illustrates that the register
optimizer does not remove unnecessary registers. "inc" has no business tucking
its input parameter away in local.
Another feature that sounds difficult but in fact will be straight forward is
function inlining. Again with the example above, there's no reason that `f1'
shouldn't be inlined. If it were, then the call to "inc" could also be removed
since "inc" would then immediately "nested_call".
A lot of progress, but a whole lot of work still ahead.
Scott
