gnupic: improved banksel and pagsel
Subject:
Re: improved banksel and pagsel
From:
Wojciech Zabolotny ####@####.####
Date:
24 Sep 2004 09:35:33 +0100
Message-Id: <Pine.SOL.4.33.0409241031360.28805-100000@elektron.elka.pw.edu.pl>
On Thu, 23 Sep 2004, Scott Dattalo wrote:
> On Thu, 23 Sep 2004, Gabor Kiss [Bitman] wrote:
>
> >> The banksel and pagesel directives in gputils have been improved for 12
> >> bit and 14 bit devices. Before the directives manipulated all the bits
> >> for 4 banks and 4 pages. Now they only manipulate the bits for the
> >> pages and banks available on that device.
> >
> > Dear Craig,
> >
> > Is it possible to make some compile time optimizations with banksel? Now
> > I had to write tricky macros that keeps current select bits in mind and
> > changes the only the bits really necessary when I select a bank. (I.e.
> > switching from bank0 to bank1 requires 1 "bsf" instruction only.)
> >
> > Yes, it is trivial, that principally there is no universal solution.
> > However even a limited version of banksel optimizer could
> > reduce code size and increase speed by omitting unnecessary
> > bit set/clear instructions at the expense of final code size
> > could not be strictly planned.
> >
> > What is your opinion?
>
> Gabor,
>
> Why stop with banksel's. To properly do what you want is not trivial. The
> reason is that there are to many special cases. Consider for example:
>
> banksel MyVar1
>
> CLRF MyVar1
>
> banksel MyVar2
>
> CLRF MyVar2
>
> If the two variables are in the same bank, then yeah, this is trivial to
> optimize. But now suppose you have:
>
> banksel MyVar1
>
> MOVF MyVar1,W
> MOVWF INDF
>
> banksel MyVar2
>
> CLRF MyVar2
>
>
> If MyVar1 and MyVar2, is it safe to get rid of the second bank select?
> Suppose FSR = 3?
>
> Or how about this:
>
> banksel MyVar1
>
> MOVF MyVar1,W
>
> A_label:
>
> banksel MyVar2
>
> CLRF MyVar2
>
> While I admit these are contrived, I'll argue that they're not too
> uncommon.
>
> One way to implement what you're asking is with a flow analyzer. This is a
> program that understands each instruction, knows where the labels are,
> where the function boundaries are, etc. The flow analyzer can do things
> like perform 'live rang analysis' and learn where certain registers are
> valid (e.g. think about how you'd implement automatic overlays for
> temporary variables). The flow analyzer can be made smart enough to detect
> the cases I illustrated above and make a decision as to whether or not the
> banksel's can be optimized.
>
> While working on SDCC, I implemented flow optimizer that did this. Its
> purpose was to mainly optimize the register allocation. However, I found
> that it was possible to do things like automatic inlining, peephole
> optimizing, tail optimizing etc. all within the same algorithmic
> framework.
>
> This is hardly trivial! Perhaps a more trivial approach is to define
> regions that the assembler/linker can safely optimize:
>
> banksel start
>
>
> ; the assembler will assume that all instructions will
> ; execute in one continuous stream. In addition, it's
> ; assumed that the status register is not manipulated
> ; through indirect operations
>
> banksel end
>
> All registers falling in the bracketed range could be banksel optimized.
>
Dear pic Users,
I'm using since ca. 2000 my old bank switching macros:
http://www.ise.pw.edu.pl/~wzab/codmpasm/xbanks.inc
So the problem possibly may be solved at the user's side...
They are not perfect, but save me a lot of work.
PS. The complaints about not working with gpasm are not true since a few
years ;-).
HTH & Regards,
Wojtek Zabolotny
