gnupic: Re: SDCC RAM banking support?
Subject:
Re: [PIC]: SDCC RAM banking support?
From:
Scott Dattalo ####@####.####
Date:
13 Oct 2001 22:47:48 -0000
Message-Id: <Pine.LNX.4.33.0110131530440.11914-100000@ruckus.brouhaha.com>
On Sat, 13 Oct 2001, Wojciech Zabolotny wrote:
> Hi All,
>
> I have tried to compile a very simple program with sdcc:
Good. SDCC does compile VERY simple programs.
>
> data at 0x47 volatile char test1;
> data at 0x193 volatile int test2;
> void main()
> {
> for(;;)
> {
> test1=0x32;
> test2=0x1234;
> test1=0x42;
> test2=0x7654;
> }
> }
>
> So the RAM bank should be switched between test1 and test2 references.
> However in the output assembly file I get (after comments removal):
>
> _00103_DS_
> MOVLW 0x32
> MOVWF _test1
> MOVLW 0x34
> MOVWF _test2
> MOVLW 0x12
> MOVWF (_test2 + 1)
> MOVLW 0x42
> MOVWF _test1
>
> Is the banking support still lacking in sdcc for pic?
Banking is not supported. You may wish to check the message I posted (to
the PICLIST not gnupic) that gave a succint up-to-date status report. An
even more succint summary is that I'm concentrating on the C specific
aspects and am ignoring the PIC idiosynchrasies like banking. However, I
do have a plan for register banking...
About the only thing different between what I said in the summary a few
days ago and now is that I support signed and unsigned long compares.
> BTW I'd like to create the 16F877 headers for SDCC.
That'd be great.
> Should the registers be declared as:
> data at 0x00 volatile char INDF;
> data at 0x01 volatile char PCL;
> and so on?
Probably. As a general rule, any register that can change without direct
program manipulation should be declared volatile. This includes I/O ports
and status registers. Volatile also applies to variables accessed within
the context of an interrupt. Special function registers such as the TRIS
registers do not need to be declared volatile. Incidently, SDCC has non
ANSI modifier called "sfr". Currently the pic port will take sfr types and
generate an EQU for them.
------
Please remember that the SDCC PIC port is still considered alpha. Just
about anything you try at the moment is almost guranteed NOT to work.
OTOH, progress is steady.
Scott
