From: Goovaerts, M. <mar...@te...> - 2003-10-23 00:49:05
|
Hi All, I'm confused/concerned about the memory layout of this very simple example. version and command line info: SDCC -v: mcs51/gbz80/z80/avr/ds390/pic14/pic16/TININative/xa51/ds400 2.3.5 (Oct 5 2003) (MINGW32) SDCC --vc --use-stdout --debug --verbose --iram-size 256 --idata-loc 0x23 main.c In the files paisted below, you'll find the source , .mem and .map files. I believe that i have found the following issues: It seems to me that sdcc generates overlapping memory useage. The automatic variable bit2 (the bit segment) is located at 0x20 although i manually assigned a bit addressable byte at 0x20. In my opinion, sdcc should see this and start at 0x21 for placing the automatic bits. I also don't know about a linker option for determining BSEG location, so there's no way to circumvent this problem. I'll ask another question while i'm at it. The manual location of the bit addressable byte was made in orde to have bit and byte addressing possibilities for the same variable. (byte1 and bit1_0 in the example) Am i right to assume that this is the only way of achieving this goal, or are there other possibilities. Finally, there's another issue, concerning the idata segment. As you can see in the commandline, i used '--idata-loc 0x23'. I would expect the idata segment to be 220 bytes long (128 + remaining part in data segment). The mem file says it's only 128 bytes. Is this just a cosmetic problem or is it really only 128 bytes long. I hope that i provided all the necessary info in the correct form. If necessary i can send the files below as attachments too. Greetings, Marc Goovaerts _________________________main.c___begin____________ sfr at 0x80 P0; /* PORT 0 */ sbit at 0x87 P0_7; sbit at 0x86 P0_6; sbit at 0x85 P0_5; sbit at 0x84 P0_4; sbit at 0x83 P0_3; sbit at 0x82 P0_2; sbit at 0x81 P0_1; sbit at 0x80 P0_0; unsigned char at 0x20 byte1 = 0x00; bit at 0x00 bit1_0; volatile bit bit2 = 1; void main(void) { while (1) { ; } } _________________________main.c___end______________ _________________________mem_file_begin____________ Direct Internal RAM: Name Start End Size Max ---------------- -------- -------- -------- -------- REG_BANK_0 0x00 0x07 8 8 REG_BANK_1 0x08 0 8 REG_BANK_2 0x10 0 8 REG_BANK_3 0x18 0 8 BSEG_BYTES 0x20 0x20 1 16 DATA 0x21 0 128 ---------------- -------- -------- -------- -------- TOTAL: 0x00 0x20 9 128 Stack starts at: 0x21 (sp set to 0x20) with 223 bytes available Other memory: Name Start End Size Max ---------------- -------- -------- -------- -------- INDIRECT RAM 0x23 0 128 EXTERNAL RAM 0x0000 0 65536 ROM/EPROM/FLASH 0x0000 0x0082 131 65536 _________________________mem_file_end______________ _________________________map_file_begin____________ Hexadecimal Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ . .ABS. 0000 0000 = 0. bytes (ABS,OVR) Value Global -------- -------------------------------- 0000 G$bit1_0$0$0 0000 _bit1_0 0000 l_DSEG 0000 l_HOME 0000 l_ISEG 0000 l_OSEG 0000 l_REG_BANK_1 0000 l_REG_BANK_2 0000 l_REG_BANK_3 0000 l_XINIT 0000 l_XISEG 0000 l_XSEG 0000 l__CODE 0000 s_BSEG 0000 s_CSEG 0000 s_REG_BANK_0 0000 s_XISEG 0000 s_XSEG 0000 s__CODE 0001 l_BSEG 0001 l_BSEG_BYTES 0001 l_SSEG 0003 l_GSFINAL 0008 l_REG_BANK_0 0008 s_REG_BANK_1 0010 s_REG_BANK_2 0018 s_REG_BANK_3 0020 G$byte1$0$0 0020 _byte1 0020 s_BSEG_BYTES 0021 s_DSEG 0021 s_OSEG 0021 s_SSEG 0023 s_ISEG 003F l_CSEG 003F s_GSINIT 0041 l_GSINIT 0080 G$P0$0$0 0080 G$P0_0$0$0 0080 s_GSFINAL 0081 G$P0_1$0$0 0082 G$P0_2$0$0 0083 G$P0_3$0$0 0083 s_HOME 0083 s_XINIT 0084 G$P0_4$0$0 0085 G$P0_5$0$0 0086 G$P0_6$0$0 0087 G$P0_7$0$0 Hexadecimal Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ _CODE 0000 0000 = 0. bytes (REL,CON) Hexadecimal Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ REG_BANK_0 0000 0008 = 8. bytes (REL,OVR) Hexadecimal Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ REG_BANK_1 0008 0000 = 0. bytes (REL,OVR) Hexadecimal Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ REG_BANK_2 0010 0000 = 0. bytes (REL,OVR) Hexadecimal Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ REG_BANK_3 0018 0000 = 0. bytes (REL,OVR) Hexadecimal Area Addr Size Decimal Bits (Attributes) -------------------------------- ---- ---- ------- ----- ------------ BSEG 0000 0001 = 1. bits (REL,CON,BIT) Value Global -------- -------------------------------- 0B:0000 G$bit2$0$0 0B:0000 _bit2 Hexadecimal Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ BSEG_BYTES 0020 0001 = 1. bytes (REL,CON) Hexadecimal Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ DSEG 0021 0000 = 0. bytes (REL,CON) Hexadecimal Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ OSEG 0021 0000 = 0. bytes (REL,OVR) Hexadecimal Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ SSEG 0021 0001 = 1. bytes (REL,CON) Hexadecimal Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ ISEG 0023 0000 = 0. bytes (REL,CON) Hexadecimal Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ XSEG 0000 0000 = 0. bytes (REL,CON,XDATA) Hexadecimal Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ XISEG 0000 0000 = 0. bytes (REL,CON,XDATA) Hexadecimal Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ CSEG 0000 003F = 63. bytes (REL,CON,CODE) Value Global -------- -------------------------------- 0C:0000 A$main$88 0C:0003 A$main$89 0C:000B A$main$91 0C:0013 A$main$93 0C:001B A$main$95 0C:0023 A$main$97 0C:002B A$main$99 0C:0033 A$main$163 0C:0036 A$main$165 0C:0038 A$main$189 0C:0038 C$main.c$23$0$0 0C:0038 C$main.c$25$1$1 0C:0038 G$main$0$0 0C:0038 _main 0C:003A A$main$193 0C:003A C$main.c$29$1$1 0C:003A XG$main$0$0 0C:003B __sdcc_external_startup Hexadecimal Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ GSINIT 003F 0041 = 65. bytes (REL,CON,CODE) Value Global -------- -------------------------------- 0C:003F A$main$108 0C:0042 A$main$109 0C:0045 A$main$110 0C:0047 A$main$111 0C:0049 A$main$112 0C:004C A$main$115 0C:004E A$main$116 0C:0050 A$main$117 0C:0052 A$main$118 0C:0054 A$main$119 0C:0056 A$main$120 0C:0057 A$main$121 0C:0059 A$main$122 0C:005B A$main$123 0C:005C A$main$124 0C:005F A$main$125 0C:0061 A$main$126 0C:0064 A$main$127 0C:0065 A$main$128 0C:0066 A$main$129 0C:0067 A$main$130 0C:0068 A$main$131 0C:0069 A$main$132 0C:006C A$main$133 0C:006E A$main$134 0C:0070 A$main$135 0C:0073 A$main$136 0C:0075 A$main$137 0C:0078 A$main$138 0C:007B A$main$145 0C:007B C$main.c$16$1$1 0C:007E A$main$150 0C:007E C$main.c$19$1$1 Hexadecimal Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ GSFINAL 0080 0003 = 3. bytes (REL,CON,CODE) Value Global -------- -------------------------------- 0C:0080 A$main$152 Hexadecimal Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ HOME 0083 0000 = 0. bytes (REL,CON,CODE) Hexadecimal Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ XINIT 0083 0000 = 0. bytes (REL,CON,CODE) ASxxxx Linker V01.70 + NoICE + SDCC Feb 1999, page 1. Files Linked [ module(s) ] main.rel Libraries Linked [ object file ] C:\Cygnal\sdcc\lib\small/libsdcc.lib [ _startup ] ASxxxx Linker V01.70 + NoICE + SDCC Feb 1999, page 2. User Base Address Definitions CSEG = 0x0000 XSEG = 0x0000 ISEG = 0x0023 BSEG = 0x0000 _________________________map_file_end_______________ This email and any files transmitted with it are confidential and/or legally privileged and intended solely for the use of the individual or entity to whom they are addressed. If you are not the addressee indicated in this email (or responsible for the delivery of the email to such person) be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you have received this email in error please notify the sender by reply email and then immediately permanently delete it and all copies from your system. Whilst we maintain virus checks, we accept no liability for viruses introduced from this email. |
From: Scott B. <br...@ri...> - 2003-10-25 16:43:17
|
On Wed, 2003-10-22 at 07:14, Goovaerts, Marc wrote: > It seems to me that sdcc generates overlapping memory useage. > The automatic variable bit2 (the bit segment) is located at 0x20 although > i manually assigned a bit addressable byte at 0x20. In my opinion, sdcc > should see this and start at 0x21 for placing the automatic bits. > I also don't know about a linker option for determining BSEG location, so > there's no way to circumvent this problem. I got bit by something like this -- my ISRs were overwriting each other. It appeared to be an asXXXX linking problem, but I haven't investigated too far -- I just wrote all my ISRs as _naked void functions containing inline asm. So, I can relate, but I don't have an answer for you. :-/ As a workaround for your simultaneous bit/byte access, have you tried using a union? I've never had need for such a thing, but I think it definitely has a nonzero chance of success. :) Sorry I can't be of more help... - Scott |
From: Diego M. M. <ti...@ti...> - 2003-10-25 18:00:15
|
where can i found pic code for sdcc? i'm new in c and in sdcc :) thanks -- Diego Manenti Martins Técnico em eletrônica CREA/SC 63164-0 ti...@ti... |
From: Diego M. M. <ti...@ti...> - 2003-10-26 16:38:47
|
nobody use sdcc for pic? Diego Manenti Martins wrote: > where can i found pic code for sdcc? > i'm new in c and in sdcc :) > thanks > > -- Diego Manenti Martins Técnico em eletrônica CREA/SC 63164-0 ti...@ti... |
From: Paul B. <pau...@su...> - 2003-10-26 19:01:44
|
Oh fer Gawd's sake! Use assembler. Paul ----- Original Message -----=20 From: "Diego Manenti Martins" <ti...@ti...> To: <sdc...@li...> Sent: Sunday, October 26, 2003 2:37 PM Subject: Re: [Sdcc-user] pic code > nobody use sdcc for pic? > > > Diego Manenti Martins wrote: > > where can i found pic code for sdcc? > > i'm new in c and in sdcc :) > > thanks > > > > > > --=20 > Diego Manenti Martins > T=E9cnico em eletr=F4nica > CREA/SC 63164-0 > ti...@ti... > > > > ------------------------------------------------------- > This SF.net email is sponsored by: The SF.net Donation Program. > Do you like what SourceForge.net is doing for the Open > Source Community? Make a contribution, and help us add new > features and functionality. Click here: http://sourceforge.net/donate/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Diego M. M. <ti...@ti...> - 2003-10-26 20:24:58
|
you are too funy.. Paul Bartlett wrote: > Oh fer Gawd's sake! Use assembler. > > Paul > > ----- Original Message ----- > From: "Diego Manenti Martins" <ti...@ti...> > To: <sdc...@li...> > Sent: Sunday, October 26, 2003 2:37 PM > Subject: Re: [Sdcc-user] pic code > > > >>nobody use sdcc for pic? >> >> >>Diego Manenti Martins wrote: >> >>>where can i found pic code for sdcc? >>>i'm new in c and in sdcc :) >>>thanks >>> >>> >> >>-- >>Diego Manenti Martins >>Técnico em eletrônica >>CREA/SC 63164-0 >>ti...@ti... >> >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: The SF.net Donation Program. >>Do you like what SourceForge.net is doing for the Open >>Source Community? Make a contribution, and help us add new >>features and functionality. Click here: http://sourceforge.net/donate/ >>_______________________________________________ >>Sdcc-user mailing list >>Sdc...@li... >>https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: The SF.net Donation Program. > Do you like what SourceForge.net is doing for the Open > Source Community? Make a contribution, and help us add new > features and functionality. Click here: http://sourceforge.net/donate/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > -- Diego Manenti Martins Técnico em eletrônica CREA/SC 63164-0 ti...@ti... |
From: Paul B. <pau...@su...> - 2003-10-27 10:02:17
|
Nah. I was serious. c has its place and is my language of choice for most purposes but PIC microcontrollers barely have the resources to support a language that requires a stack frame. Assembler is the best solution for PICs IMHO. Best, Paul :-) > -----Original Message----- > From: sdc...@li... > [mailto:sdc...@li...]On > Behalf Of Diego Manenti > Martins > Sent: 26 October 2003 18:18 > To: sdc...@li... > Subject: Re: [Sdcc-user] pic code > > > you are too funy.. > > Paul Bartlett wrote: > > Oh fer Gawd's sake! Use assembler. > > > > Paul > > > > ----- Original Message ----- > > From: "Diego Manenti Martins" <ti...@ti...> > > To: <sdc...@li...> > > Sent: Sunday, October 26, 2003 2:37 PM > > Subject: Re: [Sdcc-user] pic code > > > > > > > >>nobody use sdcc for pic? > >> > >> > >>Diego Manenti Martins wrote: > >> > >>>where can i found pic code for sdcc? > >>>i'm new in c and in sdcc :) > >>>thanks > >>> > >>> > >> > >>-- > >>Diego Manenti Martins > >>Técnico em eletrônica > >>CREA/SC 63164-0 > >>ti...@ti... > >> > >> > >> > >>------------------------------------------------------- > >>This SF.net email is sponsored by: The SF.net > Donation Program. > >>Do you like what SourceForge.net is doing for the Open > >>Source Community? Make a contribution, and help us add new > >>features and functionality. Click here: > http://sourceforge.net/donate/ > >>_______________________________________________ > >>Sdcc-user mailing list > >>Sdc...@li... > >>https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: The SF.net > Donation Program. > > Do you like what SourceForge.net is doing for the Open > > Source Community? Make a contribution, and help us add new > > features and functionality. Click here: > http://sourceforge.net/donate/ > > _______________________________________________ > > Sdcc-user mailing list > > Sdc...@li... > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > > > > -- > Diego Manenti Martins > Técnico em eletrônica > CREA/SC 63164-0 > ti...@ti... > > > > ------------------------------------------------------- > This SF.net email is sponsored by: The SF.net > Donation Program. > Do you like what SourceForge.net is doing for the Open > Source Community? Make a contribution, and help us add new > features and functionality. Click here: > http://sourceforge.net/donate/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Steve T. <te...@te...> - 2003-10-29 15:56:11
|
On Mon, 27 Oct 2003, Paul Bartlett wrote: > Nah. I was serious. > > c has its place and is my language of choice for most purposes > but PIC microcontrollers barely have the resources to support a > language that requires a stack frame. I've seen sdcc -mpic generate some pretty decent code (and some lousy code). I expect for a long time to have to study the .asm output of sdcc to see what its done - so you have to know PIC assembly _better_ when using sdcc than if you were hand-coding. But you'll still get the benefit of having your algorithms expressed in C. Of course, the stack limitation is there - best limit yourself to C functions that take only a single 'char' argument and return only 'char', and do the rest with globals, which is roughly what sdcc will have to try to do for you anyway. That said, the pic port is completely broken in CVS right now. Most of the regressions fail to gplink with: error: no target memory available for section ".udata" Some still have this failure that's been around for a few months: compare3.asm:830:Error [113] Symbol not previously defined (r0x20). For the moment, the only place for C programmers here is inside sdcc's pic port, working to fix and enhance it... That's where I'll be when I get time. |
From: Steffen K. <tax...@op...> - 2003-11-29 23:23:14
|
> Some still have this failure that's been around for a few months: > compare3.asm:830:Error [113] Symbol not previously defined (r0x20). > > For the moment, the only place for C programmers here is inside sdcc's pic > port, working to fix and enhance it... That's where I'll be when I get > time. Yes, it is very sad that the development of the pic port does not continue... I am a C coder and know the PIC very good, but i have no knowledge in building a compiler. I used the whole day to track down a problem why the compiler does not generate banksel's for registers which never have a write access, only read access in the code. Now i found out that the address fields in the pCode's have the value "0" (which forces the banksel generating code to fail) when there is no write access to the register in the whole code. This is because the function allocDirReg(operand *op) (that assigns the address) is only called for a reg if there is a write access to this reg. But i think i have not enough knowledge to fix this bug in a good way. Are there people on this list that can help with the pic port? Scott, where are you? ;) cu, Steffen |
From: Scott D. <sc...@da...> - 2003-11-30 15:58:55
|
On Sun, 30 Nov 2003, Steffen Koepf wrote: > Scott, where are you? ;) Here I am! Steffan, my apologies to you and all other SDCC PIC users. Over the last year and a half I've had little time for SDCC. As it stands, the PIC port is mostly done. But mostly done is hardly acceptable for a compiler. Over the last two months I've started back into Open Source development. I've been working on gpsim (the GNUPIC simulator). I expect to be working on gpsim for at least a few more months. After that I may be able to revisit SDCC. Meanwhile, I'll gladly try to help answer specific questions about the PIC port. Regards, Scott |
From: Steffen K. <tax...@op...> - 2003-12-07 21:42:24
|
Hi Scott, no problem, your work is great. I used the sdcc for a Solar Charge Controller with a PIC16F876, it is possible to use it, but i found some bugs and try to fix them. Let's start with the first.. it would be great if you can give a few hints/comments to the following. bug5.c: ----------------------------------- #define __16F876 #include "pic16f876.h" void main() { unsigned char bl,bh; // ADRESL = 0; bl = ADRESH; bh = ADRESL; PORTA = bl; TRISA = bh; } ----------------------------------- It does not generate working assembly code if it is used like printed, but if the comment before "ADRESL = 0;" is removed, it works. ----------------------------------- ;entry: _main ;Function start ; 2 exit points ;has an exit ;; Starting pCode block _main ;Function start ; 2 exit points ;#CSRC bug5.c 8 ; bl = ADRESH; MOVF _ADRESH,W MOVWF _PORTA ;#CSRC bug5.c 9 ; bh = ADRESL; MOVF _ADRESL,W BSF STATUS,5 MOVWF _TRISA BCF STATUS,5 ;#CSRC bug5.c 11 ; TRISA = bh; RETURN ; exit point of _main ----------------------------------- As one can see, there is a bank switch missing before " MOVF _ADRESL,W" (ADRESL is in bank 1 while ADRESH, PORTA are in bank 0). I wrote a small function that prints the pCodes (name, address, ...) Called at the beginning of picglue (), the output is: ----------------------------------- _ADRESH addr = 0x000, bank = 0, bit=0 _PORTA addr = 0x005, bank = 0, bit=0 _ADRESL addr = 0x000, bank = 0, bit=0 _TRISA addr = 0x085, bank = 1, bit=0 ----------------------------------- As one can see, the address stored in this list for ADRESL is 0 which leads to a missing bank switch later. With "ADRESL = 0;" at the beginning of the c source, we get: ----------------------------------- _ADRESH addr = 0x01e, bank = 0, bit=0 _PORTA addr = 0x005, bank = 0, bit=0 _ADRESL addr = 0x09e, bank = 1, bit=0 _TRISA addr = 0x085, bank = 1, bit=0 ----------------------------------- The addr's contain the correct values and the bank selects are ok -> code works. After some researches i found out, that a correct addr is stored in the pCode only when there is a write to the register in question somewhere in the code. In the example, we can see that there is no write to ADRESH, ADRESL but to the other regs, and the result is that the other regs have correct addr's, and 0 for ADRESH and ADRESL. It seems that allocDirReg (operand *op ) assigns the addresses to the (fixed) registers. This function is *not* called for registers that have no write instruction somewhere in the code. packRegisters (eBBlock * ebp) calls sometimes packRegsForAssign (iCode * ic, eBBlock * ebp) and this fct. calls then allocDirReg (operand *op ). packRegisters (eBBlock * ebp) ... /* look for assignments of the form */ /* iTempNN = TRueSym (someoperation) SomeOperand */ /* .... */ /* TrueSym := iTempNN:1 */ for (ic = ebp->sch; ic; ic = ic->next) { allocDirReg(IC_RIGHT (ic)); /* WORKAROUND WORKAROUND WORKAROUND */ /* find assignment of the form TrueSym := iTempNN:1 */ if (ic->op == '=' && !POINTER_SET (ic)) change += packRegsForAssign (ic, ebp); /* debug stuff */ if (ic->op == '=') { if (POINTER_SET (ic)) debugLog ("pointer is set\n"); debugAopGet (" result:", IC_RESULT (ic)); debugAopGet (" left:", IC_LEFT (ic)); debugAopGet (" right:", IC_RIGHT (ic)); } } packRegsForAssign is only called for a certain type of assignments. ADRESL is never assigned any value... so it is never given to allocDirReg. I made a workaround by calling allocDirReg(IC_RIGHT (ic)); for every ic. I do not know what the side-effects are, but it generates correct code now. Have you an ideas on how to fix it in a better way? cu, Steffen |
From: Scott D. <sc...@da...> - 2003-12-07 23:34:47
|
On Sun, 7 Dec 2003, Steffen Koepf wrote: > Hi Scott, > > no problem, your work is great. I used the sdcc for a > Solar Charge Controller with a PIC16F876, it is possible to use > it, but i found some bugs and try to fix them. > Let's start with the first.. it would be great if you can > give a few hints/comments to the following. Thanks for the complement, I just wish I had enough time to finish up the job. > > bug5.c: > ----------------------------------- > #define __16F876 > #include "pic16f876.h" > > void main() { > unsigned char bl,bh; > // ADRESL = 0; > > bl = ADRESH; > bh = ADRESL; > PORTA = bl; > TRISA = bh; > } > ----------------------------------- > > It does not generate working assembly code if it is used like > printed, but if the comment before "ADRESL = 0;" is removed, > it works. <snip - analysis of the bug and a fix> Steffan, Your analysis appears correct! A register appears to only get assigned an address if a value is written to it. One way to tell if your proposed fix has a side effect is by running the PIC regression test. It's located in src/regression/ (although it should probably be moved to where the other regression tests are stored...). You're going to need gpsim since the code's correctness is validated by simulation. Checkout the README there and if you have questions let me know. BTW, it doesn't hurt to keep little snippets like this example as regression tests. It's amazing how fixes in one area can inadvertantly break working code in another area. Scott |
From: Vangelis R. <vr...@ot...> - 2003-12-14 01:46:18
|
----- Original Message ----- From: "Steffen Koepf" <tax...@op...> To: <sdc...@li...> Sent: Sunday, November 30, 2003 1:23 AM Subject: Re: [Sdcc-user] pic code / New banksel bug found > > Some still have this failure that's been around for a few months: > > compare3.asm:830:Error [113] Symbol not previously defined (r0x20). > > > > For the moment, the only place for C programmers here is inside sdcc's pic > > port, working to fix and enhance it... That's where I'll be when I get > > time. > Can you sent me the source code that generated the message? I had a similar problem in the PIC16 port and fixed it (in a bit unusual way, but its definetely an unusual bug!:) My bug was with symbols that were used for the first time in expressions like addition, i.e. char temp; a = temp + 2; would eliminate the `temp' variable, and produce a `Symbol not previously defined' error. If the source of the error is similar, the problem is in the register allocator that does not recognise allocate the `temp' variable when it scans the iCode list. I have made a workaround, but only in the pic16 port. I am supporting for the time being the pic16 port, and possibly I could get into the pic internals, although I haven't much experience. Regards, Vangelis Rokas |
From: Steve T. <te...@te...> - 2003-12-20 19:58:05
|
On Sun, 14 Dec 2003, Vangelis Rokas wrote: > ----- Original Message ----- > From: "Steffen Koepf" <tax...@op...> > To: <sdc...@li...> > Sent: Sunday, November 30, 2003 1:23 AM > Subject: Re: [Sdcc-user] pic code / New banksel bug found > > > > > Some still have this failure that's been around for a few months: > > > compare3.asm:830:Error [113] Symbol not previously defined (r0x20). > > > > > > For the moment, the only place for C programmers here is inside sdcc's > pic > > > port, working to fix and enhance it... That's where I'll be when I get > > > time. Sounds like an error I've seen. > Can you sent me the source code that generated the message? I had a > similar problem > in the PIC16 port and fixed it (in a bit unusual way, but its definetely an > unusual bug!:) I saw this in code like sdcc/src/regression/compare3.c, part of the pic14 test suite included with the sdcc development tree. cd there and do "make compare3.o" to evoke the error. > My bug was with symbols that were used for the first time in expressions > like addition, i.e. > > char temp; > > a = temp + 2; > > would eliminate the `temp' variable, and produce a `Symbol not previously > defined' error. I've seen a bug very much like this in the pic14 tree. I encountered it most often with SFR registers that were read from but never written to, and was sometimes able to work around it by assigning to the register somewhere. > If the source of the error is similar, the problem is in the register > allocator that does not > recognise allocate the `temp' variable when it scans the iCode list. I have > made a workaround, > but only in the pic16 port. Is your change in CVS? If you were to point me to it, I could try it on the pic14 side. > I am supporting for the time being the pic16 port, and possibly I could get > into the pic internals, > although I haven't much experience. The more the merrier! Especialy if problems you fix on the pic16 port are present on the pic14 side, anything you can do to share that knowledge would be appreciated. Otherwise someone else will have to make the same investigation. Steve |