sdcc-devel — Development chatter about SDCC
You can subscribe to this list here.
| 2000 |
Jan
(1) |
Feb
(56) |
Mar
(65) |
Apr
(18) |
May
(40) |
Jun
(12) |
Jul
(18) |
Aug
(19) |
Sep
(164) |
Oct
(86) |
Nov
(67) |
Dec
(29) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(96) |
Feb
(176) |
Mar
(119) |
Apr
(59) |
May
(181) |
Jun
(193) |
Jul
(140) |
Aug
(180) |
Sep
(182) |
Oct
(322) |
Nov
(263) |
Dec
(187) |
| 2002 |
Jan
(130) |
Feb
(83) |
Mar
(106) |
Apr
(28) |
May
(39) |
Jun
(46) |
Jul
(78) |
Aug
(107) |
Sep
(66) |
Oct
(33) |
Nov
(58) |
Dec
(53) |
| 2003 |
Jan
(197) |
Feb
(261) |
Mar
(282) |
Apr
(242) |
May
(218) |
Jun
(107) |
Jul
(108) |
Aug
(78) |
Sep
(129) |
Oct
(181) |
Nov
(139) |
Dec
(108) |
| 2004 |
Jan
(224) |
Feb
(185) |
Mar
(115) |
Apr
(102) |
May
(98) |
Jun
(103) |
Jul
(124) |
Aug
(88) |
Sep
(124) |
Oct
(100) |
Nov
(74) |
Dec
(79) |
| 2005 |
Jan
(66) |
Feb
(83) |
Mar
(123) |
Apr
(53) |
May
(109) |
Jun
(46) |
Jul
(126) |
Aug
(78) |
Sep
(61) |
Oct
(43) |
Nov
(213) |
Dec
(93) |
| 2006 |
Jan
(63) |
Feb
(109) |
Mar
(79) |
Apr
(185) |
May
(283) |
Jun
(179) |
Jul
(147) |
Aug
(156) |
Sep
(114) |
Oct
(173) |
Nov
(137) |
Dec
(148) |
| 2007 |
Jan
(154) |
Feb
(108) |
Mar
(132) |
Apr
(151) |
May
(241) |
Jun
(94) |
Jul
(109) |
Aug
(50) |
Sep
(62) |
Oct
(128) |
Nov
(90) |
Dec
(74) |
| 2008 |
Jan
(53) |
Feb
(161) |
Mar
(261) |
Apr
(53) |
May
(87) |
Jun
(44) |
Jul
(73) |
Aug
(67) |
Sep
(54) |
Oct
(37) |
Nov
(72) |
Dec
(53) |
| 2009 |
Jan
(51) |
Feb
(73) |
Mar
(84) |
Apr
(67) |
May
(59) |
Jun
(31) |
Jul
(78) |
Aug
(45) |
Sep
(90) |
Oct
(56) |
Nov
(69) |
Dec
(51) |
| 2010 |
Jan
(188) |
Feb
(73) |
Mar
(20) |
Apr
(46) |
May
(91) |
Jun
(24) |
Jul
(115) |
Aug
(135) |
Sep
(132) |
Oct
(90) |
Nov
(92) |
Dec
(58) |
| 2011 |
Jan
(121) |
Feb
(90) |
Mar
(56) |
Apr
(79) |
May
(98) |
Jun
(109) |
Jul
(104) |
Aug
(113) |
Sep
(234) |
Oct
(143) |
Nov
(160) |
Dec
(93) |
| 2012 |
Jan
(162) |
Feb
(160) |
Mar
(219) |
Apr
(186) |
May
(135) |
Jun
(360) |
Jul
(138) |
Aug
(72) |
Sep
(130) |
Oct
(146) |
Nov
(64) |
Dec
(137) |
| 2013 |
Jan
(65) |
Feb
(18) |
Mar
(35) |
Apr
(26) |
May
(108) |
Jun
(34) |
Jul
(16) |
Aug
(11) |
Sep
(61) |
Oct
(4) |
Nov
(23) |
Dec
(24) |
| 2014 |
Jan
(56) |
Feb
(58) |
Mar
(54) |
Apr
(26) |
May
(3) |
Jun
(31) |
Jul
(13) |
Aug
(13) |
Sep
(7) |
Oct
(26) |
Nov
(65) |
Dec
(54) |
| 2015 |
Jan
(64) |
Feb
(15) |
Mar
(25) |
Apr
(41) |
May
(22) |
Jun
(62) |
Jul
(26) |
Aug
(17) |
Sep
(35) |
Oct
(33) |
Nov
(37) |
Dec
(17) |
| 2016 |
Jan
(39) |
Feb
(12) |
Mar
(15) |
Apr
(13) |
May
(41) |
Jun
(76) |
Jul
(53) |
Aug
(38) |
Sep
(31) |
Oct
(11) |
Nov
(9) |
Dec
(19) |
| 2017 |
Jan
(11) |
Feb
(19) |
Mar
|
Apr
(28) |
May
(61) |
Jun
(9) |
Jul
(9) |
Aug
(14) |
Sep
|
Oct
(63) |
Nov
(43) |
Dec
(21) |
| 2018 |
Jan
(24) |
Feb
(46) |
Mar
(38) |
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(2) |
2
(15) |
3
(3) |
|
4
(3) |
5
(3) |
6
(9) |
7
(8) |
8
(2) |
9
(4) |
10
(2) |
|
11
|
12
(2) |
13
(2) |
14
(1) |
15
(2) |
16
(2) |
17
(7) |
|
18
(4) |
19
(11) |
20
(7) |
21
(8) |
22
(2) |
23
(1) |
24
(2) |
|
25
(7) |
26
(2) |
27
|
28
(2) |
29
(4) |
30
(2) |
31
|
|
From: Johan Knol <johan.knol@id...> - 2001-03-02 19:53:56
|
> I'll take your advice and modify the Makefiles so that a make clean just works. Please don't. Let me handle this, since there are other abnomalties that I fixed already in my working copy. Let's say we call your port "-mpic" and that you add MODEL_PIC[12,14,16] to SDCCglobl.h, and the related switches in SDCCmain.c. Then I think you could rename all your *pic14* functions and variables to *pic*. You could make MODEL_PIC14 the default model in pic_setDaultOptions() and throw an error (e.g. "--model-pic16 isn't supported yet" or --model-small for that matter) in pic_finaliseOptions() as long as it is not supported. Regards, Johan |
|
From: Sandeep Dutta <sandeep@dd...> - 2001-03-02 19:39:20
|
Iam the culprit. I guess I was not very consistent. As for the z80 changes you wanted to make.... Michael sometimes leaves the group he will be back, the z80 port was never fully integrated into the source tree. I think the libraries had to be separately downloaded from the gameboy development kit site. I would say you can go ahead and make the changes in the header files. Let me know when you need CVS write access. You will need to register at sourceforge , and I will need your "unix" login name. Sandeep -----Original Message----- From: sdcc-devel-admin@... [mailto:sdcc-devel-admin@...]On Behalf Of Russel Winder Sent: Friday, March 02, 2001 10:34 AM To: SDCC Developer List Subject: [sdcc-devel]The error messages The error messages are handled in support/Utils/SDCCerr.[ch] by a combination of pre-processor symbols to give the index numbers into an array of structs giving severity and text string. The introducer on the pre-processor symbols (E_, W_) does not always match the severity specifier in the array of structs (ERROR, WARNING). The question is which is right? Also should there be an INFORMATION type to go with the I_ indexes? I found this whilst trying to work out who EVELYN the DOG was. Is there an answer? Russel. ==================================================================== Dr Russel Winder Chief Technology Officer OneEighty Software Ltd Tel: +44 20 8263 2329 The Lansdowne Building Fax: +44 20 8263 6314 2 Lansdowne Road R.Winder@... Croydon, Surrey CR9 2ER, UK http://www.180sw.com ==================================================================== Under the Regulation of Investigatory Powers (RIP) Act 2000 together with any and all Regulations in force pursuant to the Act One Eighty Software Ltd reserves the right to monitor any or all incoming or outgoing communications as provided for under the Act _______________________________________________ sdcc-devel mailing list sdcc-devel@... http://lists.sourceforge.net/lists/listinfo/sdcc-devel |
|
From: Stephen Williams <steve@ic...> - 2001-03-02 18:43:18
|
r.winder@... said: > I did a cvs diff and there wer no differences, still the problem > occurred. I've seen that happen, where "cvs diff" reports no differences yet "cvs update" reports that local files are modified. I don't know if the problem is with sourceforge or versions of CVS itself. -- Steve Williams "The woods are lovely, dark and deep. steve@... But I have promises to keep, steve@... and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." |
|
From: Russel Winder <r.winder@18...> - 2001-03-02 18:32:58
|
The error messages are handled in support/Utils/SDCCerr.[ch] by a combination of pre-processor symbols to give the index numbers into an array of structs giving severity and text string. The introducer on the pre-processor symbols (E_, W_) does not always match the severity specifier in the array of structs (ERROR, WARNING). The question is which is right? Also should there be an INFORMATION type to go with the I_ indexes? I found this whilst trying to work out who EVELYN the DOG was. Is there an answer? Russel. ==================================================================== Dr Russel Winder Chief Technology Officer OneEighty Software Ltd Tel: +44 20 8263 2329 The Lansdowne Building Fax: +44 20 8263 6314 2 Lansdowne Road R.Winder@... Croydon, Surrey CR9 2ER, UK http://www.180sw.com ==================================================================== Under the Regulation of Investigatory Powers (RIP) Act 2000 together with any and all Regulations in force pursuant to the Act One Eighty Software Ltd reserves the right to monitor any or all incoming or outgoing communications as provided for under the Act |
|
From: Scott Dattalo <scott@da...> - 2001-03-02 18:14:29
|
On Fri, 2 Mar 2001, Johan Knol wrote: > Ok, but please check your gen.c Your fReturnSize (=4) is static, so your > main.c and ralloc.c uses the fReturnSize from the ds390 port (=5). Could you > change yours to fReturnSizePIC? Then I can change ours to fReturnSizeDS390 I'll add the fReturnSizePIC. Furthermore, I'll check in my most recent changes this weekend. > > By the way, are you doing the pic or the pic14 port. Right now the pic dir > isn't cleaned with make clean because your port is called pic14. I would > suggest we call it the pic port and you can than throw an error if e.g. some > default --model-pic14 is overruled. I'm doing "both" ports. But let me clarify. The PIC family as you probably know, is comprised from three different cores. The instruction width for each is 12 bits, 14 bits, and 16 bits. The 12 and 14-bit cores are similar in many respects. The 16 bit core has two varieties, the 17cxx and the 18cxxx. The 17cxx is a dark horse in many regards. The 18cxxx is fairly logical extension of the 14-bit cores. Now my goal was to create THE pic port. Then within this to provide customizations for the three variations. However, as I became more entrenced in the details of development, I'm discovering that this is fairly lofty goal. So I've backed off and have just concentrated on the most popular PIC family: the 14bit core. I'll take your advice and modify the Makefiles so that a make clean just works. I should get both of these done with in 48 hours of the time tag of this message. Regards, Scott |
|
From: Russel Winder <r.winder@18...> - 2001-03-02 17:55:53
|
Johan, > > make[2]: *** [_atoi.rel] Segmentation fault (core dumped) > > make[2]: Leaving directory > > `/home/users/russel/OneEighty/CrossCompilers/SDCC/device/lib' > > make[1]: *** [modelDS390] Error 2 > > make[1]: Leaving directory > > `/home/users/russel/OneEighty/CrossCompilers/SDCC/device/lib' > > make: *** [sdcc-device] Error 2 > > After a fresh checkout everything works for me. Are you sure you have an > unmodified source tree? I had no modified files, the cvs update gave no differences. I did a cvs diff and there wer no differences, still the problem occurred. I took you suggestion and deleted everything and did effectively a new check out and ... it worked fine. I think I will chalk this one up to bizarreness and forget about it. Sorry to everyone for sending what turned out to be an irrelevant email. Russel. ==================================================================== Dr Russel Winder Chief Technology Officer OneEighty Software Ltd Tel: +44 20 8263 2329 The Lansdowne Building Fax: +44 20 8263 6314 2 Lansdowne Road R.Winder@... Croydon, Surrey CR9 2ER, UK http://www.180sw.com ==================================================================== Under the Regulation of Investigatory Powers (RIP) Act 2000 together with any and all Regulations in force pursuant to the Act One Eighty Software Ltd reserves the right to monitor any or all incoming or outgoing communications as provided for under the Act |
|
From: Johan Knol <johan.knol@id...> - 2001-03-02 16:02:05
|
> make[2]: *** [_atoi.rel] Segmentation fault (core dumped) > make[2]: Leaving directory > `/home/users/russel/OneEighty/CrossCompilers/SDCC/device/lib' > make[1]: *** [modelDS390] Error 2 > make[1]: Leaving directory > `/home/users/russel/OneEighty/CrossCompilers/SDCC/device/lib' > make: *** [sdcc-device] Error 2 After a fresh checkout everything works for me. Are you sure you have an unmodified source tree? Regards, Johan |
|
From: Sandeep Dutta <sandeep@dd...> - 2001-03-02 15:55:03
|
yes -----Original Message----- From: sdcc-devel-admin@... [mailto:sdcc-devel-admin@...]On Behalf Of Johan Knol Sent: Friday, March 02, 2001 7:48 AM To: sdcc-devel@... Subject: Re: [sdcc-devel]Fixed PCALL and stack adjustment bug ----- Original Message ----- From: Sandeep Dutta <sandeep@...> To: <sdcc-devel@...> Sent: Friday, March 02, 2001 4:18 PM Subject: RE: [sdcc-devel]Fixed PCALL and stack adjustment bug > No problems here. This will cleanup the code. > Sandeep I assume that refers to my "removing ds390 polutions from..." message? Johan _______________________________________________ sdcc-devel mailing list sdcc-devel@... http://lists.sourceforge.net/lists/listinfo/sdcc-devel |
|
From: Johan Knol <johan.knol@id...> - 2001-03-02 15:46:44
|
----- Original Message ----- From: Sandeep Dutta <sandeep@...> To: <sdcc-devel@...> Sent: Friday, March 02, 2001 4:18 PM Subject: RE: [sdcc-devel]Fixed PCALL and stack adjustment bug > No problems here. This will cleanup the code. > Sandeep I assume that refers to my "removing ds390 polutions from..." message? Johan |
|
From: Johan Knol <johan.knol@id...> - 2001-03-02 15:43:10
|
Ok, but please check your gen.c Your fReturnSize (=4) is static, so your main.c and ralloc.c uses the fReturnSize from the ds390 port (=5). Could you change yours to fReturnSizePIC? Then I can change ours to fReturnSizeDS390 By the way, are you doing the pic or the pic14 port. Right now the pic dir isn't cleaned with make clean because your port is called pic14. I would suggest we call it the pic port and you can than throw an error if e.g. some default --model-pic14 is overruled. Regards, Johan ----- Original Message ----- From: Scott Dattalo <scott@...> To: <sdcc-devel@...> Sent: Friday, March 02, 2001 4:13 PM Subject: Re: [sdcc-devel]removing ds390 polutions from mcs51 and pic port > > > On Fri, 2 Mar 2001, Johan Knol wrote: > > > I want to make the OPT_DISABLE_<target> work again. > > > > But there are still references to model-flat24 and stack-10bit in mcs51 and > > pic port. These are causing problems if e.g. the ds390 port is disabled. Is > > it possible for them to be removed? I can do that but only if agreed by > > resp. Sandeep and Scott. > > FYI, the pic port started off as: > > cd sdcc/src > mkdir pic > cp mcs51/* pic > > As a consequence, there are many 8051'isms in the PIC port. I've removed many in > gen.c and some in ralloc.c, but there are many still to remove. Both > model-flat24 and stack-10bit concepts are not applicable to the pic port. > > If you want to disable these in the pic port, then give me a heads up. I'd like > to check in my most recent changes before this is done (e.g. to prevent > potential merge conflicts). (Aside: The reasons I don't check my changes in > every day or so are 1) I don't want to break sdcc for the other ports, 2) I > don't want to be interrupted by the occasional breaks others introduced. The pic > port is still in MAJOR development mode. ) > > Regards, > Scott > > > _______________________________________________ > sdcc-devel mailing list > sdcc-devel@... > http://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
|
From: Russel Winder <r.winder@18...> - 2001-03-02 15:20:07
|
I just did a full make distclean, cvs update, configure and make and
after a while got (this is just the last few lines):
../../bin/sdcc -I../../device/include --model-large -c time.c
make[2]: Leaving directory
`/home/users/russel/OneEighty/CrossCompilers/SDCC/device/lib'
test -d ds390 || mkdir ds390
rm -f ds390/*.lib
make CFLAGS=" -mds390 --model-flat24 \
--stack-10bit" objects
make[2]: Entering directory
`/home/users/russel/OneEighty/CrossCompilers/SDCC/device/lib'
../../bin/sdcc -I../../device/include -mds390 --model-flat24
--stack-10bit -c _atoi.c
make[2]: *** [_atoi.rel] Segmentation fault (core dumped)
make[2]: Leaving directory
`/home/users/russel/OneEighty/CrossCompilers/SDCC/device/lib'
make[1]: *** [modelDS390] Error 2
make[1]: Leaving directory
`/home/users/russel/OneEighty/CrossCompilers/SDCC/device/lib'
make: *** [sdcc-device] Error 2
it never done this before.
Russel.
====================================================================
Dr Russel Winder Chief Technology Officer
OneEighty Software Ltd Tel: +44 20 8263 2329
The Lansdowne Building Fax: +44 20 8263 6314
2 Lansdowne Road R.Winder@...
Croydon, Surrey CR9 2ER, UK http://www.180sw.com
====================================================================
Under the Regulation of Investigatory Powers (RIP) Act 2000 together
with any and all Regulations in force pursuant to the Act One Eighty
Software Ltd reserves the right to monitor any or all incoming or
outgoing communications as provided for under the Act
|
|
From: Sandeep Dutta <sandeep@dd...> - 2001-03-02 15:17:52
|
No problems here. This will cleanup the code. Sandeep -----Original Message----- From: sdcc-devel-admin@... [mailto:sdcc-devel-admin@...]On Behalf Of Klaus Hennemann Sent: Friday, March 02, 2001 4:36 AM To: sdcc-devel@... Subject: Re: [sdcc-devel]Fixed PCALL and stack adjustment bug > This will effect the Z80 port > Sandeep I checked this. The compiler generates correct code with my last patch. Klaus _______________________________________________ sdcc-devel mailing list sdcc-devel@... http://lists.sourceforge.net/lists/listinfo/sdcc-devel |
|
From: Scott Dattalo <scott@da...> - 2001-03-02 15:04:23
|
On Fri, 2 Mar 2001, Johan Knol wrote: > I want to make the OPT_DISABLE_<target> work again. > > But there are still references to model-flat24 and stack-10bit in mcs51 and > pic port. These are causing problems if e.g. the ds390 port is disabled. Is > it possible for them to be removed? I can do that but only if agreed by > resp. Sandeep and Scott. FYI, the pic port started off as: cd sdcc/src mkdir pic cp mcs51/* pic As a consequence, there are many 8051'isms in the PIC port. I've removed many in gen.c and some in ralloc.c, but there are many still to remove. Both model-flat24 and stack-10bit concepts are not applicable to the pic port. If you want to disable these in the pic port, then give me a heads up. I'd like to check in my most recent changes before this is done (e.g. to prevent potential merge conflicts). (Aside: The reasons I don't check my changes in every day or so are 1) I don't want to break sdcc for the other ports, 2) I don't want to be interrupted by the occasional breaks others introduced. The pic port is still in MAJOR development mode. ) Regards, Scott |
|
From: Klaus Hennemann <klaus.hennemann@rt...> - 2001-03-02 12:35:13
|
> This will effect the Z80 port > Sandeep I checked this. The compiler generates correct code with my last patch. Klaus |
|
From: Johan Knol <johan.knol@id...> - 2001-03-02 10:57:37
|
I want to make the OPT_DISABLE_<target> work again. But there are still references to model-flat24 and stack-10bit in mcs51 and pic port. These are causing problems if e.g. the ds390 port is disabled. Is it possible for them to be removed? I can do that but only if agreed by resp. Sandeep and Scott. Regards, Johan |