gnupic: SDCC in the bank
Subject:
Re: SDCC in the bank
From:
Scott Dattalo ####@####.####
Date:
22 Jan 2002 16:59:33 -0000
Message-Id: <Pine.LNX.4.33.0201220824120.28609-100000@ruckus.brouhaha.com>
On Tue, 22 Jan 2002, Ralf Forsberg wrote:
> On Mon, Jan 21, 2002 at 10:49:37PM -0800, Scott Dattalo wrote:
> >
> > Register bank that is.
>
> Yes!
>
> > btfss bank0_var1,0
> > btfsc bank1_var2,2
> > incf bank3_var3,f
>
> Would it be possible to group variables with temporal locality
> together in the same bank?
Sometimes. Another possibility is to create temporary copies and operate
on those. Yet another possibility is to use indirect addressing for one of
the access (I haven't even begun to look at indirect accesses into banks 2
and 3 though).
I'm now trying to arrange the generated code into non-branching flow
segments. In other words, if a series of instructions has no branches,
calls, skips, or labels, then the instructions will execute one after
another (excluding interrupts). Anytime a branch or skip or call is
encountered then the execution sequence is potentially altered. Labels
mark the beginning of call or goto destination and hence mark the
beginning of a contiguous string of instructions (although the string may
be only one instruction long). A skipped instruction is a special case of
a string of just one instruction.
Now, the entire code can be partitioned into these contiguous flow
segments. And conversely, each of these flow segments can be concatenated
to create the program. It greatly simplifies the analysis of the code when
you're confined to a string of instructions to execute one after another.
I plan to use this (among many things) for grouping banked accesses
together. As it stands, each banked access is wrapped in bsf/bcf's to set
and clear the page bits. However, it's fairly straight forward to
determine the state of the page bits within a flow segment. Furthermore,
this information can also be recorded in the entry and exit conditions of
a flow segment.
>
> SFR's are another matter...
They sure are. I've added a new file called src/pic/device.c that will
define the basic architecture of all the PIC's. Right now it only defines
the memory map of a 16F877. All of the SFR's will be defined here. I've
decided to put this in here (as opposed to creating user defined .h files
that describe the SFR's) so that I can track register volatility down to
the bit level. SDCC has a mechanism in place for defining special function
registers, but it doesn't have a mechanism for describing the register
volatility (it assumes that all bits are volatile). For example, PORTA and
TRISA are two SFR's. TRISA's bits are not volatile whereas PORTA's may be.
However, PORTA's bit's are technically only volatile if they're inputs. So
PORTA's volatility depends on TRISA! But before I worry about this, there
many more basic things that need to work...
Scott
