gnupic: PIC port status
Subject:
Re: PIC port status
From:
Ulrich Dziergwa ####@####.####
Date:
19 Mar 2001 21:57:20 -0000
Message-Id: <3AB68001.5A4E222B@web.de>
Scott Dattalo wrote:
>
> (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
... snip ...
>
> 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).
>
... snip ...
Hi Scott
I am using the PCM Compiler from CCS. I have choosen this compiler,
because it supports bit variables (not real standard C). But I found a
severe flaw in the register handling. I make intensive use of timer tick
interrupts. I scan inputs and build software PWM on multiple outputs in
the interrupt handler. While I was doing that in assembler, I try to use
completely different registers in the interrupt handler than in the main
programm. The use of interrupt functions in C is easy, but if you look
into the generated code, the compiler saves a lot of registers in the
interrupt praeambel and restores them back again at the end. This code
sometimes runs longer than my interrupt handler and severly limits the
frequency I can generate in software. I like rather to deal the use of
some more registers against the time it takes to save and restore them.
The PIC hase only one interrupt context, so the cost of having a second
set of compiler internal registers for complex functions (16 bit add,
..) is not so high and on the 16F87x there are plenty of them.
Ulrich
