From: Vangelis R. <vr...@ot...> - 2004-06-04 23:22:47
|
A new big set of patches has been committed to the CVS for thePIC16 port To take advantage of them you'll need either to perform a checkout of the device/lib/pic16 directory and then an update of the whole tree if you use CVS, or a fresh checkout. Among others the features are: 1. Header and device library sources for the following chips: 18f1220, 18f6520, 18f6620, 18f6680, 18f6720, 18f8520, 18f8620, 18f8680, 18f8720 2. Many have asked for configuration macros. You got them. Now in each device's header file are included macros for a. the names and the locations of the configuration registers b. the names and the values of the configuration bits The new scheme for defining the value of a configuration register is: #include <pic18fregs.h> // or i.e. <pic18f452.h> code char at __CONFIG0H _conf0 = _OSCS_ON_0H & _OSC_HS_0H; as you can see the __CONFIG0H is a macro that expands to the value 0x300001. Note the registers are counting from 0 not from 1. 0H is the word count 0 and L for low, or H for high byte, in the fields, all macros are appended with their respective register so no its easy to find mistakes. The only drawback here that for some fields the macros can be a bit too long, because the automatic script that creates them needs to overcome ambiguity. The variable _conf0 is not accessible from inside the program, but should be unique. This may change in the future and allow the user to read them on run-time. 3. A new library has been introduced, called libsdcc.lib. This library contains the support functions for char/int/long/float multiplication/division/modulo. The main purpose was to have the sources compiled. Extensive test for the integrity of the results hasn't been done yet. On the other hand, all these file come from the sdcc library, so the sources *should* be bug free. 4. A new set of startup files has been introduced. These are three (3) .c sources: crt0.c, crt0i.c, crt0iz.c Their purpose is to initialise various variables after reset. a. crt0 hooks the reset vector and calls the use main function, b. crt0i same as crt0 but initialises variables before calling main, c. crt0iz same as crt0i but clear RAM before initalisation These files are more or less like the ones found in the Microchip's C18 compiler. Their use isn't standard yet for reasons of compatibility and for allowing the users to get familiar with this scheme. The old way to compile programs with the use of the --pomit-ivt --pleave-reset-vector is still applicable. But variables with initialisers will no be processed. The way to use the feature is to use --pomit-ivt only and add the command line argument for library, i.e. -lcrt0i.o when issuing sdcc. This will link crt0i.o. Of course one should have compiled the libraries first. 5. Initialisations of pointers and structures is not finished yet. Its a quite painful procedure which I wish to finish in the next weeks. 6. The command line arguments --asm= and --link= have been introduced to allow the use of an alternative assembler and linker respectively. 7. Peepholes are now automatically disabled by the port, so the argument --no-peep is necessary to be added at command line anymore. Well, that's all. I am looking forward for your comments. I hope Matthias and George will find the changes useful. Vangelis Rokas PS. Although the structure of the device/lib/pic16 directory has changed, the procedure to build the libraries remains the same: issue ./configure in the device/lib/pic16 directory, and then from device/lib issue: make model-pic16 This will build all the libraries and place them in device/lib/build/pic16, then you can issue: make install (preferably as root to install them to their proper places. The scripts for building under Windows will soon be added to the CVS. |
From: George M. G. <gga...@co...> - 2004-06-05 13:28:44
|
Vangelis, I downloaded the sdcc-20040605. Below are the errors while building the pic16 libraries. It looks like the asm file was built for mcs51. The math functions built without any problems. I will try to load a test program into a pic18f242 this weekend. make[1]: Entering directory `/home3/local/src/pic/sdcc/sdcc-20040605/device/lib/pic16/startup' ../../../../bin/sdcc --nostdinc --nostdlib -c crt0.c ?ASxxxx-Error-<o> in line 85 of crt0.asm <o> .org in REL area or directive / mnemonic error ?ASxxxx-Error-<o> in line 107 of crt0.asm <o> .org in REL area or directive / mnemonic error ?ASxxxx-Error-<o> in line 108 of crt0.asm <o> .org in REL area or directive / mnemonic error ?ASxxxx-Error-<o> in line 109 of crt0.asm <o> .org in REL area or directive / mnemonic error ?ASxxxx-Error-<o> in line 110 of crt0.asm <o> .org in REL area or directive / mnemonic error ?ASxxxx-Error-<o> in line 111 of crt0.asm <o> .org in REL area or directive / mnemonic error removing crt0.rel make[1]: *** [crt0.o] Error 1 make[1]: Leaving directory `/home3/local/src/pic/sdcc/sdcc-20040605/device/lib/pic16/startup' make: *** [build-all-libraries] Error 2 Regards, George Vangelis Rokas wrote: >A new big set of patches has been committed to the CVS for thePIC16 port > >To take advantage of them you'll need either to perform a checkout of the >device/lib/pic16 directory and then an update of the whole tree if you use >CVS, or a fresh checkout. > >Among others the features are: > >1. Header and device library sources for the following chips: > 18f1220, 18f6520, 18f6620, 18f6680, > 18f6720, 18f8520, 18f8620, 18f8680, > 18f8720 > >2. Many have asked for configuration macros. You got them. >Now in each device's header file are included macros for > a. the names and the locations of the configuration registers > b. the names and the values of the configuration bits > >The new scheme for defining the value of a configuration register is: > >#include <pic18fregs.h> // or i.e. <pic18f452.h> >code char at __CONFIG0H _conf0 = _OSCS_ON_0H & _OSC_HS_0H; > >as you can see the __CONFIG0H is a macro that expands to the value 0x300001. >Note the registers are counting from 0 not from 1. 0H is the word count 0 and >L for low, or H for high byte, >in the fields, all macros are appended with their respective register so no >its easy to find mistakes. > >The only drawback here that for some fields the macros can be a bit too long, >because the automatic script that creates them needs to overcome ambiguity. > >The variable _conf0 is not accessible from inside the program, but should be >unique. This may change in the future and allow the user to read them on >run-time. > >3. A new library has been introduced, called libsdcc.lib. This library >contains the support functions for char/int/long/float >multiplication/division/modulo. >The main purpose was to have the sources compiled. Extensive test for the >integrity of the results hasn't been done yet. On the other hand, all these >file come from the sdcc library, so the sources *should* be bug free. > >4. A new set of startup files has been introduced. These are three (3) .c >sources: crt0.c, crt0i.c, crt0iz.c >Their purpose is to initialise various variables after reset. > a. crt0 hooks the reset vector and calls the use main function, > b. crt0i same as crt0 but initialises variables before calling main, > c. crt0iz same as crt0i but clear RAM before initalisation > >These files are more or less like the ones found in the Microchip's C18 >compiler. > >Their use isn't standard yet for reasons of compatibility and for allowing the >users to get familiar with this scheme. > >The old way to compile programs with the use of the --pomit-ivt >--pleave-reset-vector is still applicable. But variables with initialisers >will no be processed. > >The way to use the feature is to use --pomit-ivt only and add the command line >argument for library, i.e. -lcrt0i.o when issuing sdcc. >This will link crt0i.o. > >Of course one should have compiled the libraries first. > >5. Initialisations of pointers and structures is not finished yet. Its a quite >painful procedure which I wish to finish in the next weeks. > >6. The command line arguments --asm= and --link= have been introduced to allow >the use of an alternative assembler and linker respectively. > >7. Peepholes are now automatically disabled by the port, so the argument >--no-peep is necessary to be added at command line anymore. > >Well, that's all. I am looking forward for your comments. >I hope Matthias and George will find the changes useful. > >Vangelis Rokas > > >PS. >Although the structure of the device/lib/pic16 directory has changed, the >procedure to build the libraries remains the same: issue > ./configure >in the device/lib/pic16 directory, and then from device/lib issue: > make model-pic16 >This will build all the libraries and place them in device/lib/build/pic16, >then you can issue: > make install (preferably as root >to install them to their proper places. >The scripts for building under Windows will soon be added to the CVS. > > > >------------------------------------------------------- >This SF.Net email is sponsored by the new InstallShield X. >>From Windows to Linux, servers to mobile, InstallShield X is the one >installation-authoring solution that does it all. Learn more and >evaluate today! http://www.installshield.com/Dev2Dev/0504 >_______________________________________________ >Sdcc-user mailing list >Sdc...@li... >https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > |
From: Vangelis R. <vr...@ot...> - 2004-06-05 16:02:27
|
On Sat, 5 Jun 2004, George M. Gallant wrote: > Vangelis, > > I downloaded the sdcc-20040605. Below are the errors while building > the pic16 libraries. It looks like the asm file was built for mcs51. The > math > functions built without any problems. I will try to load a test program into > a pic18f242 this weekend. > > make[1]: Entering directory > `/home3/local/src/pic/sdcc/sdcc-20040605/device/lib/pic16/startup' > ../../../../bin/sdcc --nostdinc --nostdlib -c crt0.c > ?ASxxxx-Error-<o> in line 85 of crt0.asm > <o> .org in REL area or directive / mnemonic error That's an error from my side... edit the Makefile in the device/lib/pic16/startup directory and add $(MODELFLAG) to the COMPILE_FLAGS variable. Eventually, it should look like: COMPILE_FLAGS += $(MODELFLAGS) --nostdinc --nostdlib I'll correct the bug as soon as possible, Thanks for the report. Vangelis |
From: George M. G. <gga...@co...> - 2004-06-05 16:47:29
|
vangelis, Success. George Vangelis Rokas wrote: >On Sat, 5 Jun 2004, George M. Gallant wrote: > > > >>Vangelis, >> >>I downloaded the sdcc-20040605. Below are the errors while building >>the pic16 libraries. It looks like the asm file was built for mcs51. The >>math >>functions built without any problems. I will try to load a test program into >>a pic18f242 this weekend. >> >>make[1]: Entering directory >>`/home3/local/src/pic/sdcc/sdcc-20040605/device/lib/pic16/startup' >>../../../../bin/sdcc --nostdinc --nostdlib -c crt0.c >>?ASxxxx-Error-<o> in line 85 of crt0.asm >> <o> .org in REL area or directive / mnemonic error >> >> > >That's an error from my side... >edit the Makefile in the device/lib/pic16/startup directory and add >$(MODELFLAG) to the COMPILE_FLAGS variable. > >Eventually, it should look like: > >COMPILE_FLAGS += $(MODELFLAGS) --nostdinc --nostdlib > >I'll correct the bug as soon as possible, >Thanks for the report. > >Vangelis > > >------------------------------------------------------- >This SF.Net email is sponsored by the new InstallShield X. >>From Windows to Linux, servers to mobile, InstallShield X is the one >installation-authoring solution that does it all. Learn more and >evaluate today! http://www.installshield.com/Dev2Dev/0504 >_______________________________________________ >Sdcc-user mailing list >Sdc...@li... >https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > |
From: George M. G. <gga...@co...> - 2004-06-06 17:18:18
|
Vamgelis, I applied sdcc 20046605 to a medium sized project that was developed with mcc. I compile to asm so that the output is readable. Some observations: 1. If an array is declared in a module but never actually used, the compiler generates a global declaration but does not create the variable proper. Work around is to create a dummy procedure that zeros the variables. 2. The following snippet compiles but dies in gpasm due to an undefined label. It generates a return address on the hardware stack using _000144_DS_ but does not generate the label. if (fp != NULL) (fp)(); 3. The make install in the device/pic16 clobbers the asm files. Not so nice for us who add their own asm entries to the libaries or who want to debug the libs!!!! Regards, George |
From: Vangelis R. <vr...@ot...> - 2004-06-06 20:50:36
|
On Sunday 06 June 2004 20:18, George M. Gallant wrote: > I applied sdcc 20046605 to a medium sized project that was developed > with mcc. I compile > to asm so that the output is readable. Some observations: > > 1. If an array is declared in a module but never actually used, the > compiler generates a global declaration but does not create the variable > proper. Work around is to create a dummy procedure that zeros the variables. No dummy procedure. It was a bug of the port. It is fixed now. I'll update the CVS later this evening. > 2. The following snippet compiles but dies in gpasm due to an > undefined label. It generates a return address on the hardware stack using > _000144_DS_ but does not generate the label. > > if (fp != NULL) (fp)(); Another bug. This time the label was optimised out by pCode optimiser. I don't know why Hans (who rewrote the specific section) didn't trace the bug. Probably he didn't try the if-statement before calling fp(). The missing label is exactly before the label where if- jumps if test is false, so we have two labels in a row (and in fact, the first, the return point, is not referenced explicit in the source!). So the optimiser thinks that its good to remove one of them. Guess which was chosen;-) ANW, I fixed that too, you'll find it in the CVS in a few hours. > 3. The make install in the device/pic16 clobbers the asm files. Not > so nice for us who add their own > asm entries to the libaries or who want to debug the libs!!!! I don't understand what you mean here. You can always rebuild the pic16 libraries if you run 'make' in the device/lib/pic16 directory. I hope this helps. Regards, Vangelis |
From: George M. G. <gga...@co...> - 2004-06-07 02:13:12
|
Vangelis, sdcc is generating extern lables such as extern _DDRE and _DDRE is not defined in the pic16 libaries! You did ask for end user comments!!!! George |
From: Vangelis R. <vr...@ot...> - 2004-06-07 06:57:59
|
On Sun, 6 Jun 2004, George M. Gallant wrote: > sdcc is generating extern lables such as > > extern _DDRE > > and _DDRE is not defined in the pic16 libaries! > You did ask for end user comments!!!! I did ask, but these information are not enough. Which source are you compiling? Which pic16 libraries define the symbol? What arguments? Vangelis |
From: George M. G. <gga...@co...> - 2004-06-07 02:03:32
|
Vangelis, I just download sdcc via cvs. I am unable to install the pic16 libraries because of the CVS directories. The copy commands are failing which causes make to abort. I tried to compile a module that contains something similiar to: static const char my_data[] = {1,2,3,4}; sdcc generates asm code of: my_data: 1 my_data: 2 my_data: 3 my_data: 4 which the assemble rejects. I also tried to compile a crc16 routine that uses 256 16 bit unsigned integers. The compiler turns my: 0x1234 into db 0x34 db 0x12 and whenever the code is ascii it outputs as quoted text. It even quotes the quote and backslash characters in a maner that the assembler chokes on. This may not be a pic16 only problem. The _strxxx functions seem to compile ok. I built a string directory, like the char & int, and created a string library. I did not look and any of the generated code or test. Regards, George |
From: Vangelis R. <vr...@ot...> - 2004-06-07 06:54:38
|
On Sun, 6 Jun 2004, George M. Gallant wrote: > I just download sdcc via cvs. I am unable to install the pic16 libraries > because > of the CVS directories. The copy commands are failing which causes make to > abort. What do you mean because of the CVS directories? Which OS are you using? Send me more information, I cannot which copy commands are failing!... > I tried to compile a module that contains something similiar to: > > static const char my_data[] = {1,2,3,4}; > > sdcc generates asm code of: > > my_data: 1 > my_data: 2 > my_data: 3 > my_data: 4 > > which the assemble rejects. Yes, it does so. In general variable initialisations are a bit of a headache. I'll try to fix this. > I also tried to compile a crc16 routine that uses 256 16 bit unsigned > integers. The > compiler turns my: > > 0x1234 > into > db 0x34 > db 0x12 > > and whenever the code is ascii it outputs as quoted text. It even quotes > the quote > and backslash characters in a maner that the assembler chokes on. This > may not be a pic16 only problem. I don't think so. I have made the changes to print 'printable' characters in quotes. There are two solutions. 1. to recognise the quote and backslash, and esacpe them, 2. revert to the old 0x hex bytes, I think I should revert to the old code. > The _strxxx functions seem to compile ok. I built a string directory, > like the char & int, and > created a string library. I did not look and any of the generated code > or test. Yes, I know that! At least there something working!;-) Vangelis |
From: <mat...@ph...> - 2004-06-05 22:38:35
|
Hi Vangelis, Attachments: <none> Saturday, June 5, 2004, 1:27:05 AM, you wrote: > A new big set of patches has been committed to the CVS for thePIC16 port Wow, that's a pretty big set of new features! > #include <pic18fregs.h> // or i.e. <pic18f452.h> > code char at __CONFIG0H _conf0 = _OSCS_ON_0H & _OSC_HS_0H; That's cool. I tried: code char at __CONFIG3L _conf3 = _STVR_OFF_3L & _LVP_OFF_3L; It doesn't seem to produce the appropriate code right now. > 3. A new library has been introduced, called libsdcc.lib. This library > contains the support functions for char/int/long/float > multiplication/division/modulo. > The main purpose was to have the sources compiled. Extensive test for the > integrity of the results hasn't been done yet. On the other hand, all these > file come from the sdcc library, so the sources *should* be bug free. > 4. A new set of startup files has been introduced. These are three (3) .c > sources: crt0.c, crt0i.c, crt0iz.c > Their purpose is to initialise various variables after reset. > a. crt0 hooks the reset vector and calls the use main function, > b. crt0i same as crt0 but initialises variables before calling main, > c. crt0iz same as crt0i but clear RAM before initalisation I tried to compile these libs on my windows machine with the latest sdcc windows binary: e.g.: sdcc --pomit-config-words -mpic16 --pomit-ivt --nostdinc -Ic:\Programme\sdcc\include\pic16 -S divschar.c This failed with a crash dump. I ll try to recompile the sdcc with my visual studio. But currently I can't import the project files. Visual Studio says "failed to load damaged project files" (I will try to fix them tomorrow.) > Well, that's all. I am looking forward for your comments. > I hope Matthias and George will find the changes useful. I find these new addition very very useful :) Good job! I think the pic16 port is getting closer to be really useable. best regards Matthias |
From: Vangelis R. <vr...@ot...> - 2004-06-05 23:26:54
|
On Sunday 06 June 2004 01:40, Matthias H=E4nel wrote: > That's cool. > I tried: > code char at __CONFIG3L _conf3 =3D _STVR_OFF_3L & _LVP_OFF_3L; > > It doesn't seem to produce the appropriate code right now. Hmm, normally _conf3 should be loaded with 0xff. What is the value you get? > This failed with a crash dump. I ll try to recompile the sdcc with my > visual studio. But currently I can't import the project files. Visual > Studio says "failed to load damaged project files" (I will try to fix > them tomorrow.) The problem is with CR/LF pairs. MSVC looks for CR/LF while the current .ds= p=20 files have only LF. I don't know why, they ought to have CR/LF since they=20 were initially produced by MSVC. ANW, for a solution you can load each .dsp file in the SDCC tree into wordp= ad=20 and then save it. It asks you a message about formatting, but you answer YE= S=20 and repeat. This worked for me... > I find these new addition very very useful :) Good job! > I think the pic16 port is getting closer to be really useable. Yes, but we have to make them compile in the first place!!! Vangelis |
From: jonathan d. <jdu...@ci...> - 2004-06-07 13:46:45
|
on wincvs i thing you have a checkbox to tell wincvs to insert the ln after cr.. Jonathan ----- Original Message ----- From: "Vangelis Rokas" <vr...@ot...> To: <sdc...@li...> Sent: Saturday, June 05, 2004 7:31 PM Subject: **SPAM** Re: [Sdcc-user] Re: PIC16 port changes On Sunday 06 June 2004 01:40, Matthias Hänel wrote: > That's cool. > I tried: > code char at __CONFIG3L _conf3 = _STVR_OFF_3L & _LVP_OFF_3L; > > It doesn't seem to produce the appropriate code right now. Hmm, normally _conf3 should be loaded with 0xff. What is the value you get? > This failed with a crash dump. I ll try to recompile the sdcc with my > visual studio. But currently I can't import the project files. Visual > Studio says "failed to load damaged project files" (I will try to fix > them tomorrow.) The problem is with CR/LF pairs. MSVC looks for CR/LF while the current .dsp files have only LF. I don't know why, they ought to have CR/LF since they were initially produced by MSVC. ANW, for a solution you can load each .dsp file in the SDCC tree into wordpad and then save it. It asks you a message about formatting, but you answer YES and repeat. This worked for me... > I find these new addition very very useful :) Good job! > I think the pic16 port is getting closer to be really useable. Yes, but we have to make them compile in the first place!!! Vangelis ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Sdcc-user mailing list Sdc...@li... https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Vangelis R. <vr...@ot...> - 2004-06-05 23:48:19
|
On Sunday 06 June 2004 01:40, Matthias H=E4nel wrote: > > #include <pic18fregs.h> // or i.e. <pic18f452.h> > > code char at __CONFIG0H _conf0 =3D _OSCS_ON_0H & _OSC_HS_0H; > > That's cool. > I tried: > code char at __CONFIG3L _conf3 =3D _STVR_OFF_3L & _LVP_OFF_3L; > > It doesn't seem to produce the appropriate code right now. Sorry, there is a bug in the sources, that leeds to only emitting the 0x300= 001=20 config register! Well, I'll fix it in the CVS, but for some strange reason,= =20 SF does not allow me to access the CVS server. A fix would be to replace the function pic16_assignConfigWordValue, its the= =20 last function in the src/pic16/device.c source, with the following code: =2D------------------------------------------------------------------------= =2D--------------- void pic16_assignConfigWordValue(int address, int value) { int i; for(i=3D0;i<pic16->cwInfo.confAddrEnd-pic16->cwInfo.confAddrStart+1;= i++){ if((address =3D=3D pic16->cwInfo.confAddrStart+i) && (pic16->cwInfo.crInfo[i].mask !=3D -1)) { pic16->cwInfo.crInfo[i].value =3D value; pic16->cwInfo.crInfo[i].emit =3D 1; return; } } } =2D------------------------------------------------------------------------= =2D-------------- Also _OSCS_ON_0H & _OSC_HS_0H doesn't produce 0xff like I wrote in my=20 previous message but to 0xfa. Vangelis |
From: Maarten B. <sou...@ds...> - 2004-06-06 13:25:29
|
> The problem is with CR/LF pairs. MSVC looks for CR/LF while the > current .dsp files have only LF. I don't know why, they ought to have > CR/LF since they were initially produced by MSVC. ANW, for a solution > you can load each .dsp file in the SDCC tree into wordpad and then > save it. It asks you a message about formatting, but you answer YES > and repeat. > > This worked for me... > > Vangelis Hello Vangelis, The only problem I found compiling on MSVC was a double semicolon. It's fixed in the cvs. I have used source snapshots and checkouts from cvs but do not find any LF-only problems in .dsp files. Maybe your win32 cvs client does some conversions? I use TortoiseCVS. |
From: Vangelis R. <vr...@ot...> - 2004-06-06 13:39:19
|
On Sunday 06 June 2004 16:25, Maarten Brock wrote: > The only problem I found compiling on MSVC was a double semicolon. > It's fixed in the cvs. I think I've noticed that also, but never give it anymore attention! Nevertheless I don't develop under windows, so I probably forget it! > I have used source snapshots and checkouts from cvs but do not find > any LF-only problems in .dsp files. Maybe your win32 cvs client does > some conversions? I use TortoiseCVS. I don't know, but cvs under linux gives me the same results, no CR/LF in .dsp files, so there must be a problem somewhere. I could fix it, but this is beyond the pic16 port, and I don't want to break other people work before warning... Vangelis |
From: Maarten B. <sou...@ds...> - 2004-06-06 14:17:01
|
> On Sunday 06 June 2004 16:25, Maarten Brock wrote: > > The only problem I found compiling on MSVC was a double semicolon. > > It's fixed in the cvs. > > I think I've noticed that also, but never give it anymore attention! > Nevertheless I don't develop under windows, so I probably forget it! > > > I have used source snapshots and checkouts from cvs but do not find > > any LF-only problems in .dsp files. Maybe your win32 cvs client does > > some conversions? I use TortoiseCVS. > > I don't know, but cvs under linux gives me the same results, no CR/LF > in .dsp files, so there must be a problem somewhere. I could fix it, > but this is beyond the pic16 port, and I don't want to break other > people work before warning... > > Vangelis Maybe you can set some option for your cvs client to use unix line endings or not. TortoiseCVS has this and I have it set at "don't" which means it doesn't convert I guess. Under linux you may be better off with such an option at "do", maybe not. |
From: George M. G. <gga...@co...> - 2004-06-17 01:41:58
|
The following code snip fails to build with the code base dated 20040615. Regards, George typedef unsigned char byte; int sub(byte *addr, byte bit_no) { int a; a = (*addr & bit_no) > 0; return(a); } sdcc -S -mpic16 -p18f8720 -I../include -I/usr/local/share/sdcc/inclued/pic16 --pomit-config-words bug.c Processor: 18f8720 ERROR: LinkFlow, couldn't find label. key=108,lab=_00108_DS_ ERROR: LinkFlow, couldn't find label. key=108,lab=_00108_DS_ b |
From: <mat...@ph...> - 2004-06-17 21:12:07
|
Hi George, Attachments: <none> Thursday, June 17, 2004, 3:41:51 AM, you wrote: =20 > The following code snip fails to build with the code base dated 2004061= 5. > typedef unsigned char byte; =20 > int sub(byte *addr, byte bit_no) > { > int > a; =20 > a =3D (*addr & bit_no) > 0; > return(a); > } I tested your code my latest sdcc (that works pretty good for me now). I could reduce your code to: int sub(int *addr) { return *addr; } and it's still failing. It seems the parser gets puzzled when dereferencing to a int. greetz Matthias H=E4nel |
From: George M. G. <gga...@co...> - 2004-06-17 23:37:56
|
Matthias, I tried your test case and it builds ok for me with 20040615. George Matthias Hänel wrote: >Hi George, > >Attachments: <none> >Thursday, June 17, 2004, 3:41:51 AM, you wrote: > > > > >>The following code snip fails to build with the code base dated 20040615. >> >> > > > >>typedef unsigned char byte; >> >> > > > >>int sub(byte *addr, byte bit_no) >>{ >> int >> a; >> >> > > > >> a = (*addr & bit_no) > 0; >> return(a); >>} >> >> > >I tested your code my latest sdcc (that works pretty good for me now). >I could reduce your code to: > >int sub(int *addr) >{ > return *addr; >} > >and it's still failing. It seems the parser gets puzzled when >dereferencing to a int. > > >greetz >Matthias Hänel > > > > >------------------------------------------------------- >This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference >Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer >Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA >REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND >_______________________________________________ >Sdcc-user mailing list >Sdc...@li... >https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > |
From: <mat...@ph...> - 2004-06-18 19:53:40
|
Hi George, Attachments: <none> Friday, June 18, 2004, 1:37:43 AM, you wrote: > I tried your test case and it builds ok for me with 20040615. That'S pretty weird since the source didn't change since 13th June 2004. Did you build your binaries yourself? Did you test it on linux or windows? I tested it with the prebuilt windows binaries. best regards Matthias |
From: George M. G. <gga...@co...> - 2004-06-18 22:42:44
|
Matthias, I use Linux and built from source. George Matthias Hänel wrote: >Hi George, > >Attachments: <none> >Friday, June 18, 2004, 1:37:43 AM, you wrote: > > > >>I tried your test case and it builds ok for me with 20040615. >> >> > >That'S pretty weird since the source didn't change since 13th June >2004. Did you build your binaries yourself? Did you test it on linux >or windows? I tested it with the prebuilt windows binaries. > >best regards >Matthias > > > > >------------------------------------------------------- >This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference >Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer >Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA >REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND >_______________________________________________ >Sdcc-user mailing list >Sdc...@li... >https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > |
From: Vangelis R. <vr...@ot...> - 2004-06-26 15:07:49
|
On Friday 18 June 2004 00:14, Matthias H=E4nel wrote: > Thursday, June 17, 2004, 3:41:51 AM, you wrote: > > The following code snip fails to build with the code base dated 2004061= 5. > > > > typedef unsigned char byte; > > > > int sub(byte *addr, byte bit_no) > > { > > int > > a; > > > > a =3D (*addr & bit_no) > 0; > > return(a); > > } > > I tested your code my latest sdcc (that works pretty good for me now). > I could reduce your code to: > > int sub(int *addr) > { > return *addr; > } > > and it's still failing. It seems the parser gets puzzled when > dereferencing to a int. The first listing fails because of a bug in a function inside the code=20 generator. The > comparison causes this bug to appear. I knew that there wa= s=20 a bug in there, but I couldn't reproduce it... The proper fix would be to rewrite genCmp which performs comparisons but it= s a=20 hard work to do. I hope I will have a partial fix in the next days. =46or the time being you can overcome the problem if you place the comparis= on=20 inside an if-statement, i.e. if((*addr & bit_no) > 0)a=3D1 else a=3D0; and EVERYBODY IS WARNED similar lines may well produce wrong code. Hopefull= y=20 the source will not compile, but sometimes it may... OTOH I can't see any bugs for the second listing. Can you still reproduce i= t?=20 Can you send me the c source and the .asm file? Regards, Vangelis |
From: George M. G. <gga...@co...> - 2004-06-26 16:46:27
|
The nightly source snapshots on sourceforge seem to have stopped on June 15th. George |