Small Device C Compiler suite

I just started trying to use SDCC with a PIC16F84 and a 
PIC18F252 (I have been using SDCC for a few months on the 
89C51's).  I am using the June 8, 2003 nightly build for windows 
(mingw32).
I get the following error message:
Tempory ERROR: at the moment you have to use
an include file create by inc2h.pl.  See SDCC source:
support/scripts/inc2h.pl  
This is a nuisance bug that will be fixed shortly.

I downloaded the source code. inc2h.pl I think is a Pearl file which I 
can't (or don't know how to) use in windows.

Re: [Sdcc-user] PIC on Windows From: Scott Dattalo <scott@da...> - 2003-06-11 06:01 On Tue, 10 Jun 2003 brainerd@... wrote: > I just started trying to use SDCC with a PIC16F84 and a > PIC18F252 (I have been using SDCC for a few months on the > 89C51's). I am using the June 8, 2003 nightly build for windows > (mingw32). > I get the following error message: > Tempory ERROR: at the moment you have to use > an include file create by inc2h.pl. See SDCC source: > support/scripts/inc2h.pl > This is a nuisance bug that will be fixed shortly. > > I downloaded the source code. inc2h.pl I think is a Pearl file which I > can't (or don't know how to) use in windows. Yes, it is a Perl script. The script reads microchip .INC files and converts them to SDCC .h files. We plan on generating these all in one shot and making them available. However, there are some issues with the script that prevent this from happening (actually the issues are that the script parses .asm comments to extract register names and there are some errors in the .INC files). The last I heard, Craig Franklin was awaiting permission from Microchip to use yet another file that gives more explicit device info. Until then, take a look at: http://hawthorn.csse.monash.edu.au/~njh/electronics/pic-tricks/ or http://w3w.arafuraconnect.com.au/~tp/embedded.html Terry Porter (the latter link) has an 16f877.h file that you could use for the time being to test things out. Scott

Re: [Sdcc-user] PIC on Windows From: <brainerd@ca...> - 2003-07-04 07:12 The latest windows snapshot I see on the webpage is June 19. Have there been no updates since then or has the download url changed??

Re: [Sdcc-user] PIC on Windows From: Bernhard Held <bheld@mg...> - 2003-07-04 11:13 > The latest windows snapshot I see on the webpage is June 19. > Have there been no updates since then or has the download url > changed?? The snapshots have been built on Sourceforge's compile farm. Unfortunately the compile farm is unusable at the moment. The anonymous pserver-cvs access has become very unrelyable. Bernhard

[Sdcc-user] PIC14 Select - Case Bug From: <brainerd@ca...> - 2003-07-18 05:44 If I set up the Switch - Case statements as shown below, when ReceivePacketAddress = 'V' the case 'S' is executed rather than the 'V' case. If I move the case 'V' section in front of the case 'S' section the code functions as indended. I attached the relevent section of the .asm file generated by SDCC. Note that I run this under Windows 98 SE. //-----< Include Files >----- #include "p16f877.h" //-----< General Program Defines >----- #define FALSE 0 #define TRUE 1 char RX_Packet_Ready; // TRUE If a receive packet is ready unsigned char TransmitPacketIdentifier; unsigned char ReceivePacketAddress; unsigned char getc(void) { while (RCIF == 0); //wait until character available return(RCREG); } void putc(unsigned char c) { while (TXIF == 0); //wait until xmit register is clear TXREG = c; //load character into transmit register return; } //-----< Transmit a packet >------------------------------------------ void send_packet(void) { // Just send the packet out, one byte at a time putc(TransmitPacketIdentifier); } void rs232_isr(void) interrupt 0 { if(RCIF) { // serial received ReceivePacketAddress = getc(); RX_Packet_Ready = TRUE; // putc(ReceivePacketAddress); //echo back for diagnostic only // print_hex(ReceivePacketAddress); } } void test(void) { _asm nop _endasm; } void decode_rs232(void) { RX_Packet_Ready = FALSE; switch(ReceivePacketAddress) { case 'S': { TransmitPacketIdentifier = 'S'; break; } case 'V': { TransmitPacketIdentifier = 'V'; break; } case '?': { TransmitPacketIdentifier = 0xFF; // 255 (0xff) - Always 255 break; } } } //=====< Main >====================================================== void main(void) { NOT_RBPU=0; // Configure UART serial transmit SPBRG = 32; // 10MHz => 19200 baud BRGH = 1; // High Baud Rate mode SYNC = 0; //Asynchronous Mode SPEN = 1; RCIE = 1; CREN = 1; TXEN = 1;//enable RS232 xmit GIE = 1; //General Interrupt Enable PEIE = 1; ADCON1 = 7; //set all digital inputs //----- Initialize global variables RX_Packet_Ready = FALSE; //----- Main loop ----- test(); // puts("This is the start of the main loop"); while(1) { // Just sit here cooling our jets if( RX_Packet_Ready == TRUE) //decode_rs232(); { decode_rs232(); } } // End of main loop } //----- End of main ----- ; File Created by SDCC : FreeWare ANSI-C Compiler ; Version 2.3.5 Thu Jul 17 22:26:46 2003 ;#CSRC C:/sdcc/PIC/testswitch.c 63 ; switch(ReceivePacketAddress) MOVF _ReceivePacketAddress,W XORLW 0x3f BTFSC STATUS,2 GOTO _00132_DS_ MOVF _ReceivePacketAddress,W XORLW 0x53 BTFSC STATUS,2 GOTO _00130_DS_ MOVF _ReceivePacketAddress,W ;; peep 1 - test/jump to test/skip XORLW 0x56 BTFSS STATUS,2 GOTO _00134_DS_ _00130_DS_ MOVLW 0x53 MOVWF _TransmitPacketIdentifier ;#CSRC C:/sdcc/PIC/testswitch.c 69 ; break; GOTO _00134_DS_ ;#CSRC C:/sdcc/PIC/testswitch.c 73 ; TransmitPacketIdentifier = 'V'; MOVLW 0x56 MOVWF _TransmitPacketIdentifier ;#CSRC C:/sdcc/PIC/testswitch.c 74 ; break; GOTO _00134_DS_ _00132_DS_ ;#CSRC C:/sdcc/PIC/testswitch.c 78 ; TransmitPacketIdentifier = 0xFF; // 255 (0xff) - Always 255 MOVLW 0xff MOVWF _TransmitPacketIdentifier _00134_DS_ GOTO _00142_DS_ RETURN ; exit point of _main

[Sdcc-user] PIC14 Interrupt bug From: <brainerd@ca...> - 2003-07-18 05:55 I think this has been reported by someone else already. As you can see below. when I set up an RS-232 interrupt routine, the SDCC output is incorrect. There should be 3 nop after the goto in the STARTUP code(the interrupt vector is at 004h). At the start of the actual interrupt routine, SDCC inserts a goto end of interrupt + 1 and 3 nop's. These shouldn't be there. I have been removing these manually and adding the 3rd nop in the startup routine. The code then works properly. I am using the July 17 windows build. ; reset and interrupt vectors ;-------------------------------------------------------- STARTUP code goto __sdcc_gsinit_startup nop nop goto __sdcc_interrupt ;-------------------------------------------------------- ; initialization and interrupt code ;-------------------------------------------------------- code_init code 0x10 __sdcc_gsinit_startup: pagesel _main goto _main __sdcc_interrupt: ;*** ; pBlock Stats: dbName = I ;*** ;entry: _rs232_isr ;Function start ; 0 exit points ;functions called: ; _getc ; _getc ;; Starting pCode block _rs232_isr ;Function start ; 0 exit points ;#CSRC C:/sdcc/PIC/testswitch.c 39 ; void rs232_isr(void) interrupt 0 GOTO END_OF_INTERRUPT+1 NOP NOP NOP MOVWF WSAVE

[Sdcc-user] PIC14 Bank Select? From: <brainerd@ca...> - 2003-07-19 04:33 On the PIC16F877, there are 2 bank select bits (STATUS,5 and STATUS,6. When I set TRISA, it appears that the compiler only sets RB0. How do I know that RP1(STATUS,6) will be 0 (TRISA only appears in Bank 1 while TRISB is in both Bank 1 and Bank 3)? void set_tris_a(unsigned char value) { TRISA = value; } ;*** ; pBlock Stats: dbName = C ;*** ;entry: _set_tris_a ;Function start ; 2 exit points ;has an exit ;; Starting pCode block _set_tris_a ;Function start ; 2 exit points BSF STATUS,5 ;#CSRC c:/sdcc/pic/ccs_functions.c 84 ; void set_tris_a(unsigned char value) MOVWF _TRISA BCF STATUS,5 ;#CSRC c:/sdcc/pic/ccs_functions.c 86 ; TRISA = value; RETURN ; exit point of _set_tris_a

[Sdcc-user] Build sdcc under Linux, need help! From: Jung-Hee Park <jhee_park2002@ho...> - 2003-07-24 13:43 Hi all, For a while trying with SDCC binary package under Windoze. I couldnot configure the include path in to project although I have already add PATH variable. I turn into Nix world. I downloaded sdcc.src.tar.gz on the offical site which marked updating on Jul 24. My PC is installed Linux Redhat 7.3 kernel 2.4. The result of "./configure" was OK, I think so. Because there was no error or warning triggered up. Unfortunately, while I "make", there are bunch of warnings/errors. For example, in the midle of "make": "make -C `dirname mcs51/port.a` make[2]: Entering directory `/home/usr/sdcc/src/mcs51` ../port.mk:44: Makefile.dep: No such file or directory " Then, at the end of "make": "make[2]: *** [Makefile.dep] Error 1 make[2]: Leaving directory `/home/usr/sdcc/avr` make[1]: *** [avr/port.a] Error 2 make[1]: Leaving directory `/home/usr/sdcc/src` make: *** [sdcc-cc] Error 2 " If I still tried to "make install", there was no 'sdcc' in 'bin' and ...bin/sdcc: Command not found. Anybody has ecperience or bite trick when building under Nix? Thanks for all comments, helps, and suggestions. yours sincerely, J.H Park wrote from Republic of Korea.

Re: [Sdcc-user] Build sdcc under Linux, need help! From: Groepaz <groepaz@gm...> - 2003-07-24 13:48 On Thursday 24 July 2003 15:48, Jung-Hee Park wrote: [snip] 1) try "make depend" or "make dep" before "make all" 2) if that doesnt help, create empty files for the makefile.dep files its complaining about gpz

Re: [Sdcc-user] Build sdcc under Linux, need help! From: Bernhard Held <Bernhard@be...> - 2003-07-24 13:52 > Unfortunately, while I "make", there are bunch of warnings/errors. For > example, in the midle of "make": > "make -C `dirname mcs51/port.a` > make[2]: Entering directory `/home/usr/sdcc/src/mcs51` > ../port.mk:44: Makefile.dep: No such file or directory This is the only warning, which can be ignored. > Then, at the end of "make": > "make[2]: *** [Makefile.dep] Error 1 > make[2]: Leaving directory `/home/usr/sdcc/avr` > make[1]: *** [avr/port.a] Error 2 > make[1]: Leaving directory `/home/usr/sdcc/src` > make: *** [sdcc-cc] Error 2 The end is rather irrelevant. The important point is, where the trouble starts. Run 'make clean', and post the complete output of 'make -s'. Bernhard

Re: [Sdcc-user] Build sdcc under Linux, need help! From: Jung-Hee Park <jhee_park2002@ho...> - 2003-07-24 17:23 > 1) > > try "make depend" or "make dep" before "make all" > Thx, I can partially overcome now. I have been able to run SDCC @: /home/jhp/sdcc/bin/sdcc -v SDCC: mcs51/gbz80/z80/avr/ds390/pic14/pic16/.../ 2.3.5 (Jul 24 2003) (Unix). However, I still could not use include files by adding #include. /home/jhp/sdcc/bin/sdcc --print-search-dirs program: /home/jhp/sdcc/bin datadir: /home/jhp/sdcc/bin/../share /usr/local/share includedir: /home/jhp/sdcc/bin/../share/sdcc/include /usr/local/share/sdcc/include libdir: /home/jhp/sdcc/bin/../share/sdcc/lib /usr/local/share/sdcc/lib [1]. Do I compulsively have to install SDCC inside /usr/local (right now, I am using /home/jhp/sdcc/ where /home and /usr are the same level). [2]. If [1] is correct. Do I have to: - copy all files & folder of sdcc which are received after taring sdcc.src.tar.gz to /usr/local. Then ./configure, make and make install right in /usr/local? OR - After./configure, make in my own dir (called /home/jhp/sdcc/), then copy all to /usr/local? [3]. How can I confige or add to system bash file the path of SDCC. I would like to use sdcc -c *.c rather than the long one (/home/jhp/sdcc/bin/sdcc -c *c). Thanks so much for any helps, suggestions and comments. yours sincerely, J.H Park wrote from Republic of Korea. PS: I am sorry, I do not get use with the *Nix world.

