*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 <daniel.franz...@gmail.com> 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.frei...@gmx.net> > 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 >> Sdcc-user@lists.sourceforge.net >> 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'')
Index: sdcc/support/regression/Makefile.in =================================================================== --- sdcc/support/regression/Makefile.in (revision 13495) +++ sdcc/support/regression/Makefile.in (working copy) @@ -263,7 +263,15 @@ # Only include if we're in a per-port call. ifdef PORT +ifeq ($(PORT_BASE), pic14) +EMU_INPUT = < $(PORTS_DIR)/$(PORT_BASE)/gpsim.cmd +else +ifeq ($(PORT_BASE), pic16) +EMU_INPUT = < $(PORTS_DIR)/$(PORT_BASE)/gpsim.cmd +else EMU_INPUT = < $(PORTS_DIR)/$(PORT_BASE)/uCsim.cmd +endif +endif # run simulator with SIM_TIMEOUT seconds timeout # include ./$(PORT)/spec.mk if exists, else include $(PORTS_DIR)/$(PORT)/spec.mk
_______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
