Hi William, I have marked the release as "ready for cautious usage" merely because I seem to be the only user so far :) Once I see enough non-trivial projects using it, I will remove that wording. While it may not yet have matured into a production quality toolchain, I wouldn't call pru-gcc a toy compiler.
I admit the pru-gcc port had a rough start. But I corrected this by writing real-world examples and running the GCC testsuite through a simulator. Bugs were found and fixed. The pru-gcc test results you pointed are actually pretty good. The 31 unexpected failures are due to reasons like: broken features that are not applicable to PRU, code optimizations that were not applied. I am not aware of any wrong-code-generation bugs. I'm also working on cleaning up the report to avoid further confusion (issue #16 <https://github.com/dinuxbg/gnupru/issues/16>). You can compare the pru results against the mainline gcc test report for x86: https://gcc.gnu.org/ml/gcc-testresults/2015-10/msg00235.html Using pru-gcc you gain GCC - free and familiar compiler. Admittedly, right now CCS generates a bit more optimized code than pru-gcc. And CCS has received more testing than pru-gcc. Regards, Dimitar On Tuesday, July 12, 2016 at 4:47:50 AM UTC+3, William Hermans wrote: > > heh I forgot that "readme dot md's" actually link to some random github > project heh. So . . > > The release is ready for cautious usage. A simulator is used to execute >> the GCC C regression test suite. Results for this release are: >> >> # of expected passes 81497 >> # of unexpected failures 31 >> # of unexpected successes 1 >> # of expected failures 97 >> # of unsupported tests 1974 >> >> > This message has changed some since the last time I read it but pretty > much the same result. In my mind - Don't use it. > > > On Mon, Jul 11, 2016 at 6:44 PM, William Hermans <yyr...@gmail.com > <javascript:>> wrote: > >> Jason: >>> I'm using gcc on the ARM and clpru on the PRU. Both are installed. >>> >>> What would you gain by using gcc on the PRU? >>> >>> --Mark >>> >> >> Let me answer this for you Mark. You would gain nothing. The contributor >> of the pru gcc implementation hints that it's nothign more than a toy, and >> that code generated with it should be thought of nothign more than >> experimental. It says this right on the github project page readme.md. >> >> On Mon, Jul 11, 2016 at 6:39 PM, William Hermans <yyr...@gmail.com >> <javascript:>> wrote: >> >>> Hi Mark, >>> >>> Well I do not know, what would be the simplest example that is close >>> enough to the traditional hello world app ? I was thinking perhaps blinking >>> a USR LED, since one would not have to add any additional hardware. But I >>> looked into that a while back, and doing this would not be a trivial matter >>> I think. Well actually . . . it depends on how remoteproc is implemented. >>> If remoteproc can gain direct access to CPU memory addressing as can be >>> done using uio_pruss. Then it should not be too much trouble. >>> >>> So maybe an external LED example? Which would work out very close to how >>> one would toggle a GPIO( LED ) on a bare metal platform. So anyone having >>> background experience with something like a TI Launchpad or Arduino should >>> be able to understand this very easily. >>> >>> Passed that . . some kind of communication example. I was thinking >>> perhaps usrspace to PRU core 1, to PRU core 2, then back to userspace. As a >>> way for people to get their feet wet, with something easily verifiable. >>> Then perhaps a shared memory example. >>> >>> >>> On Mon, Jul 11, 2016 at 6:14 PM, Mark A. Yoder <mark.a...@gmail.com >>> <javascript:>> wrote: >>> >>>> Greg: >>>> I tried removing the symbolic links and I get the following error >>>> when running make on a BeagleScope example. >>>> >>>> Invoking: PRU Compiler >>>> /usr/share/ti/cgt-pru/bin/clpru >>>> --include_path=/usr/share/ti/cgt-pru/include >>>> --include_path=../../../include --include_path=../../../include/am335x -v3 >>>> -O2 --display_error_number --endian=little --hardware_mac=on >>>> --obj_directory=gen --pp_directory=gen -ppd -ppa -fe >>>> gen/PRU_gpioToggle.object PRU_gpioToggle.c >>>> make: /usr/share/ti/cgt-pru/bin/clpru: Command not found >>>> Makefile:63: recipe for target 'gen/PRU_gpioToggle.object' failed >>>> >>>> The error goes away when I put the link back. Maybe the BeagleScope >>>> makefiles aren't set up right. >>>> >>>> --Mark >>>> >>>> On Monday, July 11, 2016 at 8:08:40 PM UTC-4, Greg wrote: >>>>> >>>>> One note on the compiler set-up: >>>>> >>>>> *ln -s `which lnkpru` .* >>>>> >>>>> I haven't found a reason to use the lnkpru command. The linking is done >>>>> with clpru with the -z option. >>>>> >>>>> Compile and link processes all done with a single command. The >>>>> PRU compiler manual explains the options reasonably thoroughly. >>>>> >>>>> Regards, >>>>> Greg >>>>> >>>> -- >>>> For more options, visit http://beagleboard.org/discuss >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "BeagleBoard" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to beagleboard...@googlegroups.com <javascript:>. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/beagleboard/6e34f332-77b5-4f0d-9267-3a5daca38616%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/beagleboard/6e34f332-77b5-4f0d-9267-3a5daca38616%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/08fbb391-c5c7-4f99-a1bd-74f0b5143dfd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