Re: [Sdcc-user] Build sdcc under Linux, need help! From: Groepaz <groepaz@gm...> - 2003-07-24 18:19 On Thursday 24 July 2003 19:27, Jung-Hee Park wrote: > [1]. > Do I compulsively have to install SDCC inside /usr/local (right now, I am > using /home/jhp/sdcc/ where /home and /usr are the same level). there should be an option for configure to tell it where the installed version lives.... usually something like --prefix=/my/dir/ i dont use that myself however, i am used to supplying all it needs on the commandline. (include and library pathes etc) > [2]. > If [1] is correct. Do I have to: > - copy all files & folder of sdcc which are received after taring > sdcc.src.tar.gz to /usr/local. Then ./configure, make and make install > right in /usr/local? OR > - After./configure, make in my own dir (called /home/jhp/sdcc/), then copy > all to /usr/local? after "make all" try "make install" or just "install" .... depends on the config script.... again, i've personally never used this, i just compile the stuff at the place i want it to be (NOT in /usr/local for that matter) oh, and remember that you'll have to be root when copying stuff to /usr/local (ie, also when doing "make install" or sth) > > [3]. > How can I confige or add to system bash file the path of SDCC. I would like > to use sdcc -c *.c rather than the long one (/home/jhp/sdcc/bin/sdcc -c > *c). depends on your system.... there should be a file like "bashrc" or "bashrc.local" or sth like that with your default environment config in it..... look for such a file and add export PATH=$PATH:/my/dir there (this is bash syntax, it may look different if you are using another shell) gpz

