PropGCC for P2

David BetzDavid Betz Posts: 13,421
edited 2019-08-12 - 17:22:40 in Propeller 2
Eric: How hard would it be to move the P1 version of GCC to the current GCC code base?
«1

Comments

  • I don't know. It depends on how much GCC has changed.
  • ersmith wrote: »
    I don't know. It depends on how much GCC has changed.
    Makes sense. Maybe I should look at the release notes for the versions since the one you last integrated.

  • Personally, I would really like to see GCC for P2. Also, I'd like C++ for P2. Maybe chasing rainbows, but that's what I'd like.
    Also on my wish list is Visual Studio integration. I'm sure that's impossible, that that is my dream...
    Prop Info and Apps: http://www.rayslogic.com/
  • C++ for P2 is available now, in the form of the RISC-V JIT compiler. Which I probably should just call "GCC CMM mode for P2" so people will use it :).
  • I can't see a use for CMM mode on the P2. I would like LMM on the P2 so that I can meet timing requirements of the process.

    Mike
  • iseries wrote: »
    I can't see a use for CMM mode on the P2. I would like LMM on the P2 so that I can meet timing requirements of the process.

    Mike
    I find it interesting that you see no need for CMM on the P2. Quite a few people here (maybe not you though) have said they see a need for the byte code version of Spin2 that Chip is making in spite of the fact that a native code version of Spin already exists in the form of Fastspin. Why would compact code be needed for Spin but not for C? Anyway, I think Eric's comment that the RISC-V runtime for the P2 is basically CMM is interesting.
  • I found that CMM on the P1 produced code that did not work for time sensitive functions and lead to poor performance. It was needed on the P1 because of the small memory space and was the only cure.

    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
  • SPIN produces good code that works. But 90% of all functions that require any kind of timing are really not SPIN code but SPIN assembly code. SPIN does not produce fast code.

    Mike
  • I think it’s too early to comment about the speed of spin2 bytecode and its interpreter!!!
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • iseries wrote: »
    SPIN produces good code that works. But 90% of all functions that require any kind of timing are really not SPIN code but SPIN assembly code. SPIN does not produce fast code.

    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.
  • Cluso99 wrote: »
    I think it’s too early to comment about the speed of spin2 bytecode and its interpreter!!!

    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.
  • Cluso is holding his cards! I remember him and Chip comparing runtime speeds when Chip got first version of Spin2 up and running.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • ersmith wrote: »
    iseries wrote: »
    SPIN produces good code that works. But 90% of all functions that require any kind of timing are really not SPIN code but SPIN assembly code. SPIN does not produce fast code.

    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.

    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.
  • 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.
    I don't think that was exactly what Eric was suggesting. The Imagecraft compiler was a commercial product that users had to pay to use. I think Eric is suggesting that people might be willing to contribute toward the development of a tool that Parallax will make available for free once it is done.

  • Why pay for a C compiler when there are free alternatives? I'm afraid that Parallax has waited too long to develop a GCC compiler for the P2, and it may never happen. There are four free compilers that have been developed for the P2 so I'm not sure there is much motivation for yet another compiler.
  • Dave Hein wrote: »
    Why pay for a C compiler when there are free alternatives? I'm afraid that Parallax has waited too long to develop a GCC compiler for the P2, and it may never happen. There are four free compilers that have been developed for the P2 so I'm not sure there is much motivation for yet another compiler.
    I doubt that Parallax has a burning desire to create their own C compiler for the P2. I think they are mostly concerned that there exists an adequate C compiler for their customer's needs. They may feel that the current offerings provide that and that there is no need for an expensive GCC or LLVM effort.

  • DavidZemonDavidZemon Posts: 2,781
    edited 2019-08-19 - 18:54:35
    From Parallax's perspective, I can imagine them being quite comfortable with the solutions provided so far. They can wrap any number of different tools with their own custom UI again (SimpleIDE v2 :confused: ) and their target audience will never know nor care about whatever happens behind the smoke and mirrors. We as a community are not thrilled with this, of course. I want Rust. Some (including me) want C++. Others what C/C++ running at its fastest possible speed, instead of through Eric's CMM (RISC-V) implementation.

    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.
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: https://ci.zemon.name?guest=1
  • DavidZemon wrote: »
    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.
    I think it's more likely that Parallax is waiting for some customer or potential to ask for a better C compiler than what is currently available. If nothing was available then they would likely start an effort to create something. However, we do have C solutions now so the urgency is reduced. As you say, some customer demanding C++ generating native code would probably result in some activity on GCC or LLVM.
  • David Betz wrote: »
    DavidZemon wrote: »
    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.
    I think it's more likely that Parallax is waiting for some customer or potential to ask for a better C compiler than what is currently available. If nothing was available then they would likely start an effort to create something. However, we do have C solutions now so the urgency is reduced. As you say, some customer demanding C++ generating native code would probably result in some activity on GCC or LLVM.

    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.
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: https://ci.zemon.name?guest=1
  • DavidZemon wrote: »
    David Betz wrote: »
    DavidZemon wrote: »
    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.
    I think it's more likely that Parallax is waiting for some customer or potential to ask for a better C compiler than what is currently available. If nothing was available then they would likely start an effort to create something. However, we do have C solutions now so the urgency is reduced. As you say, some customer demanding C++ generating native code would probably result in some activity on GCC or LLVM.

    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.
    Need to find a potential commercial customer who wants to buy zillions of chips and also needs C++.

  • What about people trying to upgrade from Arduino? I think they will want C++...
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    What about people trying to upgrade from Arduino? I think they will want C++...
    You'd have to ask Parallax if they have any interest in supporting the Arduino libraries. They didn't seem interested for P1. I'm not sure if that's changed for P2.

  • Rayman wrote: »
    What about people trying to upgrade from Arduino? I think they will want C++...

    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.
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: https://ci.zemon.name?guest=1
  • FWIW, when Parallax begins to see revenue from P2, these discussions will change.

    The whole thing is a bootstrap. So, it is likely we just need to wait for a time.

    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • The LMM as implemented in SimpleIDE seems to generate very fast code. I think nothing would be lost if Parallax released a similar tool for the P2.

    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
  • samuell wrote: »
    The LMM as implemented in SimpleIDE seems to generate very fast code. I think nothing would be lost if Parallax released a similar tool for the P2.

    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
    There really is no need for LMM on the P2. The P2 COG can execute code directly from hub memory. Also, there already exists at least two compilers that generate hub exec code for P2: fastspin and Catalina.

  • David Betz wrote: »
    samuell wrote: »
    The LMM as implemented in SimpleIDE seems to generate very fast code. I think nothing would be lost if Parallax released a similar tool for the P2.

    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
    There really is no need for LMM on the P2. The P2 COG can execute code directly from hub memory. Also, there already exists at least two compilers that generate hub exec code for P2: fastspin and Catalina.
    Thanks for the info. But either fastspin and Catalina are Windows only solutions. I want bo be able to compile my code in Linux, natively.

    Kind regards, Samuel Lourenço
  • DavidZemonDavidZemon Posts: 2,781
    edited 2019-08-19 - 22:49:59
    samuell wrote: »
    David Betz wrote: »
    samuell wrote: »
    The LMM as implemented in SimpleIDE seems to generate very fast code. I think nothing would be lost if Parallax released a similar tool for the P2.

    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
    There really is no need for LMM on the P2. The P2 COG can execute code directly from hub memory. Also, there already exists at least two compilers that generate hub exec code for P2: fastspin and Catalina.
    Thanks for the info. But either fastspin and Catalina are Windows only solutions. I want bo be able to compile my code in Linux, natively.

    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
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: https://ci.zemon.name?guest=1
  • samuell wrote: »
    David Betz wrote: »
    samuell wrote: »
    The LMM as implemented in SimpleIDE seems to generate very fast code. I think nothing would be lost if Parallax released a similar tool for the P2.

    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
    There really is no need for LMM on the P2. The P2 COG can execute code directly from hub memory. Also, there already exists at least two compilers that generate hub exec code for P2: fastspin and Catalina.
    Thanks for the info. But either fastspin and Catalina are Windows only solutions. I want bo be able to compile my code in Linux, natively.

    Kind regards, Samuel Lourenço
    Fastspin will also run under Linux and on the Mac. I believe Catalina will as well. However, you may have to build them from sources.

  • evanhevanh Posts: 7,522
    edited 2019-08-20 - 00:14:52
    I've been using Fastspin + Loadp2 on Linux for years. Also used p2asm a little. I will occasionally test assemble code using Pnut on Wine.

    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.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
Sign In or Register to comment.