You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
(27) |
Apr
(107) |
May
(32) |
Jun
(45) |
Jul
(79) |
Aug
(61) |
Sep
(94) |
Oct
(89) |
Nov
(133) |
Dec
(45) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(81) |
Feb
(57) |
Mar
(85) |
Apr
(80) |
May
(79) |
Jun
(85) |
Jul
(97) |
Aug
(104) |
Sep
(60) |
Oct
(82) |
Nov
(49) |
Dec
(57) |
2002 |
Jan
(46) |
Feb
(80) |
Mar
(112) |
Apr
(93) |
May
(72) |
Jun
(89) |
Jul
(118) |
Aug
(130) |
Sep
(67) |
Oct
(49) |
Nov
(58) |
Dec
(99) |
2003 |
Jan
(281) |
Feb
(141) |
Mar
(231) |
Apr
(109) |
May
(128) |
Jun
(166) |
Jul
(243) |
Aug
(64) |
Sep
(44) |
Oct
(67) |
Nov
(70) |
Dec
(68) |
2004 |
Jan
(71) |
Feb
(88) |
Mar
(60) |
Apr
(84) |
May
(79) |
Jun
(168) |
Jul
(92) |
Aug
(72) |
Sep
(51) |
Oct
(102) |
Nov
(35) |
Dec
(73) |
2005 |
Jan
(65) |
Feb
(48) |
Mar
(86) |
Apr
(64) |
May
(107) |
Jun
(93) |
Jul
(40) |
Aug
(117) |
Sep
(82) |
Oct
(65) |
Nov
(63) |
Dec
(85) |
2006 |
Jan
(36) |
Feb
(81) |
Mar
(74) |
Apr
(131) |
May
(92) |
Jun
(71) |
Jul
(71) |
Aug
(54) |
Sep
(26) |
Oct
(77) |
Nov
(55) |
Dec
(55) |
2007 |
Jan
(112) |
Feb
(88) |
Mar
(105) |
Apr
(46) |
May
(28) |
Jun
(53) |
Jul
(29) |
Aug
(34) |
Sep
(74) |
Oct
(83) |
Nov
(67) |
Dec
(39) |
2008 |
Jan
(40) |
Feb
(105) |
Mar
(42) |
Apr
(25) |
May
(91) |
Jun
(32) |
Jul
(47) |
Aug
(128) |
Sep
(188) |
Oct
(54) |
Nov
(19) |
Dec
(41) |
2009 |
Jan
(145) |
Feb
(88) |
Mar
(117) |
Apr
(38) |
May
(53) |
Jun
(9) |
Jul
(47) |
Aug
(10) |
Sep
(28) |
Oct
(65) |
Nov
(97) |
Dec
(36) |
2010 |
Jan
(55) |
Feb
(87) |
Mar
(81) |
Apr
(30) |
May
(37) |
Jun
(15) |
Jul
(85) |
Aug
(31) |
Sep
(1) |
Oct
(69) |
Nov
(69) |
Dec
(32) |
2011 |
Jan
(37) |
Feb
(49) |
Mar
(55) |
Apr
(27) |
May
(67) |
Jun
(30) |
Jul
(43) |
Aug
(73) |
Sep
(65) |
Oct
(89) |
Nov
(59) |
Dec
(15) |
2012 |
Jan
(27) |
Feb
(48) |
Mar
(14) |
Apr
(18) |
May
(38) |
Jun
(59) |
Jul
(46) |
Aug
(11) |
Sep
(21) |
Oct
(28) |
Nov
(18) |
Dec
(51) |
2013 |
Jan
(35) |
Feb
(68) |
Mar
(56) |
Apr
(21) |
May
(62) |
Jun
(43) |
Jul
(12) |
Aug
(34) |
Sep
(28) |
Oct
|
Nov
(11) |
Dec
(33) |
2014 |
Jan
(15) |
Feb
(36) |
Mar
(33) |
Apr
(45) |
May
(8) |
Jun
(52) |
Jul
(30) |
Aug
(7) |
Sep
(38) |
Oct
(76) |
Nov
(19) |
Dec
(26) |
2015 |
Jan
(67) |
Feb
(42) |
Mar
(6) |
Apr
(12) |
May
(13) |
Jun
(17) |
Jul
(10) |
Aug
(9) |
Sep
(26) |
Oct
(24) |
Nov
(8) |
Dec
(2) |
2016 |
Jan
(19) |
Feb
(2) |
Mar
(33) |
Apr
(56) |
May
(10) |
Jun
(12) |
Jul
(38) |
Aug
(69) |
Sep
(10) |
Oct
(7) |
Nov
(20) |
Dec
(26) |
2017 |
Jan
(10) |
Feb
(10) |
Mar
(4) |
Apr
(4) |
May
(16) |
Jun
(13) |
Jul
(16) |
Aug
(25) |
Sep
|
Oct
(28) |
Nov
|
Dec
(1) |
2018 |
Jan
(31) |
Feb
(24) |
Mar
(38) |
Apr
(18) |
May
(13) |
Jun
|
Jul
(7) |
Aug
(4) |
Sep
(17) |
Oct
(15) |
Nov
(5) |
Dec
(2) |
2019 |
Jan
(3) |
Feb
(2) |
Mar
(8) |
Apr
(10) |
May
(3) |
Jun
(2) |
Jul
(17) |
Aug
(5) |
Sep
(1) |
Oct
(16) |
Nov
(6) |
Dec
(7) |
2020 |
Jan
(12) |
Feb
(4) |
Mar
(25) |
Apr
(26) |
May
(34) |
Jun
(59) |
Jul
(37) |
Aug
|
Sep
(2) |
Oct
(8) |
Nov
(38) |
Dec
(31) |
2021 |
Jan
(3) |
Feb
(21) |
Mar
(9) |
Apr
|
May
(15) |
Jun
(10) |
Jul
(22) |
Aug
(10) |
Sep
(7) |
Oct
(12) |
Nov
(13) |
Dec
(5) |
2022 |
Jan
(1) |
Feb
(18) |
Mar
(10) |
Apr
(27) |
May
(1) |
Jun
(14) |
Jul
(44) |
Aug
(29) |
Sep
(17) |
Oct
(10) |
Nov
(1) |
Dec
(7) |
2023 |
Jan
|
Feb
|
Mar
(7) |
Apr
(12) |
May
|
Jun
(1) |
Jul
(5) |
Aug
(4) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
(4) |
2024 |
Jan
(18) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Daniel F. <dan...@gm...> - 2022-08-23 23:22:08
|
On Mon, Aug 22, 2022 at 3:56 PM Philipp Klaus Krause <pk...@sp...> wrote: > Am 22.08.22 um 06:55 schrieb Daniel Franzini: > > > * I ran the tests and I'm not sure if all the errors I got are actually > > specific for the pic ports. For example, this one (I got a lot of this > one): > > > > cases/../../../../sdcc/support/regression/cases/../tests/bug-2805.c:9: > > error 206: invalid combination of short / long > > > > You get those because the pic ports are the only ports that still don't > support long long (they also don't support _BitInt yet, I guess > implementing support could be done for both at the same time, as there > likely is a lot of overlap in codegen for them). > I think I found the answer to the "where do I start" question. Cleaning this will remove a lot of clutter from the tests. Seem to be a good way to start. > > > * maybe some guidance from more experienced people might help me > > separating pic-specific bugs from generic compiler bugs (if I'm able to, > > I will fix as much stuff as I can); > > Since regression tests for other ports, e.g. "make test-stm8" pass, you > are very unlikely to encounter generic compiler bugs (the few test cases > for those are most likely disabled via #if 0 with a comment stating the > relevant bug ticket number on sourceforge. > > I'm struggling to get "make test-stm8" working. I build a version with both stm8 and ucsim enabled and I can run "make test-stm8" but it seems to be in an infinite loop without stopping. What is the expected time the full test suite takes to run? I want to run this because maybe stm8 is some sort of reference I can follow to see how things are done. > Philipp > > > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > -- Daniel "Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." (Donald Knuth) "Yes, technogeeks can be funny, even if only to each other." ( http://www.boogieonline.com/revolution/science/humor/)" "Man is driven to create; I know I really love to create things. And while I'm not good at painting, drawing, or music, I can write software." (Yukihiro Matsumoto, a.k.a. ``Matz'') |
From: Philipp K. K. <pk...@sp...> - 2022-08-22 18:56:05
|
Am 22.08.22 um 06:55 schrieb Daniel Franzini: > * I ran the tests and I'm not sure if all the errors I got are actually > specific for the pic ports. For example, this one (I got a lot of this one): > > cases/../../../../sdcc/support/regression/cases/../tests/bug-2805.c:9: > error 206: invalid combination of short / long > You get those because the pic ports are the only ports that still don't support long long (they also don't support _BitInt yet, I guess implementing support could be done for both at the same time, as there likely is a lot of overlap in codegen for them). > * maybe some guidance from more experienced people might help me > separating pic-specific bugs from generic compiler bugs (if I'm able to, > I will fix as much stuff as I can); Since regression tests for other ports, e.g. "make test-stm8" pass, you are very unlikely to encounter generic compiler bugs (the few test cases for those are most likely disabled via #if 0 with a comment stating the relevant bug ticket number on sourceforge. Philipp |
From: Felix S. <fe...@sa...> - 2022-08-22 08:03:21
|
On Mon, Aug 22, 2022 at 01:55:15AM -0300, Daniel Franzini wrote: > * I need help in order to add one more option to the configure script: the > ability to set the gputils path at configure time and use it as the default > (of course, the command line option will always have the priority but it is > difficult e.g. to run the test suite using a newer build of gputils > installed in a custom path. The configure script simply detects and uses > the gputils but I don't have a chance to point it to one build of mine > (newer, more supported chips). Can anyone help? Hi Daniel. A good and non-intrusive way is to use the PATH environment variable. In bash, you would do $ export PATH=/path/to/my/own/gputils/bin:$PATH. Generally, when calling programs from make, you should be able to override/interfere as in $ make CC=/my/other/compiler/bin/cc. This is broken in a few places, for some tools, perhaps including gputils. Please fix it, if you need it. Thanks felix |
From: Felix S. <fe...@sa...> - 2022-08-22 07:51:36
|
On Mon, Aug 22, 2022 at 01:55:15AM -0300, Daniel Franzini wrote: > The current status is: > > * in rev 13670: both builds pic14 and pic16 are fine without changes; > * but there are some fixes needed in order to run the tests for these > ports. Attached is a patch that provides the necessary fixes (one also > needs to have gpsim installed and in the path for things to run or set the > GPSIM_PATH variable with the path of gpsim; Thanks Daniel. -EXCLUDE_PORTS += \ - pic14 \ - pic16 +# EXCLUDE_PORTS += \ +# pic14 \ +# pic16 The use of EXCLUDE_PORTS here is indeed fishy. We might need some configure logic to determine if gpsim is present... Or do we want pic tests to just fail if there is no gpsim? Fine with me, what do others think? ---- -EMU_INPUT = < $(PORTS_DIR)/$(PORT_BASE)/uCsim.cmd +ifeq ($(PORT_BASE), pic14) +EMU_INPUT = $(PORTS_DIR)/$(PORT_BASE)/gpsim.cmd +EMU_EXTRA_FLAGS = -i -c +else +ifeq ($(PORT_BASE), pic16) +EMU_INPUT = $(PORTS_DIR)/$(PORT_BASE)/gpsim.cmd +EMU_EXTRA_FLAGS = -i -c +else +EMU_INPUT = $(PORTS_DIR)/$(PORT_BASE)/uCsim.cmd +endif +endif Please move PORT specifics into spec.mk. EMU_INPUT is set before [..]/${PORT}/spec.mk is included. Add +# Default Simulator input argument. Override in spec.mk EMU_INPUT = < $(PORTS_DIR)/$(PORT_BASE)/uCsim.cmd Do we really need the EMU_EXTRA_FLAGS variable? Could you use EMU_FLAGS in */spec.mk instead? Best wishes felix |
From: Daniel F. <dan...@gm...> - 2022-08-22 04:55:39
|
The current status is: * in rev 13670: both builds pic14 and pic16 are fine without changes; * but there are some fixes needed in order to run the tests for these ports. Attached is a patch that provides the necessary fixes (one also needs to have gpsim installed and in the path for things to run or set the GPSIM_PATH variable with the path of gpsim; * I ran the tests and I'm not sure if all the errors I got are actually specific for the pic ports. For example, this one (I got a lot of this one): cases/../../../../sdcc/support/regression/cases/../tests/bug-2805.c:9: error 206: invalid combination of short / long * maybe some guidance from more experienced people might help me separating pic-specific bugs from generic compiler bugs (if I'm able to, I will fix as much stuff as I can); * I need help in order to add one more option to the configure script: the ability to set the gputils path at configure time and use it as the default (of course, the command line option will always have the priority but it is difficult e.g. to run the test suite using a newer build of gputils installed in a custom path. The configure script simply detects and uses the gputils but I don't have a chance to point it to one build of mine (newer, more supported chips). Can anyone help? * here is the summary of running make test-pic14 in support/regression: Summary for 'pic14': 406 abnormal stops ( ), 1264 failures, 11746 tests, 2822 test cases, 0 bytes, 0 ticks I'm suspecting that actually no tests were run at all (some tests don't compile and the ones that compile are not being run for some reason I can't see yet). On Sun, Aug 21, 2022 at 7:06 AM Benedikt Freisen <b.f...@gm...> wrote: > Good morning! > > Am 21.08.22 um 07:27 schrieb Michael Havenga: > > Morning Everyone, > > > > Would it be wrong in saying there is some level of renewed interest in > > the PIC support and if the automated testing has been reviewed could > > that potentially lead to a release at some point ? > > > > Have a great day. > > > > Michael A Havenga > > That assessment of the situation is not wrong, but it is not entirely > right, either. > The PIC backends are still part of every official release, but > individual distributors might not be willing to distribute SDCC binaries > with unstable, unmaintained parts of the code enabled. > > The path to _stable_ PIC backends is as follows: > - Stabilize the build process -- it is currently hit or miss > - Stabilize regression testing itself > - Stabilize the compiler, minimizing the number of crashes during > regression testing > - Fix the code generator so that all (or most) regression tests pass > > Needless to say, the fourth step requires extensive knowledge of the PIC > platform and will likely be the hardest. > However, from a distributor's point of view, the software package itself > would already be stable after the completion of step three. > > As always: Contributions are welcome! > > Greetings, > Benedikt > > > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > -- Daniel "Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." (Donald Knuth) "Yes, technogeeks can be funny, even if only to each other." ( http://www.boogieonline.com/revolution/science/humor/)" "Man is driven to create; I know I really love to create things. And while I'm not good at painting, drawing, or music, I can write software." (Yukihiro Matsumoto, a.k.a. ``Matz'') |
From: Benedikt F. <b.f...@gm...> - 2022-08-21 10:05:46
|
Good morning! Am 21.08.22 um 07:27 schrieb Michael Havenga: > Morning Everyone, > > Would it be wrong in saying there is some level of renewed interest in > the PIC support and if the automated testing has been reviewed could > that potentially lead to a release at some point ? > > Have a great day. > > Michael A Havenga That assessment of the situation is not wrong, but it is not entirely right, either. The PIC backends are still part of every official release, but individual distributors might not be willing to distribute SDCC binaries with unstable, unmaintained parts of the code enabled. The path to _stable_ PIC backends is as follows: - Stabilize the build process -- it is currently hit or miss - Stabilize regression testing itself - Stabilize the compiler, minimizing the number of crashes during regression testing - Fix the code generator so that all (or most) regression tests pass Needless to say, the fourth step requires extensive knowledge of the PIC platform and will likely be the hardest. However, from a distributor's point of view, the software package itself would already be stable after the completion of step three. As always: Contributions are welcome! Greetings, Benedikt |
From: Michael H. <mic...@gm...> - 2022-08-21 05:28:08
|
Morning Everyone, Would it be wrong in saying there is some level of renewed interest in the PIC support and if the automated testing has been reviewed could that potentially lead to a release at some point ? Have a great day. Michael A Havenga CELL: 0827728050 On Fri, Aug 19, 2022 at 12:20 AM Daniel Franzini <dan...@gm...> wrote: > I discovered more stuff: > > * the pic14 port testing infrastructure does not set the EMU variable > (this is why I couldn't get any tests to run at all); > * I fixed this and it started to run all tests in gpsim (yay!); > * now I have to properly setup gpsim to actually run the .cod file (it > seems it only loads but does not run the executable); > * I got gpsim working properly after some hacks (I need to refactor some > stuff a little and make a patch). > > On Thu, Aug 18, 2022 at 12:36 PM Daniel Franzini < > dan...@gm...> wrote: > >> I'm trying to run the tests as support/regression. >> >> What would be the correct way to do this? >> Here is how I run everything: >> >> ../sdcc/configure (from build dir) >> make >> cd support/regression >> make test-pic14 >> >> I have gpsim installed and it is on PATH. Even though it is outdated >> (thanks, Debian) I expected to see some results not only error messages >> like this: >> >> gen/pic14/tst_gcc-torture-execute-pr86231.cod: Permission denied >> results/pic14/tst_gcc-torture-execute-pr86231.out:1:--- FAIL: "timeout, >> simulation killed" in cases/tst_gcc-torture-execute-pr86231.c >> Failure: tst_gcc-torture-execute-pr86231 >> tst_gcc-torture-execute-pr86231 (f: 1, t: 1, c: 1, b: 0, T: >> 0) >> >> and this one: >> >> gen/pic14/tst_gcc-torture-execute-strlen-2.cod: No such file or directory >> results/pic14/tst_gcc-torture-execute-strlen-2.out:1:--- FAIL: "timeout, >> simulation killed" in cases/tst_gcc-torture-execute-strlen-2.c >> Failure: tst_gcc-torture-execute-strlen-2 >> tst_gcc-torture-execute-strlen-2 (f: 1, t: 1, c: 1, b: 0, T: >> 0) >> >> Looks like the test .cod executable (the one to run in the simulator) >> doesn't get generated by the build. I'm not sure why. Can you please, help >> me? >> >> On Thu, Aug 18, 2022 at 8:23 AM Philipp Klaus Krause <pk...@sp...> wrote: >> >>> Am 18.08.22 um 12:55 schrieb Daniel Franzini: >>> > _Updated status:_ >>> > * both pic16 and pic14 builds ok_ >>> > _ >>> > * I can't get the testing code to run properly (if I run make >>> test-pic14 >>> > it end with this weird message: >>> > […] >>> > >>> > I didn't expect the testing code to try something with padauk and z80 >>> ports. >>> > >>> > * I had to fix an issue: the testing code pointed the simulator >>> command >>> > file to uCsim.cmd even when pic14 or pic16 are enabled. Attached is a >>> > patch that fixes this one. >>> >>> What do you mean by "testing code"? The old pic-specific, very >>> incomplete tests in src/regression? The real regression tests in >>> support/regression? >>> >>> Philipp >>> >>> >>> _______________________________________________ >>> Sdcc-user mailing list >>> Sdc...@li... >>> https://lists.sourceforge.net/lists/listinfo/sdcc-user >>> >> >> >> -- >> Daniel >> >> "Let us change our traditional attitude to the construction of programs. >> Instead of imagining that our main task is to instruct a computer what to >> do, let us concentrate rather on explaining to human beings what we want a >> computer to do." (Donald Knuth) >> >> "Yes, technogeeks can be funny, even if only to each other." ( >> http://www.boogieonline.com/revolution/science/humor/)" >> >> "Man is driven to create; I know I really love to create things. And >> while I'm not good at painting, drawing, or music, I can write software." >> (Yukihiro Matsumoto, a.k.a. ``Matz'') >> > > > -- > Daniel > > "Let us change our traditional attitude to the construction of programs. > Instead of imagining that our main task is to instruct a computer what to > do, let us concentrate rather on explaining to human beings what we want a > computer to do." (Donald Knuth) > > "Yes, technogeeks can be funny, even if only to each other." ( > http://www.boogieonline.com/revolution/science/humor/)" > > "Man is driven to create; I know I really love to create things. And while > I'm not good at painting, drawing, or music, I can write software." > (Yukihiro Matsumoto, a.k.a. ``Matz'') > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Daniel F. <dan...@gm...> - 2022-08-18 22:20:15
|
I discovered more stuff: * the pic14 port testing infrastructure does not set the EMU variable (this is why I couldn't get any tests to run at all); * I fixed this and it started to run all tests in gpsim (yay!); * now I have to properly setup gpsim to actually run the .cod file (it seems it only loads but does not run the executable); * I got gpsim working properly after some hacks (I need to refactor some stuff a little and make a patch). On Thu, Aug 18, 2022 at 12:36 PM Daniel Franzini <dan...@gm...> wrote: > I'm trying to run the tests as support/regression. > > What would be the correct way to do this? > Here is how I run everything: > > ../sdcc/configure (from build dir) > make > cd support/regression > make test-pic14 > > I have gpsim installed and it is on PATH. Even though it is outdated > (thanks, Debian) I expected to see some results not only error messages > like this: > > gen/pic14/tst_gcc-torture-execute-pr86231.cod: Permission denied > results/pic14/tst_gcc-torture-execute-pr86231.out:1:--- FAIL: "timeout, > simulation killed" in cases/tst_gcc-torture-execute-pr86231.c > Failure: tst_gcc-torture-execute-pr86231 > tst_gcc-torture-execute-pr86231 (f: 1, t: 1, c: 1, b: 0, T: > 0) > > and this one: > > gen/pic14/tst_gcc-torture-execute-strlen-2.cod: No such file or directory > results/pic14/tst_gcc-torture-execute-strlen-2.out:1:--- FAIL: "timeout, > simulation killed" in cases/tst_gcc-torture-execute-strlen-2.c > Failure: tst_gcc-torture-execute-strlen-2 > tst_gcc-torture-execute-strlen-2 (f: 1, t: 1, c: 1, b: 0, T: > 0) > > Looks like the test .cod executable (the one to run in the simulator) > doesn't get generated by the build. I'm not sure why. Can you please, help > me? > > On Thu, Aug 18, 2022 at 8:23 AM Philipp Klaus Krause <pk...@sp...> wrote: > >> Am 18.08.22 um 12:55 schrieb Daniel Franzini: >> > _Updated status:_ >> > * both pic16 and pic14 builds ok_ >> > _ >> > * I can't get the testing code to run properly (if I run make >> test-pic14 >> > it end with this weird message: >> > […] >> > >> > I didn't expect the testing code to try something with padauk and z80 >> ports. >> > >> > * I had to fix an issue: the testing code pointed the simulator command >> > file to uCsim.cmd even when pic14 or pic16 are enabled. Attached is a >> > patch that fixes this one. >> >> What do you mean by "testing code"? The old pic-specific, very >> incomplete tests in src/regression? The real regression tests in >> support/regression? >> >> Philipp >> >> >> _______________________________________________ >> Sdcc-user mailing list >> Sdc...@li... >> https://lists.sourceforge.net/lists/listinfo/sdcc-user >> > > > -- > Daniel > > "Let us change our traditional attitude to the construction of programs. > Instead of imagining that our main task is to instruct a computer what to > do, let us concentrate rather on explaining to human beings what we want a > computer to do." (Donald Knuth) > > "Yes, technogeeks can be funny, even if only to each other." ( > http://www.boogieonline.com/revolution/science/humor/)" > > "Man is driven to create; I know I really love to create things. And while > I'm not good at painting, drawing, or music, I can write software." > (Yukihiro Matsumoto, a.k.a. ``Matz'') > -- Daniel "Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." (Donald Knuth) "Yes, technogeeks can be funny, even if only to each other." ( http://www.boogieonline.com/revolution/science/humor/)" "Man is driven to create; I know I really love to create things. And while I'm not good at painting, drawing, or music, I can write software." (Yukihiro Matsumoto, a.k.a. ``Matz'') |
From: Daniel F. <dan...@gm...> - 2022-08-18 15:36:36
|
I'm trying to run the tests as support/regression. What would be the correct way to do this? Here is how I run everything: ../sdcc/configure (from build dir) make cd support/regression make test-pic14 I have gpsim installed and it is on PATH. Even though it is outdated (thanks, Debian) I expected to see some results not only error messages like this: gen/pic14/tst_gcc-torture-execute-pr86231.cod: Permission denied results/pic14/tst_gcc-torture-execute-pr86231.out:1:--- FAIL: "timeout, simulation killed" in cases/tst_gcc-torture-execute-pr86231.c Failure: tst_gcc-torture-execute-pr86231 tst_gcc-torture-execute-pr86231 (f: 1, t: 1, c: 1, b: 0, T: 0) and this one: gen/pic14/tst_gcc-torture-execute-strlen-2.cod: No such file or directory results/pic14/tst_gcc-torture-execute-strlen-2.out:1:--- FAIL: "timeout, simulation killed" in cases/tst_gcc-torture-execute-strlen-2.c Failure: tst_gcc-torture-execute-strlen-2 tst_gcc-torture-execute-strlen-2 (f: 1, t: 1, c: 1, b: 0, T: 0) Looks like the test .cod executable (the one to run in the simulator) doesn't get generated by the build. I'm not sure why. Can you please, help me? On Thu, Aug 18, 2022 at 8:23 AM Philipp Klaus Krause <pk...@sp...> wrote: > Am 18.08.22 um 12:55 schrieb Daniel Franzini: > > _Updated status:_ > > * both pic16 and pic14 builds ok_ > > _ > > * I can't get the testing code to run properly (if I run make test-pic14 > > it end with this weird message: > > […] > > > > I didn't expect the testing code to try something with padauk and z80 > ports. > > > > * I had to fix an issue: the testing code pointed the simulator command > > file to uCsim.cmd even when pic14 or pic16 are enabled. Attached is a > > patch that fixes this one. > > What do you mean by "testing code"? The old pic-specific, very > incomplete tests in src/regression? The real regression tests in > support/regression? > > Philipp > > > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > -- Daniel "Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." (Donald Knuth) "Yes, technogeeks can be funny, even if only to each other." ( http://www.boogieonline.com/revolution/science/humor/)" "Man is driven to create; I know I really love to create things. And while I'm not good at painting, drawing, or music, I can write software." (Yukihiro Matsumoto, a.k.a. ``Matz'') |
From: Philipp K. K. <pk...@sp...> - 2022-08-18 11:23:57
|
Am 18.08.22 um 12:55 schrieb Daniel Franzini: > _Updated status:_ > * both pic16 and pic14 builds ok_ > _ > * I can't get the testing code to run properly (if I run make test-pic14 > it end with this weird message: > at 1: error 131: cannot generate code for target 'pdk14' > make[2]: *** [Makefile:432: gen/pdk14/testfwk.rel] Error 1 > make[1]: *** [Makefile:365: test-port] Error 2 > at 1: error 131: cannot generate code for target 'z80' > make[2]: *** [Makefile:432: gen/ucz80/testfwk.rel] Error 1 > make[1]: *** [Makefile:365: test-port] Error 2 > at 1: warning 133: Model '--model-huge' not supported for pic16, ignored. > ERROR: device list pic16devices.txt not found, specify its path via -I<path> > '18f452' was not found. > make[2]: *** [Makefile:432: gen/mcs51-huge/testfwk.rel] Error 1 > make[1]: *** [Makefile:365: test-port] Error 2 > at 1: error 131: cannot generate code for target 's08' > make[2]: *** [Makefile:432: gen/s08/testfwk.rel] Error 1 > make[1]: *** [Makefile:365: test-port] Error 2 > at 1: error 131: cannot generate code for target 'z180' > make[2]: *** [Makefile:432: gen/ucz180/testfwk.rel] Error 1 > make[1]: *** [Makefile:365: test-port] Error 2 > make: *** [Makefile:191: test-ports] Error 2 > > I didn't expect the testing code to try something with padauk and z80 ports. Indeed, a "make test-pic14" or "make test-pic16" in support regression should work fine, een if z80 and pdk ports haven't been built at all. Philipp |
From: Philipp K. K. <pk...@sp...> - 2022-08-18 11:22:59
|
Am 18.08.22 um 12:55 schrieb Daniel Franzini: > _Updated status:_ > * both pic16 and pic14 builds ok_ > _ > * I can't get the testing code to run properly (if I run make test-pic14 > it end with this weird message: > […] > > I didn't expect the testing code to try something with padauk and z80 ports. > > * I had to fix an issue: the testing code pointed the simulator command > file to uCsim.cmd even when pic14 or pic16 are enabled. Attached is a > patch that fixes this one. What do you mean by "testing code"? The old pic-specific, very incomplete tests in src/regression? The real regression tests in support/regression? Philipp |
From: Daniel F. <dan...@gm...> - 2022-08-18 10:55:41
|
*Updated status:* * both pic16 and pic14 builds ok * I can't get the testing code to run properly (if I run make test-pic14 it end with this weird message: at 1: error 131: cannot generate code for target 'pdk14' make[2]: *** [Makefile:432: gen/pdk14/testfwk.rel] Error 1 make[1]: *** [Makefile:365: test-port] Error 2 at 1: error 131: cannot generate code for target 'z80' make[2]: *** [Makefile:432: gen/ucz80/testfwk.rel] Error 1 make[1]: *** [Makefile:365: test-port] Error 2 at 1: warning 133: Model '--model-huge' not supported for pic16, ignored. ERROR: device list pic16devices.txt not found, specify its path via -I<path> '18f452' was not found. make[2]: *** [Makefile:432: gen/mcs51-huge/testfwk.rel] Error 1 make[1]: *** [Makefile:365: test-port] Error 2 at 1: error 131: cannot generate code for target 's08' make[2]: *** [Makefile:432: gen/s08/testfwk.rel] Error 1 make[1]: *** [Makefile:365: test-port] Error 2 at 1: error 131: cannot generate code for target 'z180' make[2]: *** [Makefile:432: gen/ucz180/testfwk.rel] Error 1 make[1]: *** [Makefile:365: test-port] Error 2 make: *** [Makefile:191: test-ports] Error 2 I didn't expect the testing code to try something with padauk and z80 ports. * I had to fix an issue: the testing code pointed the simulator command file to uCsim.cmd even when pic14 or pic16 are enabled. Attached is a patch that fixes this one. On Wed, Aug 17, 2022 at 10:02 PM Daniel Franzini <dan...@gm...> wrote: > I'm trying to hack the code myself (I already asked this question a while > ago but due to personal problems I couldn't get much work done). > > Here is the current status of the code as-is: > > * there are two backends for PIC: pic14 and pic16; > * pic14 backend builds and runs tests (seems that I couldn't get any stats > and most likely no test was run but I'm going to check what happened); > * pic16 backend fails to build. > > I also have a question: I'd like to use a custom build of gputils. How can > I point SDCC to use a different build of gputils than the one the distro I > use (Debian) installs in /usr/bin (no, I don't want to overwrite those > binaries because I use them for other projects)? I saw that at some point > in the configure & build process this gets automatically detected and I'd > like it to point to a custom gputils build I did myself. Is this possible? > > On Wed, Aug 17, 2022 at 5:46 PM Benedikt Freisen <b.f...@gm...> > wrote: > >> Hi Michael! >> >> Am 17.08.22 um 21:41 schrieb Michael Havenga: >> > Hi Everyone, >> > >> > I hope all are well. >> > >> > Is there perhaps a resource that details what incomplete pic support >> > means, and what is on the to-do list? >> > >> > Also, is there a dev actively working on the PIC support? >> > >> > Have a great day! >> > >> > Michael A Havenga >> > CELL: 0827728050 >> >> To the best of my knowledge nobody is actively working on the PIC >> targets beyond minor build fixes that become necessary from time to time >> and most currently active SDCC developers are not particularly familiar >> with the platform. >> The most complete resource on PIC support is the bug tracker that >> currently lists 118 open bugs tagged as PIC-related. This is roughly >> one third of all open bugs. >> Consequently, there is no real to-do list, but a good starting point >> wold be to build SDCC with PIC support from source and to subsequently >> try to get the automated regression tests up and running. >> Once you have archived that, you get a better impression of the effect >> that changes to the backend code have on the compiler's stability and >> the quality of the compiler output. >> >> Greetings, >> Benedikt >> >> >> _______________________________________________ >> Sdcc-user mailing list >> Sdc...@li... >> https://lists.sourceforge.net/lists/listinfo/sdcc-user >> > > > -- > Daniel > > "Let us change our traditional attitude to the construction of programs. > Instead of imagining that our main task is to instruct a computer what to > do, let us concentrate rather on explaining to human beings what we want a > computer to do." (Donald Knuth) > > "Yes, technogeeks can be funny, even if only to each other." ( > http://www.boogieonline.com/revolution/science/humor/)" > > "Man is driven to create; I know I really love to create things. And while > I'm not good at painting, drawing, or music, I can write software." > (Yukihiro Matsumoto, a.k.a. ``Matz'') > -- Daniel "Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." (Donald Knuth) "Yes, technogeeks can be funny, even if only to each other." ( http://www.boogieonline.com/revolution/science/humor/)" "Man is driven to create; I know I really love to create things. And while I'm not good at painting, drawing, or music, I can write software." (Yukihiro Matsumoto, a.k.a. ``Matz'') |
From: Daniel F. <dan...@gm...> - 2022-08-18 01:02:46
|
I'm trying to hack the code myself (I already asked this question a while ago but due to personal problems I couldn't get much work done). Here is the current status of the code as-is: * there are two backends for PIC: pic14 and pic16; * pic14 backend builds and runs tests (seems that I couldn't get any stats and most likely no test was run but I'm going to check what happened); * pic16 backend fails to build. I also have a question: I'd like to use a custom build of gputils. How can I point SDCC to use a different build of gputils than the one the distro I use (Debian) installs in /usr/bin (no, I don't want to overwrite those binaries because I use them for other projects)? I saw that at some point in the configure & build process this gets automatically detected and I'd like it to point to a custom gputils build I did myself. Is this possible? On Wed, Aug 17, 2022 at 5:46 PM Benedikt Freisen <b.f...@gm...> wrote: > Hi Michael! > > Am 17.08.22 um 21:41 schrieb Michael Havenga: > > Hi Everyone, > > > > I hope all are well. > > > > Is there perhaps a resource that details what incomplete pic support > > means, and what is on the to-do list? > > > > Also, is there a dev actively working on the PIC support? > > > > Have a great day! > > > > Michael A Havenga > > CELL: 0827728050 > > To the best of my knowledge nobody is actively working on the PIC > targets beyond minor build fixes that become necessary from time to time > and most currently active SDCC developers are not particularly familiar > with the platform. > The most complete resource on PIC support is the bug tracker that > currently lists 118 open bugs tagged as PIC-related. This is roughly > one third of all open bugs. > Consequently, there is no real to-do list, but a good starting point > wold be to build SDCC with PIC support from source and to subsequently > try to get the automated regression tests up and running. > Once you have archived that, you get a better impression of the effect > that changes to the backend code have on the compiler's stability and > the quality of the compiler output. > > Greetings, > Benedikt > > > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > -- Daniel "Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." (Donald Knuth) "Yes, technogeeks can be funny, even if only to each other." ( http://www.boogieonline.com/revolution/science/humor/)" "Man is driven to create; I know I really love to create things. And while I'm not good at painting, drawing, or music, I can write software." (Yukihiro Matsumoto, a.k.a. ``Matz'') |
From: Benedikt F. <b.f...@gm...> - 2022-08-17 20:45:54
|
Hi Michael! Am 17.08.22 um 21:41 schrieb Michael Havenga: > Hi Everyone, > > I hope all are well. > > Is there perhaps a resource that details what incomplete pic support > means, and what is on the to-do list? > > Also, is there a dev actively working on the PIC support? > > Have a great day! > > Michael A Havenga > CELL: 0827728050 To the best of my knowledge nobody is actively working on the PIC targets beyond minor build fixes that become necessary from time to time and most currently active SDCC developers are not particularly familiar with the platform. The most complete resource on PIC support is the bug tracker that currently lists 118 open bugs tagged as PIC-related. This is roughly one third of all open bugs. Consequently, there is no real to-do list, but a good starting point wold be to build SDCC with PIC support from source and to subsequently try to get the automated regression tests up and running. Once you have archived that, you get a better impression of the effect that changes to the backend code have on the compiler's stability and the quality of the compiler output. Greetings, Benedikt |
From: Michael H. <mic...@gm...> - 2022-08-17 19:41:57
|
Hi Everyone, I hope all are well. Is there perhaps a resource that details what incomplete pic support means, and what is on the to-do list? Also, is there a dev actively working on the PIC support? Have a great day! Michael A Havenga CELL: 0827728050 |
From: Basil H. <ba...@st...> - 2022-08-13 20:22:47
|
On 13/08/2022 18:47, Maarten Brock wrote: > To the compiler a call to memcpy is just a call to any unknown function. > Probably it knows about your eeprom_log_fifo_push() implementation not > using a DIV and thus that the ISR is free of any DIV. But when the > memcpy is in it cannot make that *assumption* about it and thus keeps > the workaround. Ah, I guess that explains things. Yes, SDCC would have no visibility into the code of __memcpy() at compile time, because it's part of the pre-compiled standard library, so it can't know what instructions are used within. I suppose the safest way is indeed to assume it might contain a DIV/DIVW instruction. Shame, such calls to __memcpy() - where SDCC uses it 'behind the scenes' for copying structs - are invisible to the average developer, so one might not even realise they're getting the penalty of the overhead of the DIV workaround in their ISRs for no real reason. But then if you're that concerned about performance, you would be looking at the output assembly anyway, and discover it - like I was. :) Regards, Basil Hussain |
From: Maarten B. <sou...@ds...> - 2022-08-13 17:48:16
|
Basil Hussain schreef op 2022-08-13 12:36: > On 13/08/2022 07:24, Philipp Klaus Krause wrote: >> If SDCC can find out that there is no division in the ISR, it will >> omit the workaround. Can you show the code of your ISR here? > > Okay, this is confusing... Since my previous message, I changed some > other code - not touching the ISR code at all - and now SDCC is not > generating the DIV workaround in the ISR! I change that code back to > how it was, and SDCC does generate the DIV. > > Here is the assembly (unoptimised, with --no-peep, in case > optimisations were obscuring things) generated for the ISR: > > ; main.c: 267: void i2c_isr(void) __interrupt(ISR_I2C) { > ; ----------------------------------------- > ; function i2c_isr > ; ----------------------------------------- > _i2c_isr: > clr a > div x, a > ; main.c: 274: PC_ODR ^= _BV(PC_ODR_ODR5); > ld a, 0x500a > xor a, #0x20 > ld 0x500a, a > ; main.c: 279: sr1 = I2C_SR1; > mov _i2c_isr_sr1_65536_68+0, 0x5217 > ; main.c: 280: sr2 = I2C_SR2; > mov _i2c_isr_sr2_65536_68+0, 0x5218 > ; main.c: 281: sr3 = I2C_SR3; > mov _i2c_isr_sr3_65536_68+0, 0x5219 > ; main.c: 284: if(bit_is_set(sr1, I2C_SR1_ADDR)) { > ld a, _i2c_isr_sr1_65536_68+0 > bcp a, #0x02 > jrne 00182$ > jp 00105$ > 00182$: > ; main.c: 285: PC_ODR ^= _BV(PC_ODR_ODR1); > ld a, 0x500a > xor a, #0x02 > ld 0x500a, a > ; main.c: 291: if(bit_is_set(sr3, I2C_SR3_TRA)) { > ld a, _i2c_isr_sr3_65536_68+0 > bcp a, #0x04 > jrne 00183$ > jp 00102$ > 00183$: > ; main.c: 292: state = EEPROM_STATE_DATA; > mov _i2c_isr_state_65536_68+0, #0x03 > jp 00103$ > 00102$: > ; main.c: 294: state = EEPROM_STATE_ADDR_MSB; > mov _i2c_isr_state_65536_68+0, #0x01 > 00103$: > ; main.c: 297: PC_ODR ^= _BV(PC_ODR_ODR1); > ld a, 0x500a > xor a, #0x02 > ld 0x500a, a > 00105$: > ; main.c: 301: if(bit_is_set(sr1, I2C_SR1_RXNE)) { > ld a, _i2c_isr_sr1_65536_68+0 > bcp a, #0x40 > jrne 00184$ > jp 00111$ > 00184$: > ; main.c: 302: PC_ODR ^= _BV(PC_ODR_ODR2); > ld a, 0x500a > xor a, #0x04 > ld 0x500a, a > ; main.c: 304: switch(state) { > ld a, _i2c_isr_state_65536_68+0 > dec a > jrne 00186$ > jp 00106$ > 00186$: > ld a, _i2c_isr_state_65536_68+0 > cp a, #0x02 > jrne 00189$ > jp 00107$ > 00189$: > jp 00108$ > ; main.c: 305: case EEPROM_STATE_ADDR_MSB: > 00106$: > ; main.c: 307: addr = (I2C_DR & EEPROM_ADDR_MASK_MSB) << 8; > ld a, 0x5216 > and a, #0x0f > clrw x > ld xh, a > clr a > ld xl, a > ldw _i2c_isr_addr_65536_68+0, x > ; main.c: 308: state = EEPROM_STATE_ADDR_LSB; > mov _i2c_isr_state_65536_68+0, #0x02 > ; main.c: 309: break; > jp 00109$ > ; main.c: 310: case EEPROM_STATE_ADDR_LSB: > 00107$: > ; main.c: 313: addr |= (I2C_DR & EEPROM_ADDR_MASK_LSB); > ld a, 0x5216 > clrw x > or a, _i2c_isr_addr_65536_68+1 > ld xl, a > ld a, xh > or a, _i2c_isr_addr_65536_68+0 > ld xh, a > ldw _i2c_isr_addr_65536_68+0, x > ; main.c: 314: state = EEPROM_STATE_START; > clr _i2c_isr_state_65536_68+0 > ; main.c: 315: break; > jp 00109$ > ; main.c: 316: default: > 00108$: > ; main.c: 317: state = EEPROM_STATE_START; > clr _i2c_isr_state_65536_68+0 > ; main.c: 319: } > 00109$: > ; main.c: 321: PC_ODR ^= _BV(PC_ODR_ODR2); > ld a, 0x500a > xor a, #0x04 > ld 0x500a, a > 00111$: > ; main.c: 325: if(bit_is_set(sr1, I2C_SR1_TXE)) { > ld a, _i2c_isr_sr1_65536_68+0 > tnz a > jrmi 00191$ > jp 00118$ > 00191$: > ; main.c: 326: PC_ODR ^= _BV(PC_ODR_ODR3); > ld a, 0x500a > xor a, #0x08 > ld 0x500a, a > ; main.c: 328: switch(state) { > ld a, _i2c_isr_state_65536_68+0 > cp a, #0x03 > jrne 00193$ > jp 00194$ > 00193$: > jp 00115$ > 00194$: > ; main.c: 333: data = (addr < sizeof(eeprom_data) ? > eeprom_data[addr] : EEPROM_DATA_BLANK); > ldw x, _i2c_isr_addr_65536_68+0 > cpw x, #0x0279 > jrc 00195$ > jp 00125$ > 00195$: > ldw x, #_eeprom_data+0 > addw x, _i2c_isr_addr_65536_68+0 > ld a, (x) > clrw x > jp 00126$ > 00125$: > ld a, #0xff > clrw x > 00126$: > ld _i2c_isr_data_65536_68+0, a > ; main.c: 334: I2C_DR = data; > mov 0x5216+0, _i2c_isr_data_65536_68+0 > ; main.c: 336: addr = (addr + 1) & EEPROM_ADDR_MASK; > ldw x, _i2c_isr_addr_65536_68+0 > incw x > ld a, xh > and a, #0x0f > ld xh, a > ldw _i2c_isr_addr_65536_68+0, x > ; main.c: 338: if(!eeprom_log_fifo_is_full()) { > call _eeprom_log_fifo_is_full > tnz a > jreq 00196$ > jp 00116$ > 00196$: > ; main.c: 339: log_msg.address = addr; > mov _i2c_isr_log_msg_65536_68+1, _i2c_isr_addr_65536_68+1 > mov _i2c_isr_log_msg_65536_68+0, _i2c_isr_addr_65536_68+0 > ; main.c: 340: log_msg.data = data; > mov _i2c_isr_log_msg_65536_68+2, _i2c_isr_data_65536_68+0 > ; main.c: 341: eeprom_log_fifo_push(&log_msg); > ldw x, #(_i2c_isr_log_msg_65536_68+0) > call _eeprom_log_fifo_push > ; main.c: 344: break; > jp 00116$ > ; main.c: 345: default: > 00115$: > ; main.c: 346: state = EEPROM_STATE_START; > clr _i2c_isr_state_65536_68+0 > ; main.c: 348: } > 00116$: > ; main.c: 350: PC_ODR ^= _BV(PC_ODR_ODR3); > ld a, 0x500a > xor a, #0x08 > ld 0x500a, a > 00118$: > ; main.c: 354: if(bit_is_set(sr2, I2C_SR2_AF)) { > ld a, _i2c_isr_sr2_65536_68+0 > bcp a, #0x04 > jrne 00197$ > jp 00120$ > 00197$: > ; main.c: 355: PC_ODR ^= _BV(PC_ODR_ODR4); > ld a, 0x500a > xor a, #0x10 > ld 0x500a, a > ; main.c: 358: I2C_SR2 &= ~(_BV(I2C_SR2_AF)); > ld a, 0x5218 > and a, #0xfb > ld 0x5218, a > ; main.c: 359: state = EEPROM_STATE_START; > clr _i2c_isr_state_65536_68+0 > ; main.c: 361: PC_ODR ^= _BV(PC_ODR_ODR4); > ld a, 0x500a > xor a, #0x10 > ld 0x500a, a > 00120$: > ; main.c: 365: if(bit_is_set(sr1, I2C_SR1_STOPF)) { > ld a, _i2c_isr_sr1_65536_68+0 > bcp a, #0x10 > jrne 00198$ > jp 00122$ > 00198$: > ; main.c: 366: PC_ODR ^= _BV(PC_ODR_ODR4); > ld a, 0x500a > xor a, #0x10 > ld 0x500a, a > ; main.c: 369: I2C_CR2 |= _BV(I2C_CR2_ACK); > ld a, 0x5211 > or a, #0x04 > ld 0x5211, a > ; main.c: 370: state = EEPROM_STATE_START; > clr _i2c_isr_state_65536_68+0 > ; main.c: 372: PC_ODR ^= _BV(PC_ODR_ODR4); > ld a, 0x500a > xor a, #0x10 > ld 0x500a, a > 00122$: > ; main.c: 375: PC_ODR ^= _BV(PC_ODR_ODR5); > ld a, 0x500a > xor a, #0x20 > ld 0x500a, a > 00123$: > ; main.c: 376: } > iret > > The code that I changed that caused SDCC not to generate the DIV > workaround was in another function, eeprom_log_fifo_push(). The only > relation of that to the ISR is that the ISR calls it. > > The code for that function is quite simple. Here is the version that > causes DIV to be generated: > > ; main.c: 201: static void eeprom_log_fifo_push(const > eeprom_log_msg_t *msg) { > ; ----------------------------------------- > ; function eeprom_log_fifo_push > ; ----------------------------------------- > _eeprom_log_fifo_push: > ; main.c: 202: eeprom_log.head = (eeprom_log.head + 1) & > EEPROM_LOG_FIFO_LEN_MASK; > ld a, _eeprom_log+0 > inc a > and a, #0x7f > ld _eeprom_log+0, a > ; main.c: 214: eeprom_log.queue[eeprom_log.head] = *msg; > exgw x, y > ld a, _eeprom_log+0 > ld xl, a > ld a, #0x03 > mul x, a > addw x, #(_eeprom_log+2) > push #0x03 > push #0x00 > pushw y > call ___memcpy > 00101$: > ; main.c: 215: } > ret > > And here is the changed version that does not generate the DIV: > > ; main.c: 201: static void eeprom_log_fifo_push(const > eeprom_log_msg_t *msg) { > ; ----------------------------------------- > ; function eeprom_log_fifo_push > ; ----------------------------------------- > _eeprom_log_fifo_push: > sub sp, #2 > ldw (0x01, sp), x > ; main.c: 202: eeprom_log.head = (eeprom_log.head + 1) & > EEPROM_LOG_FIFO_LEN_MASK; > ld a, _eeprom_log+0 > inc a > and a, #0x7f > ld _eeprom_log+0, a > ; main.c: 205: eeprom_log_msg_t *log_msg = > &eeprom_log.queue[eeprom_log.head]; > ld a, _eeprom_log+0 > ld xl, a > ld a, #0x03 > mul x, a > addw x, #(_eeprom_log+2) > ; main.c: 206: log_msg->address = msg->address; > ldw y, (0x01, sp) > ldw y, (y) > ldw (x), y > ; main.c: 207: log_msg->data = msg->data; > incw x > incw x > ldw y, (0x01, sp) > ld a, (0x2, y) > ld (x), a > 00101$: > ; main.c: 215: } > addw sp, #2 > ret > > (I was attempting to get rid of the call to ___memcpy().) > > I don't see how any of the code in the other function would have any > impact on whether the DIV workaround is generated or not in the ISR. > Unless it's something to do with the sub-call to ___memcpy() - but I > don't see why that would ever be using a DIV/DIVW instruction. > > Regards, > Basil Hussain To the compiler a call to memcpy is just a call to any unknown function. Probably it knows about your eeprom_log_fifo_push() implementation not using a DIV and thus that the ISR is free of any DIV. But when the memcpy is in it cannot make that *assumption* about it and thus keeps the workaround. Maarten |
From: Basil H. <ba...@st...> - 2022-08-13 11:09:49
|
On 13/08/2022 07:24, Philipp Klaus Krause wrote: > If SDCC can find out that there is no division in the ISR, it will > omit the workaround. Can you show the code of your ISR here? Okay, this is confusing... Since my previous message, I changed some other code - not touching the ISR code at all - and now SDCC is not generating the DIV workaround in the ISR! I change that code back to how it was, and SDCC does generate the DIV. Here is the assembly (unoptimised, with --no-peep, in case optimisations were obscuring things) generated for the ISR: ; main.c: 267: void i2c_isr(void) __interrupt(ISR_I2C) { ; ----------------------------------------- ; function i2c_isr ; ----------------------------------------- _i2c_isr: clr a div x, a ; main.c: 274: PC_ODR ^= _BV(PC_ODR_ODR5); ld a, 0x500a xor a, #0x20 ld 0x500a, a ; main.c: 279: sr1 = I2C_SR1; mov _i2c_isr_sr1_65536_68+0, 0x5217 ; main.c: 280: sr2 = I2C_SR2; mov _i2c_isr_sr2_65536_68+0, 0x5218 ; main.c: 281: sr3 = I2C_SR3; mov _i2c_isr_sr3_65536_68+0, 0x5219 ; main.c: 284: if(bit_is_set(sr1, I2C_SR1_ADDR)) { ld a, _i2c_isr_sr1_65536_68+0 bcp a, #0x02 jrne 00182$ jp 00105$ 00182$: ; main.c: 285: PC_ODR ^= _BV(PC_ODR_ODR1); ld a, 0x500a xor a, #0x02 ld 0x500a, a ; main.c: 291: if(bit_is_set(sr3, I2C_SR3_TRA)) { ld a, _i2c_isr_sr3_65536_68+0 bcp a, #0x04 jrne 00183$ jp 00102$ 00183$: ; main.c: 292: state = EEPROM_STATE_DATA; mov _i2c_isr_state_65536_68+0, #0x03 jp 00103$ 00102$: ; main.c: 294: state = EEPROM_STATE_ADDR_MSB; mov _i2c_isr_state_65536_68+0, #0x01 00103$: ; main.c: 297: PC_ODR ^= _BV(PC_ODR_ODR1); ld a, 0x500a xor a, #0x02 ld 0x500a, a 00105$: ; main.c: 301: if(bit_is_set(sr1, I2C_SR1_RXNE)) { ld a, _i2c_isr_sr1_65536_68+0 bcp a, #0x40 jrne 00184$ jp 00111$ 00184$: ; main.c: 302: PC_ODR ^= _BV(PC_ODR_ODR2); ld a, 0x500a xor a, #0x04 ld 0x500a, a ; main.c: 304: switch(state) { ld a, _i2c_isr_state_65536_68+0 dec a jrne 00186$ jp 00106$ 00186$: ld a, _i2c_isr_state_65536_68+0 cp a, #0x02 jrne 00189$ jp 00107$ 00189$: jp 00108$ ; main.c: 305: case EEPROM_STATE_ADDR_MSB: 00106$: ; main.c: 307: addr = (I2C_DR & EEPROM_ADDR_MASK_MSB) << 8; ld a, 0x5216 and a, #0x0f clrw x ld xh, a clr a ld xl, a ldw _i2c_isr_addr_65536_68+0, x ; main.c: 308: state = EEPROM_STATE_ADDR_LSB; mov _i2c_isr_state_65536_68+0, #0x02 ; main.c: 309: break; jp 00109$ ; main.c: 310: case EEPROM_STATE_ADDR_LSB: 00107$: ; main.c: 313: addr |= (I2C_DR & EEPROM_ADDR_MASK_LSB); ld a, 0x5216 clrw x or a, _i2c_isr_addr_65536_68+1 ld xl, a ld a, xh or a, _i2c_isr_addr_65536_68+0 ld xh, a ldw _i2c_isr_addr_65536_68+0, x ; main.c: 314: state = EEPROM_STATE_START; clr _i2c_isr_state_65536_68+0 ; main.c: 315: break; jp 00109$ ; main.c: 316: default: 00108$: ; main.c: 317: state = EEPROM_STATE_START; clr _i2c_isr_state_65536_68+0 ; main.c: 319: } 00109$: ; main.c: 321: PC_ODR ^= _BV(PC_ODR_ODR2); ld a, 0x500a xor a, #0x04 ld 0x500a, a 00111$: ; main.c: 325: if(bit_is_set(sr1, I2C_SR1_TXE)) { ld a, _i2c_isr_sr1_65536_68+0 tnz a jrmi 00191$ jp 00118$ 00191$: ; main.c: 326: PC_ODR ^= _BV(PC_ODR_ODR3); ld a, 0x500a xor a, #0x08 ld 0x500a, a ; main.c: 328: switch(state) { ld a, _i2c_isr_state_65536_68+0 cp a, #0x03 jrne 00193$ jp 00194$ 00193$: jp 00115$ 00194$: ; main.c: 333: data = (addr < sizeof(eeprom_data) ? eeprom_data[addr] : EEPROM_DATA_BLANK); ldw x, _i2c_isr_addr_65536_68+0 cpw x, #0x0279 jrc 00195$ jp 00125$ 00195$: ldw x, #_eeprom_data+0 addw x, _i2c_isr_addr_65536_68+0 ld a, (x) clrw x jp 00126$ 00125$: ld a, #0xff clrw x 00126$: ld _i2c_isr_data_65536_68+0, a ; main.c: 334: I2C_DR = data; mov 0x5216+0, _i2c_isr_data_65536_68+0 ; main.c: 336: addr = (addr + 1) & EEPROM_ADDR_MASK; ldw x, _i2c_isr_addr_65536_68+0 incw x ld a, xh and a, #0x0f ld xh, a ldw _i2c_isr_addr_65536_68+0, x ; main.c: 338: if(!eeprom_log_fifo_is_full()) { call _eeprom_log_fifo_is_full tnz a jreq 00196$ jp 00116$ 00196$: ; main.c: 339: log_msg.address = addr; mov _i2c_isr_log_msg_65536_68+1, _i2c_isr_addr_65536_68+1 mov _i2c_isr_log_msg_65536_68+0, _i2c_isr_addr_65536_68+0 ; main.c: 340: log_msg.data = data; mov _i2c_isr_log_msg_65536_68+2, _i2c_isr_data_65536_68+0 ; main.c: 341: eeprom_log_fifo_push(&log_msg); ldw x, #(_i2c_isr_log_msg_65536_68+0) call _eeprom_log_fifo_push ; main.c: 344: break; jp 00116$ ; main.c: 345: default: 00115$: ; main.c: 346: state = EEPROM_STATE_START; clr _i2c_isr_state_65536_68+0 ; main.c: 348: } 00116$: ; main.c: 350: PC_ODR ^= _BV(PC_ODR_ODR3); ld a, 0x500a xor a, #0x08 ld 0x500a, a 00118$: ; main.c: 354: if(bit_is_set(sr2, I2C_SR2_AF)) { ld a, _i2c_isr_sr2_65536_68+0 bcp a, #0x04 jrne 00197$ jp 00120$ 00197$: ; main.c: 355: PC_ODR ^= _BV(PC_ODR_ODR4); ld a, 0x500a xor a, #0x10 ld 0x500a, a ; main.c: 358: I2C_SR2 &= ~(_BV(I2C_SR2_AF)); ld a, 0x5218 and a, #0xfb ld 0x5218, a ; main.c: 359: state = EEPROM_STATE_START; clr _i2c_isr_state_65536_68+0 ; main.c: 361: PC_ODR ^= _BV(PC_ODR_ODR4); ld a, 0x500a xor a, #0x10 ld 0x500a, a 00120$: ; main.c: 365: if(bit_is_set(sr1, I2C_SR1_STOPF)) { ld a, _i2c_isr_sr1_65536_68+0 bcp a, #0x10 jrne 00198$ jp 00122$ 00198$: ; main.c: 366: PC_ODR ^= _BV(PC_ODR_ODR4); ld a, 0x500a xor a, #0x10 ld 0x500a, a ; main.c: 369: I2C_CR2 |= _BV(I2C_CR2_ACK); ld a, 0x5211 or a, #0x04 ld 0x5211, a ; main.c: 370: state = EEPROM_STATE_START; clr _i2c_isr_state_65536_68+0 ; main.c: 372: PC_ODR ^= _BV(PC_ODR_ODR4); ld a, 0x500a xor a, #0x10 ld 0x500a, a 00122$: ; main.c: 375: PC_ODR ^= _BV(PC_ODR_ODR5); ld a, 0x500a xor a, #0x20 ld 0x500a, a 00123$: ; main.c: 376: } iret The code that I changed that caused SDCC not to generate the DIV workaround was in another function, eeprom_log_fifo_push(). The only relation of that to the ISR is that the ISR calls it. The code for that function is quite simple. Here is the version that causes DIV to be generated: ; main.c: 201: static void eeprom_log_fifo_push(const eeprom_log_msg_t *msg) { ; ----------------------------------------- ; function eeprom_log_fifo_push ; ----------------------------------------- _eeprom_log_fifo_push: ; main.c: 202: eeprom_log.head = (eeprom_log.head + 1) & EEPROM_LOG_FIFO_LEN_MASK; ld a, _eeprom_log+0 inc a and a, #0x7f ld _eeprom_log+0, a ; main.c: 214: eeprom_log.queue[eeprom_log.head] = *msg; exgw x, y ld a, _eeprom_log+0 ld xl, a ld a, #0x03 mul x, a addw x, #(_eeprom_log+2) push #0x03 push #0x00 pushw y call ___memcpy 00101$: ; main.c: 215: } ret And here is the changed version that does not generate the DIV: ; main.c: 201: static void eeprom_log_fifo_push(const eeprom_log_msg_t *msg) { ; ----------------------------------------- ; function eeprom_log_fifo_push ; ----------------------------------------- _eeprom_log_fifo_push: sub sp, #2 ldw (0x01, sp), x ; main.c: 202: eeprom_log.head = (eeprom_log.head + 1) & EEPROM_LOG_FIFO_LEN_MASK; ld a, _eeprom_log+0 inc a and a, #0x7f ld _eeprom_log+0, a ; main.c: 205: eeprom_log_msg_t *log_msg = &eeprom_log.queue[eeprom_log.head]; ld a, _eeprom_log+0 ld xl, a ld a, #0x03 mul x, a addw x, #(_eeprom_log+2) ; main.c: 206: log_msg->address = msg->address; ldw y, (0x01, sp) ldw y, (y) ldw (x), y ; main.c: 207: log_msg->data = msg->data; incw x incw x ldw y, (0x01, sp) ld a, (0x2, y) ld (x), a 00101$: ; main.c: 215: } addw sp, #2 ret (I was attempting to get rid of the call to ___memcpy().) I don't see how any of the code in the other function would have any impact on whether the DIV workaround is generated or not in the ISR. Unless it's something to do with the sub-call to ___memcpy() - but I don't see why that would ever be using a DIV/DIVW instruction. Regards, Basil Hussain |
From: Philipp K. K. <pk...@sp...> - 2022-08-13 06:25:07
|
Am 12.08.22 um 21:52 schrieb Basil Hussain: > Hi all, > > For the STM8 platform, SDCC adds "clr a", "div x, a" instructions as a > prologue to the start of all interrupt service routines (ISRs) in order > to mitigate the published errata "Unexpected DIV/DIVW instruction result > in ISR". However, as far as I know, this workaround is unnecessary when > the code within the ISR does not perform any division instructions. > If SDCC can find out that there is no division in the ISR, it will omit the workaround. Can you show the code of your ISR here? Philipp |
From: Basil H. <ba...@st...> - 2022-08-12 22:26:18
|
Hi all, For the STM8 platform, SDCC adds "clr a", "div x, a" instructions as a prologue to the start of all interrupt service routines (ISRs) in order to mitigate the published errata "Unexpected DIV/DIVW instruction result in ISR". However, as far as I know, this workaround is unnecessary when the code within the ISR does not perform any division instructions. I am writing some code where I am trying to reduce interrupt latency as much as possible, to respond to an event as quickly as possible. But my ISR code does not use DIV anywhere (in fact, my entire program does not), so this workaround is consuming cycles unnecessarily. Is there any way to tell SDCC to leave the workaround out? I could mark the ISR function as __naked, but then I would have to add my own __asm__("iret"), which would also prevent some peephole optimisation, which I don't want to happen, so I'd prefer if there was some other way. Regards, Basil Hussain |
From: Alan C. <al...@et...> - 2022-08-04 18:29:33
|
On Thu, 4 Aug 2022 09:06:35 +0200 Philipp Klaus Krause <pk...@sp...> wrote: > Am 29.05.22 um 21:44 schrieb Tony Pavlov via Sdcc-user: > > > > > another annoying thing is one byte hidden parameter for the bank number on the Z80 target. > > inc sp/dec sp everywhere, while on gbz80 two bytes are reserved - that is much faster! why > > not unify that? also, on systems like MSX you may want to save/restore more than one page > > and two bytes may be very useful here! > > > > > > Well, I'm personally not very familiar with all that banking stuff. I > try not to break it, but otherwise leave it to other sdcc devs (or wait > for patches from users). But since I'm not that familiar with it, I'm > reluctant to make changes that might be a problem for other users. You actually want the smarts in the linker not the compiler IMHO (especially on Z180 and R2K/R3K). On Z80 with the Fuzix patches for transparent banked support I use push af call foo pop af which has a cost but creates the needed consistent extra stack offset for all functions. The linker rewrites those 5 bytes into something else for a cross bank (or overlay..) function. That allows arbitrary calling between banks to work properly as you've got the 2 bytes needed. Typically it's something like call __bank1_2 ; from 1 to 2 .word foo You also have to rewrite function pointers for it to work properly so that any function pointer is turned into the address of a stub in common space that does the banked call needed. This is also needed for standards compliance so that all references to the address of the function give the same value. R2K/R3K is a bit different because the processor is designed to keep a rolling window of paged in code with most common space for data but apart from having extra hardware support the same basic logic applies along with rather more linker magic to pack functions so no function crosses an 8K boundary. It's something the official compiler does (did - it's basically dead software you have to run under emulators) but would be a big change to the very primitive linker SDCC relies upon. Whether explicit or automatic banking is the best option is another topic altogether and does depend a lot on use cases Alan |
From: Basil H. <ba...@st...> - 2022-08-04 12:50:09
|
On 04/08/2022 08:07, Philipp Klaus Krause wrote: > That technique is likely useful for users who need it for more common > reasons (writing to Flash). Can I put the content of your mailing list > post on the SDCC wiki? Sure, if you like. But, as-is it's specific to assembly code, and doesn't make any provision for code written in C, I don't know how relevant it may be for people looking for solutions in that context. Regards, Basil Hussain |
From: Philipp K. K. <pk...@sp...> - 2022-08-04 07:14:56
|
Am 12.05.20 um 19:06 schrieb Vahid Bashiri: > I'v seen exactly the same problem with "--out-fmt-elf" and "_naked". it > must be bug. Works for me in current svn from trunk, so I guess it is fixed by now. Philipp |
From: Philipp K. K. <pk...@sp...> - 2022-08-04 07:11:38
|
Am 14.10.20 um 03:45 schrieb Ralph Doncaster: > The following program allocates code space for the string, even though > it's only used at compile time by sizeof(). > > int main() > { > return sizeof("hello"); > } I've opened a ticket: https://sourceforge.net/p/sdcc/feature-requests/855/ Philipp |
From: Philipp K. K. <pk...@sp...> - 2022-08-04 07:07:55
|
That technique is likely useful for users who need it for more common reasons (writing to Flash). Can I put the content of your mailing list post on the SDCC wiki? Philipp |