RE: [Sdcc-user] Build sdcc under Linux, need help! From: Josh Stone <josh@4s...> - 2003-07-24 19:46 > -----Original Message----- > From: sdcc-user-admin@... > [mailto:sdcc-user-admin@... Behalf Of Groepaz > Sent: Thursday, July 24, 2003 12:17 PM > To: sdcc-user@... > Subject: Re: [Sdcc-user] Build sdcc under Linux, need help! >=20 >=20 > On Thursday 24 July 2003 19:27, Jung-Hee Park wrote: > > [1]. > > Do I compulsively have to install SDCC inside /usr/local (right=20 > now, I am > > using /home/jhp/sdcc/ where /home and /usr are the same level). >=20 > there should be an option for configure to tell it where the=20 > installed version=20 > lives.... usually something like --prefix=3D/my/dir/ >=20 > i dont use that myself however, i am used to supplying all it=20 > needs on the=20 > commandline. (include and library pathes etc) Just to clarify this - you need to specify the directories when you are = building sdcc. So start fresh again with "make clean". Now build sdcc = with: make prefix=3D/home/jhp/sdcc/ datadir=3D/home/jhp/sdcc/ Then you need to install sdcc with a similar command: make install prefix=3D/home/jhp/sdcc/ datadir=3D/home/jhp/sdcc/ As for adding it to the path, open up your ".bash_profile" file. Look = for the line with PATH=3D/path1:/path2 and tack yours on to the end, so: PATH=3D/path1:/path2:/home/jhp/sdcc/bin If you don't have a PATH line, then make your own with these two lines: PATH=3D$PATH:/home/jhp/sdcc/bin export PATH Hope this helps... Josh Stone

[Sdcc-user] pic14 lookup table BUG From: <brainerd@ca...> - 2003-08-08 19:54 Attachments: Message as HTML      The pic14 port produces incorrect code for a lookup table when the lookup table is not in page 1 and the index is a variable. The attached file, test.c , reproduces the error. The portion of the assembled file for main is shown below. The compiler clears r0x69, then checks if the table crosses a boundry. But, it fails to add the upper address bits of the table start address before setting PCLATH. When I insert ADDLW HIGH(_scan_to_ascii) just before the MOVWF PCLATH, the code works correctly. I am using the AUG 4 2003 [MINGW32] build. I used the following command line: C:\sdcc\bin\sdcc.exe -S -mpic14 -p16f877 c:\sdcc\PIC\test.c _main ;Function start ; 2 exit points ;#CSRC C:/sdcc/PIC/test.c 277 ; a = scan_to_ascii[x]; MOVF _PORTA,W ADDLW LOW(_scan_to_ascii+0) MOVWF r0x68 CLRF r0x69 RLF r0x69,F CALL _00107_DS_ GOTO _00108_DS_ _00107_DS_ MOVF r0x69,W MOVWF PCLATH MOVF r0x68,W MOVWF PCL _00108_DS_ MOVWF _PORTB ;#CSRC C:/sdcc/PIC/test.c 278 ; PORTB = a; RETURN ; exit point of _main Dave Brainerd

[Sdcc-user] TRIS Bug in PIC14 port From: <brainerd@ca...> - 2003-08-09 08:11 If I use TRISB = 0xFD the compiler will generate the bank switch command. But, if I use the program below (which OR's TRISB with 0xFD), NO bank switch command is generated. #include "p16f877.h" void main() { TRISB = TRISB | 0x01 ; } _main ;Function start ; 2 exit points ;#CSRC C:/sdcc/PIC/test2.c 4 ; TRISB = TRISB | 0x01 ; BSF _TRISB,0 RETURN ; exit point of _main end This was generated using the AUG 4 2003 [MINGW32} build. Command line was: C:\sdcc\bin\sdcc.exe -S -mpic14 -p16f877 test2.c Dave Brainerd

[Sdcc-user] PIC16 Compile Error From: <brainerd@ca...> - 2003-08-13 06:19 Attachments: Message as HTML      18f252led.zip      In response to this command, I get the version statement following. C:\sdcc\bin\sdcc.exe -v SDCC : mcs51/gbz80/z80/avr/ds390/pic14/pic16/TININative/xa51/ds400 2.3.5 (Aug 11 2003) (MINGW32) Using this command line, I get the following response(18f252.led.c is listed below). I have attached the 18f252led.d file produced. No .asm file is produced. C:\sdcc\bin\sdcc.exe -mpic16 -p18f252 c:\sdcc\pic18\18f252led.c Processor: 18f252 Comparing operands r0x53 to r0x53 Caught signal 11: SIGSEGV This is file 18f252led.c #define __18f252 #include "p18f252.h" #define HIGH 1 #define LOW 0 BIT_AT (PORTB_ADDR,0) led; unsigned char i; void delay (unsigned char x); void main (void) { TRISB = 0; do { led = HIGH; delay (2); led = LOW; delay (2); } while (i); } /* delay routine*/ void delay (unsigned char x) { while (x > 0 ) --x; return; }

[Sdcc-user] pic14 breakage From: Steve Tell <tell@te...> - 2003-09-10 18:24 Is it just me, or has the pic14 port broken badly in recent snapshots? I confess that before compiling yesterday's shapshot, the last one I built was from early april 2003, but with the sept 9 2003 snapshot I find: - the regression tests in src/regression cause gpsim to core dump on every single .cod file - this code fragment used to (in april) produce good code: volatile unsigned char cbctrl; volatile unsigned char cbdata; #define cbctrl_wrH 4 void cbwr(unsigned char byte) { cbdata = byte; cbctrl |= 1<<cbctrl_wrH; cbctrl &= ~(1<<cbctrl_wrH); } ; partial old sdcc output: _cbwr ;Function start MOVWF _cbdata BSF _cbctrl,4 BCF _cbctrl,4 RETURN end But with the 9sept2003 sdcc.src.tar.gz, the same input produces this mess: _cbwr ;Function start ; 2 exit points ;#CSRC memsub.c 18 ; void cbwr(unsigned char byte) MOVWF _cbdata ;#CSRC memsub.c 21 ; cbctrl |= 1<<cbctrl_wrH; MOVF _cbctrl,W MOVWF r0x20 CLRF r0x20 CLRF r0x20 CLRF r0x20 BSF r0x68,4 ;; peep 9c - Removed redundant move MOVF r0x20,W MOVWF _cbctrl MOVWF r0x20 CLRF r0x20 CLRF r0x20 CLRF r0x20 BCF r0x68,4 MOVF r0x20,W MOVWF _cbctrl RETURN All were built on sparc-sun-solaris2.8, using gcc 3.2.2. A complete example and both outputs are attached for the curious. Has any one seen similar problems or have any suggestions of where to look in the code? Steve

Re: [Sdcc-user] pic14 breakage From: Steve Tell <tell@te...> - 2003-09-10 23:28 Earlier today, I wrote: > > Is it just me, or has the pic14 port broken badly in recent snapshots? > I confess that before compiling yesterday's shapshot, the last one I built > was from early april 2003, but with the sept 9 2003 snapshot I find: > > - the regression tests in src/regression cause gpsim to core dump on every > single .cod file > > - this code fragment used to (in april) produce good code: > > volatile unsigned char cbctrl; > volatile unsigned char cbdata; > #define cbctrl_wrH 4 > void cbwr(unsigned char byte) > { > cbdata = byte; > cbctrl |= 1<<cbctrl_wrH; > cbctrl &= ~(1<<cbctrl_wrH); > } I discovered that "sdcc -mcs51" also produces wretched code code for this fragment, while the old (april) one did not. I'm fairly certain that this is due to changes in the target-independent portion, since the iCode (as viewed in the --dumpall output files) is quite different, and longer in yesterday's snapshot. The iCode from yesterday's sdcc seems to promote everything to unsigned-long-int while doing the |= and &= operations in the example. Found it - the difference is due to this change (paraphrased from cvs): Revision 1.71 Wed Aug 13 20:10:57 2003 UTC (4 weeks ago) by bernhardheld * src/SDCCval.c (cheapestVal): removed, it doesn't accord with ANSI (can be re-activated by defining REDUCE_LITERALS) adding a #REDUCE_LITERALS to SDCCval.c gives me output more like what I was expecting (and that works). ANSIfication is a nice goal, but in order to get useful output, I guess I'll have to use this hack until further optimization code is added to properly find the cases where such reduction is actually legal. Steve

Re: [Sdcc-user] pic14 breakage From: Scott Dattalo <scott@da...> - 2003-09-11 13:57 On Wed, 10 Sep 2003, Steve Tell wrote: > > Is it just me, or has the pic14 port broken badly in recent snapshots? > I confess that before compiling yesterday's shapshot, the last one I built > was from early april 2003, but with the sept 9 2003 snapshot I find: > > - the regression tests in src/regression cause gpsim to core dump on every > single .cod file Have you upgraded your gputils? SDCC now generates relocatable code for gpasm and hence requires gpasm to support it. Theoretically, the output of the link and located code should be backwards compatible with old versions of gpsim. Scott

Re: [Sdcc-user] pic14 breakage From: Bernhard Held <bernhard@be...> - 2003-09-11 15:20 > The iCode from yesterday's sdcc seems to promote everything to > unsigned-long-int while doing the |= and &= operations in the example. Thanks for the hint, I'll have a look. My work is far from being complete, and I was already supprised, that nobody complained so far :-) Bernhard

Re: [Sdcc-user] pic14 breakage From: Steve Tell <tell@te...> - 2003-09-11 18:57 On Thu, 11 Sep 2003, Scott Dattalo wrote: > On Wed, 10 Sep 2003, Steve Tell wrote: > > > > > Is it just me, or has the pic14 port broken badly in recent snapshots? > > I confess that before compiling yesterday's shapshot, the last one I built > > was from early april 2003, but with the sept 9 2003 snapshot I find: > > > > - the regression tests in src/regression cause gpsim to core dump on every > > single .cod file > > Have you upgraded your gputils? SDCC now generates relocatable code for > gpasm and hence requires gpasm to support it. Theoretically, the output of > the link and located code should be backwards compatible with old versions > of gpsim. Yes I've got the latest released gputils. gplink -v yields "gplink-0.11.6 pre-alpha". similar for gpasm. (relocatable sdcc output won't even compile with older 0.10.x gputils) a typical gpsim gdb session and traceback is: (gdb) set args --cli -c b.stc test.log (gdb) r Starting program: /usr/local/bin/gpsim --cli -c b.stc test.log gpsim - the GNUPIC simulator version: 0.20.14 type help for help not using guigpsim> Program received signal SIGSEGV, Segmentation fault. 0xfeb32d00 in strcmp () from /usr/lib/libc.so.1 (gdb) bt #0 0xfeb32d00 in strcmp () from /usr/lib/libc.so.1 #1 0xff24aae0 in search_commands (s=@0xffbedb90) at command.cc:118 #2 0xff23ecc0 in handle_identifier (s=@0xffbedb90, op=0xff27359c) at scan.ll:275 #3 0xff23db44 in yylex () at scan.ll:195 #4 0xff23b5b0 in yyparse () at /usr/lib/bison.simple:432 #5 0xff24ad84 in parse_string (cmd_string=0xffbee4d8 "load c b.stc") at input.cc:197 #6 0x0001dd54 in main (argc=5, argv=0xffbee64c) at main.cc:246 I haven't looked further into gpsim because I can't seem to recompile it since upgrading to gcc-3.2.2. Actually, I don't know for sure that the sdcc regressions ever worked with gpsim on solaris; I used to run them at home on linux-intel and haven't tried that yet this time around. anyway, thanks for looking at this... Steve

Re: [Sdcc-user] pic14 breakage From: Scott Dattalo <scott@da...> - 2003-09-13 13:54 On Thu, 11 Sep 2003, Steve Tell wrote: > > a typical gpsim gdb session and traceback is: > > (gdb) set args --cli -c b.stc test.log > (gdb) r > Starting program: /usr/local/bin/gpsim --cli -c b.stc test.log > > gpsim - the GNUPIC simulator > version: 0.20.14 > > type help for help > not using guigpsim> > Program received signal SIGSEGV, Segmentation fault. > 0xfeb32d00 in strcmp () from /usr/lib/libc.so.1 > (gdb) bt > #0 0xfeb32d00 in strcmp () from /usr/lib/libc.so.1 > #1 0xff24aae0 in search_commands (s=@0xffbedb90) at command.cc:118 > #2 0xff23ecc0 in handle_identifier (s=@0xffbedb90, op=0xff27359c) at scan.ll:275 > #3 0xff23db44 in yylex () at scan.ll:195 > #4 0xff23b5b0 in yyparse () at /usr/lib/bison.simple:432 > #5 0xff24ad84 in parse_string (cmd_string=0xffbee4d8 "load c b.stc") at input.cc:197 > #6 0x0001dd54 in main (argc=5, argv=0xffbee64c) at main.cc:246 > > > I haven't looked further into gpsim because I can't seem to recompile it > since upgrading to gcc-3.2.2. Actually, I don't know for sure that the > sdcc regressions ever worked with gpsim on solaris; I used to run them at > home on linux-intel and haven't tried that yet this time around. Hi Steve, If it's not too painful, I strongly suggest working with the CVS version of gpsim. There have been numerous bug fixes since the last release - including fixing the C++ issues for which gcc 3.x+ is much more strict. BTW, I'm "actively" working on a new gpsim release. I have plans for release in negative 1 weeks. :) But seriously, there are some remaining bugs that need to be ironed out for a new release. (Although, at the rate I'm going I probably should just do an interim release...) Regards, Scott

Re: [Sdcc-user] pic14 breakage From: Bernhard Held <bernhard@be...> - 2003-09-13 22:00 > > The iCode from yesterday's sdcc seems to promote everything to > > unsigned-long-int while doing the |= and &= operations in the example. > > Thanks for the hint, I'll have a look. My work is far from being complete, > and I was already supprised, that nobody complained so far :-) Fixed in SDCCval.c 1.73. Most of the val*() functions need a review, and I've finished only valMult(), valDiv() and valMod(). This time I've fixed valShift(). More to come, Bernhard

Re: [Sdcc-user] pic14 breakage From: Steve Tell <tell@te...> - 2003-09-14 18:13 On Sat, 13 Sep 2003, Bernhard Held wrote: > > > The iCode from yesterday's sdcc seems to promote everything to > > > unsigned-long-int while doing the |= and &= operations in the example. > > > > Thanks for the hint, I'll have a look. My work is far from being complete, > > and I was already supprised, that nobody complained so far :-) > Fixed in SDCCval.c 1.73. Most of the val*() functions need a review, and I've > finished only valMult(), valDiv() and valMod(). This time I've fixed > valShift(). Thanks, I'll take a look. One thing that occured to me: The interim versions showed noticable increases in code size and register usage. Would it have been helpful to have a report-generator script that sumarized those stats for each of the regression tests? That way you (or anyone else) could quickly see what effects a proposed change would have. I see if I can whip up somthing like this. Steve > More to come, > Bernhard > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Sdcc-user mailing list > Sdcc-user@... > https://lists.sourceforge.net/lists/listinfo/sdcc-user >

Re: [Sdcc-user] pic14 breakage From: Bernhard Held <bernhard@be...> - 2003-09-15 07:10 > One thing that occured to me: > The interim versions showed noticable increases in code size and register > usage. Would it have been helpful to have a report-generator script > that sumarized those stats for each of the regression tests? > That way you (or anyone else) could quickly see what effects a proposed > change would have. Well, the idea is not new. Generally there's no lack of ideas how to improve SDCC, but of time and people, who would implement these ideas. > I see if I can whip up somthing like this. I'll happily add a script to the nightly build. Bernhard

3 messages have been excluded from this view by a project administrator.