Status of P2 C/C++ Compiler?

The chip is now in a state where C/C++ compiler work can restart, right? I saw Betz posted a comment during the live stream about it, asking Ken if now was a good time to start again. Not sure if the question was lost in the mass of comments or ignored, but I would love to know the answer to that question too. Are we waiting on Parallax to give an "OK"? Or are we just waiting on a community member to give it a go and make it happen? Last I heard, one or two people had brought up the possibility of switching to LLVM instead of GCC for P2. Sounds fun... I don't think I have an opinion. Has a decision been made? If not, do we have everything we need to make said decision?

I'm just eager to help and would love someone to point me at a TODO list and tell me what to do.
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: http://david.zemon.name:8111/?guest=1
«1

Comments

  • 54 Comments sorted by Date Added Votes
  • I don't think we ever got the critical mass for a community project. However, Dave Hein says he intends to continue working on his p2gcc compiler.
  • The P2 is now cast in silicon. I think we can be sure that anything a C/C++ compiler needs from it is not going to change anymore.

    TODO:

    1) Create C/C++ back ends for GCC and Clang/LLVM.

    :)

  • Heater. wrote: »
    The P2 is now cast in silicon. I think we can be sure that anything a C/C++ compiler needs from it is not going to change anymore.

    TODO:

    1) Create C/C++ back ends for GCC and Clang/LLVM.

    :)
    Is that your own personal TODO list? That's great! I'm glad you'll be building these things for us. :smile:
  • Dave HeinDave Hein Posts: 5,575
    edited September 30 Vote Up0Vote Down
    I started the "Can't Wait for PropGCC on the P2?" thread about a year and a half ago. My intent was to try to drum up some interest in developing GCC for the P2 by building on the P1 PropGCC tools. I developed a script called p2gcc and some tools for converting P1 assembly to P2 code, and assembly and loading it. I use the P1 PropGCC compiler to compile C code to P1 COG assembly, and then run it through s2pasm, p2asm and loadp2. The source code is located on GitHub at https://github.com/davehein/p2gcc .

    p2gcc currently supports a basic C library. I have looked at porting the library from PropGCC, and p2gcc can compile much of it. However, there is still a lot of work required to get it to compile the whole library. I also want to add C++ capability.

    I think p2gcc could be used as a starting point for fully implementing GCC on the P2, but we would need people that understand how to modify GCC to support the P2 instruction set. We would then need to modify GAS and the linker for the P2.
  • David Betz,
    Is that your own personal TODO list? That's great! I'm glad you'll be building these things for us.
    Ah, no. DavidZemon asked to be pointed to a TODO list. So I obliged.

    I know what you are getting at. As much as I wish otherwise, trust me, nobody would want to use any compiler I produced. With my meager skills such a thing would produce terrible code, slow and buggy, not to mention it would take me years to even figure out where to start.

    I'm always up for testing duties though.

  • Roy ElthamRoy Eltham Posts: 2,415
    edited September 30 Vote Up0Vote Down
    Once I get OpenSpin for P2 up and running, I will dive in to help with GCC or LLVM for P2. I think we should just pick one and run with that. My vote would be for LLVM since, in my opinion, it is a better compiler front end, but whatever one other people will work on is fine.
  • David BetzDavid Betz Posts: 12,491
    edited September 30 Vote Up0Vote Down
    Roy Eltham wrote: »
    Once I get OpenSpin for P2 up and running, I will dive in to help with GCC or LLVM for P2. I think we should just pick one and run with that. My vote would be for LLVM since, in my opinion, it is a better compiler front end, but whatever one other people will work on is fine.
    You're probably right about LLVM but I know absolutely nothing about it. I do know something about GCC though. In any case, if that's the direction we choose I'll make an attempt to get up to speed but the last time I started reading the LLVM documentation I got lost pretty rapidly. It's possible though that the best approach would be to start with a backend for another processor that is similar to the Propeller rather than trying to understand LLVM from first principles.

  • Yeah, if there is an LLVM backend for a small pic or avr or something like that, then we ought to be able to convert it to P2.
  • Roy Eltham wrote: »
    Yeah, if there is an LLVM backend for a small pic or avr or something like that, then we ought to be able to convert it to P2.
    Really? I would think we would be better off starting with something like MIPS or some other 32 bit processor. Maybe RISC-V?

  • PICs and AVRs come in 32bit flavors. That's what I was thinking. I doubt they have an LLVM backend for the tiny stuff.
    You might be right though, using a MIPs or other 32bit CPU would be okay also.
  • Roy Eltham wrote: »
    PICs and AVRs come in 32bit flavors. That's what I was thinking. I doubt they have an LLVM backend for the tiny stuff.
    You might be right though, using a MIPs or other 32bit CPU would be okay also.
    I hadn't thought about PIC32. That might be an option. I think the 32 bit AVR chips are just ARM cores aren't they?
  • A 32 bit PIC is not a PIC as we used to know it from 8 bit days.

    I thought the PIC32 was based on the MIPS instruction set architecture. https://www.mips.com/blog/tag/pic32/

    Meanwhile the 32 bit AVR is nothing like an 8 bit AVR. They are ARM instruction set architecture.

  • David Betz wrote: »
    I hadn't thought about PIC32. That might be an option. I think the 32 bit AVR chips are just ARM cores aren't they?

    There was an AVR32, but it has been deprecated in favour of the ARM cores.
    It's not likely there are many AVR32 code generators out there...

  • I did a quick scan through the LLVM backend intro stuff. Seems semi straightforward-ish. Define machine, registers, instructions, selector, etc. Their own docs suggest taking an existing backend and modify it.
    They have a dozen or more, including ARM. The main reason I suggested PIC/AVR is that they tend to have different memory areas (code in flash, then data in ram, etc.) which could help with figuring out a Prop1/2 one.
  • IIRC, PIC and Propeller register and branching concepts resemble eachother more than typical register concepts like ARM/i86/80/6800/6502...

    This is logical given the PIC->SX->Propeller progression Chip followed.
  • I doubt the flavor of C makes much difference. Sounds to me like they all use a very small subset of the P2 assembly commands. Seems like more important is to make native P2ASM subroutines easy to use.
    Prop Info and Apps: http://www.rayslogic.com/
  • Dave HeinDave Hein Posts: 5,575
    edited October 1 Vote Up0Vote Down
    It seems to me that it would be less effort to get GCC working for the P2 than to start from scratch with LLVM. The opcodes that PropGCC generates for the P1 are identical to those needed for the P2, except for a few minor differences. I wrote a tool call s2pasm that converts P1 assembly to P2. The main section of code in s2pasm.c is
            ReplaceString("wz,wc", "wcz");
            ReplaceString("\tmax\t", "\tfle\t");
            ReplaceString("\tmaxs\t", "\tfles\t");
            ReplaceString("\tmin\t", "\tfge\t");
            ReplaceString("\tmins\t", "\tfges\t");
            ReplaceString(" max\t", " fle\t");
            ReplaceString(" maxs\t", " fles\t");
            ReplaceString(" min\t", " fge\t");
            ReplaceString(" mins\t", " fges\t");
            ReplaceString("0x", "$");
            ReplaceString("jmpret", "calld");
    
    s2pasm also generates code to emulate waitcnt and reading the CNT register. I use PropGCC in the COG memory model. The code that is generated assumes constants and variable addresses are in COG memory, so s2pasm must also account for the fact that these values are in hub RAM on the P2. For the P2, a new memory model would need to be created that is a hybrid between the COG model and LMM. It doesn't seem like this would be too hard. There are already a number of hooks in PropGCC to handle the P2. I think Eric or David Betz put them in. The library code has some support for the P2 also.

    The remaining parts are the assembler and the linker. I think p2asm could handle this if I modify it to output the ELF format. The linker would then have to be modified to handle the new ways that addresses are packed into instructions, such as with the AUGS and AUGD instructions.

    There's a lot of work to do, but it seems like we're already more than 50% there if we start from PropGCC.
  • Dave Hein wrote: »
    It seems to me that it would be less effort to get GCC working for the P2 than to start from scratch with LLVM. The opcodes that PropGCC generates for the P1 are identical to those needed for the P2, except for a few minor differences. I wrote a tool call s2pasm that converts P1 assembly to P2. The main section of code in s2pasm.c is
            ReplaceString("wz,wc", "wcz");
            ReplaceString("\tmax\t", "\tfle\t");
            ReplaceString("\tmaxs\t", "\tfles\t");
            ReplaceString("\tmin\t", "\tfge\t");
            ReplaceString("\tmins\t", "\tfges\t");
            ReplaceString(" max\t", " fle\t");
            ReplaceString(" maxs\t", " fles\t");
            ReplaceString(" min\t", " fge\t");
            ReplaceString(" mins\t", " fges\t");
            ReplaceString("0x", "$");
            ReplaceString("jmpret", "calld");
    
    s2pasm also generates code to emulate waitcnt and reading the CNT register. I use PropGCC in the COG memory model. The code that is generated assumes constants and variable addresses are in COG memory, so s2pasm must also account for the fact that these values are in hub RAM on the P2. For the P2, a new memory model would need to be created that is a hybrid between the COG model and LMM. It doesn't seem like this would be too hard. There are already a number of hooks in PropGCC to handle the P2. I think Eric or David Betz put them in. The library code has some support for the P2 also.

    The remaining parts are the assembler and the linker. I think p2asm could handle this if I modify it to output the ELF format. The linker would then have to be modified to handle the new ways that addresses are packed into instructions, such as with the AUGS and AUGD instructions.

    There's a lot of work to do, but it seems like we're already more than 50% there if we start from PropGCC.
    It would certainly be easier for me to help if we start with what we already have. I did the initial port of PropGCC to the old P2 but then Eric Smith put in a lot of work as well probably some of it fixing things I did wrong. Anyway, we got it working pretty quickly. If we don't have to port gas that would make the job easier.

  • Does PropGCC already have a runtime flag to enable the P2 mode? That would be a major step if we could get PropGCC to generate P2 assembly. I could then eliminate s2pasm from p2gcc, and then look into generating ELF format from p2asm.
  • Dave Hein wrote: »
    Does PropGCC already have a runtime flag to enable the P2 mode? That would be a major step if we could get PropGCC to generate P2 assembly. I could then eliminate s2pasm from p2gcc, and then look into generating ELF format from p2asm.
    The version that is in the Parallax repository does. I'm not sure about the newer version in Eric's GitHub repository. I think some of the old P2 stuff may have been stripped out of that version. However, we want to start with Eric's version because it's based on a more recent version of GCC.

  • At https://github.com/totalspectrum I see binutils-propeller and proplib. Is that what you're referring to? I don't see the GCC code there. Where is the official GCC compiler? Is the official version at https://github.com/parallaxinc/propgcc ? If so, then does that mean we should use the parallaxinc repository for the compiler, and the totalspectrum repository for the libraries? And what about SimpleIDE?

    It seems like the first thing that should be done is to put all of the latest GCC-related code in one repository.
  • OK, I see it there now. I was just looking at an overview of Eric's site, and not all of the repositories.
  • DavidZemon wrote: »
    The chip is now in a state where C/C++ compiler work can restart, right? I saw Betz posted a comment during the live stream about it, asking Ken if now was a good time to start again. Not sure if the question was lost in the mass of comments or ignored, but I would love to know the answer to that question too. Are we waiting on Parallax to give an "OK"? Or are we just waiting on a community member to give it a go and make it happen? Last I heard, one or two people had brought up the possibility of switching to LLVM instead of GCC for P2. Sounds fun... I don't think I have an opinion. Has a decision been made? If not, do we have everything we need to make said decision?

    I'm just eager to help and would love someone to point me at a TODO list and tell me what to do.

    What we'd like to do is hold a meeting on this topic the first week of November, including all interested developers users. This is what we did last time - met, discussed, formed a team and completed the development work. I will note the meeting date and time here on the forums. We hope to get some of the same team (Eric, Dave, David) and others who wish to participate. It will likely be a Zoom meeting so we can all chat and talk openly.

    One aspect that is very different this time is available budget. We simply don't have the funds available that we did last time.

    Sound like a good approach?

    Thanks,

    Ken Gracey

    - one more small note. It's imperative that Parallax isn't in the middle of all the hardware designs and some software tools. We'll provide the core development tools and compilers, plus one to two boards (likely a module). We hope to see support the community to develop an industry around it.


  • David Betz wrote: »
    Dave Hein wrote: »
    There's a lot of work to do, but it seems like we're already more than 50% there if we start from PropGCC.
    It would certainly be easier for me to help if we start with what we already have. I did the initial port of PropGCC to the old P2 but then Eric Smith put in a lot of work as well probably some of it fixing things I did wrong. Anyway, we got it working pretty quickly. If we don't have to port gas that would make the job easier.

    What I don't know, I certainly truly don't know. But there's one thing I do know: the benefit of leveraging existing efforts that worked. While I often read on the forums that our GCC is outdated and not maintained, it's working well for the core use in educational applications. This is where we needed to go with the compiler for our business. I am sure it may lack certain needs for commercial developers, though.

    If GCC can be improved to achieve the goal we will want to look at this closely as an additional benefit over other alternatives.

    Ken Gracey

  • Thanks for chiming in Ken! I look forward to sitting in on that meeting.
    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: http://david.zemon.name:8111/?guest=1
  • DavidZemon wrote: »
    Thanks for chiming in Ken! I look forward to sitting in on that meeting.

    It'll be great to have you join us.

    We're waiting a bit to start it to see what else Chip learns about the P2. We also need to talk about our priorities with Chip, too.

    Ken Gracey
  • I don't know either but:

    Whatever anyone says about the pros and cons of GCC vs LLVM, GCC is still the compiler of the Linux world and all that rests on top of it.

    I would imagine that whatever exists for Propeller support in GCC can be leveraged for the P2 and recent GCC versions.

    Provided of course those with the know how are available.

  • After thinking about things more, I think we should stick with GCC for the initial C/C++ stuff. Although, we should use the newer version that Eric started.

    Ken, sounds like a reasonable plan, I'd like to be in that meeting, even if I can't initially contribute much to the C/C++ effort since I'll be working on OpenSpin for P2.
  • Ken Gracey wrote: »
    David Betz wrote: »
    Dave Hein wrote: »
    There's a lot of work to do, but it seems like we're already more than 50% there if we start from PropGCC.
    It would certainly be easier for me to help if we start with what we already have. I did the initial port of PropGCC to the old P2 but then Eric Smith put in a lot of work as well probably some of it fixing things I did wrong. Anyway, we got it working pretty quickly. If we don't have to port gas that would make the job easier.

    What I don't know, I certainly truly don't know. But there's one thing I do know: the benefit of leveraging existing efforts that worked. While I often read on the forums that our GCC is outdated and not maintained, it's working well for the core use in educational applications. This is where we needed to go with the compiler for our business. I am sure it may lack certain needs for commercial developers, though.

    If GCC can be improved to achieve the goal we will want to look at this closely as an additional benefit over other alternatives.

    Ken Gracey
    I'm not sure it's correct to say that "GCC is outdated and not maintained". What is true is that our branch can be described that way. Going into the future I think we need to find a way to get updates to our compiler toolchain into production rather than sticking with an old buggy version for years. As we've pointed out a number of times, there have been many bugs and updates done to PropGCC over the years that never made it into the SimpleIDE release. We need to avoid that in the future. We should at least keep up with our own branch! :smile:

Sign In or Register to comment.