PropGCC for P2
David Betz
Posts: 14,516
Eric: How hard would it be to move the P1 version of GCC to the current GCC code base?
Comments
Also on my wish list is Visual Studio integration. I'm sure that's impossible, that that is my dream...
Mike
On the P2 we have ample memory so that we can have accurate function timing and native code that can be accurately timed out.
Mike
Mike
Don't confuse Spin the language with PNut the (bytecode) implementation of Spin. The various bytecode Spin compilers all produce basically the same code (bstc can do a little bit of optimization, but not much), and yes, it is slow. But fastspin compiles Spin to LMM code that's similar in speed to GCC LMM code, and can do this for both P1 and P2.
Similarly, when I called riscvp2 a "CMM for P2" I was referring to size, not speed. In fact the riscvp2 implementation of C on P2 produced some of the best C benchmark results I've seen for P2 code, period, beating all of the "native" C compilers (p2gcc, catalina, fastspin) in dhrystone and fft-bench. Which isn't too surprising, because under the hood it really is a native P2 compiler -- it converts the compressed RISC-V opcodes to P2 hubexec code dynamically at run time.
Presumably a native and up to date GCC port for P2 could do even better, but that's not going to appear out of thin air -- it needs real work to happen, and in practice that means that someone is going to have to pay for it. And Parallax is a small company and evidently does not have funds to provide for tools.
Which opens up an interesting question: quite a few people were willing to pay for P2 ES engineering samples. Would a similar number of people be willing to pay for a "professional development kit" containing a high quality native C/C++ compiler for P2? If so perhaps Parallax could sell one and recoup at least some of their development costs for it.
True, although I think it's a pretty safe bet that optimized hubexec code (fastspin) will be faster than any xbyte interpreted code (PNut). The ratio of speed will be interesting to see.
There had been an attempt to let customers pay for a c compiler:
https://imagecraft.com/blog/2008/08/parallax-propeller-and-the-propeller-c-compiler/
This didn't work out. I don't know the exact reasons. I could imagine that some bigger firms would pay good money for a reliable compiler, but I don't see this for a bigger number of makers.
We're all still waiting for P2 rev 2 to get the hands of customers, though. For months now, that's been the best theory thrown around: Parallax is waiting to move forward with a P2 C/C++ compiler until P2 rev 2 is done.
Now the scary thing, is: what happens if Parallax does not initiate any new conversations after P2 rev 2 is done? Then what? I don't know... I guess it will be up to the community to do something.... or not.
Suuuuure would be nice if Parallax at least weighed in and confirmed some of our speculations. At least put the rumor mills to rest.
That's a depressing though. I can't imagine an educational customer caring for C++ support, nor needing the speed of native code. I think the existing C support and MicroPython implementation will be ample for teaching lots of classes for many years.
The thought occurred to me. But with Parallax concentrating on education, the question is "what educational customer is interested in combining Arduino and Propeller?" I would posit none. If they want the Arduino ecosystem, they'll buy Arduino hardware.
So yes, there will be and there are people trying to upgrade from Arduino. But it seems that they are not Parallax's target audience.
The whole thing is a bootstrap. So, it is likely we just need to wait for a time.
Programming in Spin, or in bytecodes, or in C using the CMM does not compute for me. It is like having a Ferrari but driving it very slowly all the time. CMM makes sense for the P1, less for the P2, but Spin is just a big no for me. It does not offer speed.
Definitely, Parallax should develop a C compiler that implements LMM. C++ is not required, IMHO, since the OO approach doesn't bring much usefulness in the context of embedded applications.
Kind regards, Samuel Lourenço
Kind regards, Samuel Lourenço
Eric only provides Windows builds of fastspin, but the code compiles just fine on Linux, and indeed, you can download Linux, Mac, and Raspberry Pi (Linux ARM) binaries from my CI server: https://ci.zemon.name/project/Spin2Cpp?guest=1
Yes, compile it. I just leave a copy in my working directory and assemble with command like ./fastspin or ../fastspin
EDIT: I used Pnut + Loadp2 for a long while with the FPGA because Chip was changing the design rapidly early on.