The pic16 currently "passes" regression tests (well, lots of tests are disabled for pic16, but those that aren't pass). The pic16 port should be included in automatic regression testing to prevent it from breaking more too much too quickly.
Philipp
Feature Requests: #403
Patches: #288
Wiki: SDCC 4.3.0 Release
Wiki: SDCC 4.4.0 Release
Wiki: SDCC 4.5.0 Release
Now that SDCC 3.4.0 it's on sight, could we address this?
What's needed?
Thanks a lot!
1) Fix as many pic16 regression test failures as we can (there's two new ones hat appeared since I opened this feature request, and all the disabled ones).
2) Put the infrastructure on the regression testing machines.
3) Enable it.
Philipp
P.S.: I guess someone familiar with the pic ports and gputils should do this.
I'll try to help with this as much as my time allows.
Regards,
Diego
On Fri, Dec 20, 2013 at 7:25 PM, Philipp Klaus Krause spth@users.sf.netwrote:
Related
Feature Requests: #403
There were a few failing tests for pic16 again. I disabled them. AFAIK the only infrastructure needed on the test machines would be gpsim (in Debian it is in a package of the same name).
Philipp
Good. It would be fine if we finally enable regression tests on pic16.
gputils is also needed on the test machines (maybe you were giving it for granted). In case of gputils, the debian package is usually too old. It would be better to use latest stable version.
Regarding bug-2231, we could apply patch-214 who addresses it instead of disabling it.
Patch-214 wasn't applied because some discussions arose about the need of pic ports to have their own library implementations, and also subtle comments on differences between strncpy on the patch and strncpy on the standard library (namely registers d and d1 reversed)...
I think it's better to apply the patch (d1 and d reversed or not), re-enable bug-2231 and later think about not having separate libraries for pic.
Diego
Is gputils age really an issue? The one from Debian unstable is fine for me. It doesn't support all the targets supported by sdcc, but I can run the regression tests.
Philipp
Don't know, but the version available on Debian is 0.13.7 (as far as I know) which dates back to 2009. There have been 10 releases after it (http://gputils.sourceforge.net/previous.html), 1.4.0 is the latest.
Having said that, it maybe works. Molnar should know better.
These 4 patches make the regression test build again. All PIC14 tests pass, and on PIC16 only the bank1 test fails.
The RFE refers to the real regression tests (support regression), not src/regression.
Philipp
These 2 patches make the regression test under support/regression execute again.
I have some further improvements, which I'll post to the development list at some point.
With this applied pic16 has less regression test failures than any other backend:
Summary for 'pic16': 10 abnormal stops ( ), -32650 failures, 7043 tests, 1719 test cases, 0 bytes, 0 ticks
Philipp
P.S.: The output is still cluttered by lots of messages like
gen/pic16/zeropad/zeropad_storage_auto.asm:1128:Message[1301] Using default destination of 0 (Access Bank).
Regarding crt0iz: While the RAM size is not available at runtime, the amount of RAM used for global variables might be available at linktime. We do not need to zero all RAM. We only need to zero the RAM where variables reside.
In other backends, the startup code uses symbols and lets the linker fill in the actual start address and range to be zeroed. E.g. for stm8:
Philipp
Thanks, I'll have a look at those things.