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 -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu