Shop OBEX P1 Docs P2 Docs Learn Events
GCC status — Parallax Forums

GCC status

Is anyone working on GCC for P2 at this point? I know lots of different approaches have been discussed and that we're waiting for Parallax to have a tools meeting to make some decisions but I was wondering if anyone had started any work.
«1

Comments

  • Congrats on post #13,000 ^^^

    Not me.
  • Hmmm... Sounds like no one is doing anything with GCC. I thought I saw some messages about people interested in learning about GCC code generation and thought someone might have started working on generating P2 code.
  • I built a server and put the latest code on it and tried compiling it but came to an error I don't understand and can't fix.

    Gave up for now. Don't understand how binutil and bfd work at all.

    Mike
  • iseries wrote: »
    Don't understand how binutil and bfd work at all.

    You're not alone there. The GCC code structure is a bit opaque.
  • Well at least you have been through the process before. This is all new to me.

    If you want I can give you access to the ubuntu server in the azure cloud.

    You can run the make yourself and see the cryptic error for yourself.

    Mike
  • iseries wrote: »
    I built a server and put the latest code on it and tried compiling it but came to an error I don't understand and can't fix.

    Gave up for now. Don't understand how binutil and bfd work at all.

    Mike

    Are you referring to upstream GCC or PropGCC?
  • iseries wrote: »
    Well at least you have been through the process before. This is all new to me.

    If you want I can give you access to the ubuntu server in the azure cloud.

    You can run the make yourself and see the cryptic error for yourself.

    Mike
    iseries wrote: »
    Well at least you have been through the process before. This is all new to me.

    If you want I can give you access to the ubuntu server in the azure cloud.

    You can run the make yourself and see the cryptic error for yourself.

    Mike
    I had to disable lots of warnings to get PropGCC to build on the Mac. You'll see those in the file called something like "fix_xcode_warnings" in the root directory of PropGCC. Maybe you could try some of those to get it to build on your server?

  • The process I used was to build the P1 code. I first built it on a Ubuntu server with the old references and got that to compile cleaning with the warning you mentioned.

    I then built a new Ubuntu server with the current version and ported to code over and added the new binutil and GAS pieces along with moving over the propeller code I could find and identify.

    So no the problem I am having is not with that.

    Mike

  • DavidZemonDavidZemon Posts: 2,973
    edited 2019-01-15 15:52
    iseries wrote: »
    The process I used was to build the P1 code. I first built it on a Ubuntu server with the old references and got that to compile cleaning with the warning you mentioned.

    I then built a new Ubuntu server with the current version and ported to code over and added the new binutil and GAS pieces along with moving over the propeller code I could find and identify.

    So no the problem I am having is not with that.

    Mike

    Newer versions of GCC can not compile older versions of GCC. I don't know all the specifics, I just know that GCC shipped with Ubuntu 17.10 and newer (maybe it started with 17.04?) can not build PropGCC. The only way I'm able to build PropGCC on my CI server is via Docker (specifically, a Docker image based off of Ubuntu 14.04).
  • Right, PropGCC only compiles on Ubuntu 14 with some modes.

    The thinking is to become current with the latest tools and work forward and not be stuck in the past.

    Mike
  • yetiyeti Posts: 818
    edited 2019-01-15 16:24
    On Debian9 I needed to build TeXinfo-4.13a and GCC-4.9.4 first as springboard to get https://github.com/parallaxinc/propgcc.git built.

    Trying to build PropGCC with Debian9's GCC-6.3.0 direcly failed.

    Building https://github.com/dbetz/propeller-gcc is easier but I didn't find a log about my last builds of this one.
  • jmgjmg Posts: 15,140
    DavidZemon wrote: »
    Newer versions of GCC can not compile older versions of GCC....

    Comments like this make me wonder if GCC is not best totally avoided. That's a long term minefield.
    The in-line ASM syntax GCC imposes is quite a step backwards, and it seems unwieldly to the point of non-productive.

    Contrast that with the rapid progress seen in the FastSpin language suite, is it better to just let FastSpin C improve the C side ? Good enough to run Blockly seems one useful milestone ?

  • jmg wrote: »
    Good enough to run Blockly seems one useful milestone ?
    And then at that milestone development stalls.
    Like with PropGCC... :-P
    ?
  • I'll confess not fully understanding the difference between propgcc and propeller-gcc.

    I see NixOS has direct support for gcc 4.8.5, 4.9.4, 5.5.0, 6.5.0, 7.4.0, 8.2.0.

    I should be able to produce a Linux distribution agnostic version (or build environment for those who want to hack it) if that would help.
  • __red__ wrote: »
    I'll confess not fully understanding the difference between propgcc and propeller-gcc.

    I see NixOS has direct support for gcc 4.8.5, 4.9.4, 5.5.0, 6.5.0, 7.4.0, 8.2.0.

    I should be able to produce a Linux distribution agnostic version (or build environment for those who want to hack it) if that would help.
    The propeller-gcc project is just a container that includes various other repositories. One is the GCC from PropGCC and another is Eric's updated GCC repository. It also includes Eric's binutils which is newer than what is in PropGCC. It's a container so that it is easy to pull in new versions of the component repositories. Basically, it's a bunch of submodules and a Makefile to build them.

  • jmgjmg Posts: 15,140
    yeti wrote: »
    jmg wrote: »
    Good enough to run Blockly seems one useful milestone ?
    And then at that milestone development stalls.
    Like with PropGCC... :-P
    ?

    Not quite, PropGCC has been left behind, by subsequent GCC movements, and it is exactly that future support minefield effect (that other's posts above show clearly) I think it is best to avoid.

    There is no reason for development to stall at all, if development is easy to do.
    Many of the fastspin advances, will be shared amongst all the languages it supports. (as already seen)
  • David Betz wrote: »
    The propeller-gcc project is just a container that includes various other repositories. One is the GCC from PropGCC and another is Eric's updated GCC repository. It also includes Eric's binutils which is newer than what is in PropGCC. It's a container so that it is easy to pull in new versions of the component repositories. Basically, it's a bunch of submodules and a Makefile to build them.

    Huh, so why am I able to compile gcc from the container with gcc-7.3.0 whereas compiling propgcc directly needs me to drop back to gcc-4.8.5?

    I'm guessing I'm compiling Eric's?
  • DavidZemonDavidZemon Posts: 2,973
    edited 2019-01-15 20:42
    Why PropGCC instead of Fastspin?

    First, performance. Fastspin is great, but ersmith makes no claim that it can do all the same optimizations as as GCC. GCC has decades of work put into generating the best possible code, unrolling loops when necessary and inlining functions when possible. Performance is a great reason to work on top of an existing compiler.

    C++ is another reason. I haven't personally written a compiler of any kind, but I've used C++ and read the posts from Eric and Dave saying C++ is a much harder language to compile. Makes sense, right? It's a much more complex language. Inheritance and polymorphism and templates and all that, right? So C++ support is another great reason to use an existing compiler.

    Now maybe you're writing a bunch of low-level code that doesn't need any further optimization and you don't give a rodent's gluteus maximus if C++ is a supported language because C is the One True Language for everything. In that case, the only reason to build on top of an existing compiler is for better support from existing tools (editors, build systems, etc). integrating with other "homegrown" solutions like Spin2Gui, PropellerIDE, and SimpleIDE, this doesn't apply because they're all written from scratch with no assumptions about the compiler being used. But what if you want to integrate with a build system like CMake or Gradle, or an IDE like Visual Studio, Eclipse, or CLion? All of these endevaors will go much smoother if you pick an widely used compiler like GCC or LLVM.

    And finally, Googlability and ease of end-user-modification. Custom tools written only a few years ago that are used by hundreds of people are rarely as flexible or as well-documented as those started decades ago and used by thousands (do you think we're into millions for GCC?). Not to say anyone around here has bad documentation - I'd say both p2gcc and fastspin are very good - but I can't google "fastspin inline assembly enum int literal" like i can "gcc inline assembly enum int literal" to get an existing Stack Overflow post explaining how to use an enum in inline assembly and have it expand to the int literal. Learning how to do new and strange things is much easier with old tools because I can almost guarantee that someone else has already tried to do it and that there is a Stack Overflow post either explaining how to do it or why it can't be done.

    Okay, so you're the kind of person that's writing simple apps using the Parallax-supported tools (SimpleIDE, Blockly, whatever) in C and you're not doing anything so complex as to require Googling features of the compiler. You just want to blink your LED, print your "Hello, world" and get on with the business logic of your application. For you, it doesn't matter. I will make no attempt to say that the four points I've made above apply to everyone, or even the majority. I think there are lots of users on this forum and lots of Parallax customers that don't care about any of those four things.
    .... But I care about all four of those things, and I don't think I'm the only one.
  • David BetzDavid Betz Posts: 14,511
    edited 2019-01-15 21:12
    I'm not sure it's quite as simple as deciding if PropGCC or fastspin is the best solution. We are pretty much guaranteed that fastspin will support the full C language and probably a pretty complete library. That's because it's Eric's project and he has said he intends to do that. However, we don't currently have anyone who has volunteered to get PropGCC up to that level and it's a big job. And, if fastspin satisfies Parallax's requirements for education then they may not be all that interested in GCC making possible that anyone who does volunteer to do all of the GCC work will find their efforts go unused like the updates to PropGCC did once Parallax had what they needed for education. We'll have to see what Parallax decides when they have their internal tools meeting.
  • __red__ wrote: »
    Huh, so why am I able to compile gcc from the container with gcc-7.3.0 whereas compiling propgcc directly needs me to drop back to gcc-4.8.5?
    https://github.com/parallaxinc/propgcc is based on GCC-4.6 and https://github.com/dbetz/propeller-gcc contains that old GCC-4ish one and one based on GCC-6.
  • yeti wrote: »
    __red__ wrote: »
    Huh, so why am I able to compile gcc from the container with gcc-7.3.0 whereas compiling propgcc directly needs me to drop back to gcc-4.8.5?
    https://github.com/parallaxinc/propgcc is based on GCC-4.6 and https://github.com/dbetz/propeller-gcc contains that old GCC-4ish one and one based on GCC-6.
    Correct. The propeller-gcc project can be built using either the old PropGCC version of GCC or with Eric's updated version that is currently, I believe, based on GCC6.
  • jmgjmg Posts: 15,140
    DavidZemon wrote: »
    .... But I care about all four of those things, and I don't think I'm the only one.
    David Betz wrote: »
    I'm not sure it's quite as simple as deciding if PropGCC or fastspin is the best solution. We are pretty much guaranteed that fastspin will support the full C language and probably a pretty complete library. That's because it's Eric's project and he has said he intends to do that. However, we don't currently have anyone who has volunteered to get PropGCC up to that level and it's a big job. And, if fastspin satisfies Parallax's requirements for education then they may not be all that interested in GCC making possible that anyone who does volunteer to do all of the GCC work will find their efforts go unused like the updates to PropGCC did once Parallax had what they needed for education. We'll have to see what Parallax decides when they have their internal tools meeting.

    Of course, it would be great to have both, and maybe P2 will ultimately have enough critical mass to allow that, I'm just wary about the long term, based on past experience.

    DavidZemon wrote: »
    Why PropGCC instead of Fastspin?

    First, performance. Fastspin is great, but ersmith makes no claim that it can do all the same optimizations as as GCC. GCC has decades of work put into generating the best possible code, unrolling loops when necessary and inlining functions when possible. Performance is a great reason to work on top of an existing compiler.
    Yes and no, GCC also tries to shoe-horn Prop into a ARM-like 16 register model, which is actually quite inefficent (but it makes porting easier )]
    Loop unroll and in-line are not complex to support on any compiler.

    On P2, I would say easy in-line assembler, will be far more important for performance

    Look at your other posts around saving registers, and think 'what if I just reserved some of the 500 odd P2 registers, for the interrupt' ?
    All of those issues just go away, and the code is far smaller and faster.

    P2 is a microcontroller, and a relatively small one (with a very small stack), in the ever-expanding MCU space, and 'portability' comes at more of a performance cost, than benefit.

  • I'd say that one of the key reasons that the AVR micro controller series platforms (Arduino's etc) has been so widespread, popular and successful was because of its support for/from GCC. Imagine if all its dev tools were proprietary or fragmented or single platform only. Could it have become quite so popular then?
  • rogloh wrote: »
    I'd say that one of the key reasons that the AVR micro controller series platforms (Arduino's etc) has been so widespread, popular and successful was because of its support for/from GCC. Imagine if all its dev tools were proprietary or fragmented or single platform only. Could it have become quite so popular then?
    Well, fastspin will not be proprietary or single platform so you don't have to worry about that. It's open source. Fragmented could happen though as it can with any open source project including GCC.
  • jmgjmg Posts: 15,140
    rogloh wrote: »
    I'd say that one of the key reasons that the AVR micro controller series platforms (Arduino's etc) has been so widespread, popular and successful was because of its support for/from GCC. Imagine if all its dev tools were proprietary or fragmented or single platform only.

    Imagine ? Do you mean like how AVR Studio is tied to Visual Studio, and so is Windows only (and proprietary ) ? ;)
  • The Arduino platform is widely excepted because it uses standard C++ and that it works on multiple platforms and can now compile applications for STM, AVR, ESP and others as people write compilers for it.

    Adding libraries is also very easy.

    Mike
  • iseries wrote: »
    The Arduino platform is widely excepted because it uses standard C++ and that it works on multiple platforms and can now compile applications for STM, AVR, ESP and others as people write compilers for it.

    Adding libraries is also very easy.

    Mike
    It was popular long before it supported multiple platforms. For a long time it was popular with only AVR support.
  • jmg wrote: »
    Imagine ? Do you mean like how AVR Studio is tied to Visual Studio, and so is Windows only (and proprietary ) ? ;)

    Sure, but you don't have to use AVR Studio. I have been using gcc for AVR for ages on 3 different platforms. Works really well. I think AVR Studio still uses GCC underneath anyway, as does the Arduino IDE.
  • Sorry David.... I just had to say this :)
    You're not alone there. The GCC code structure is a bit opaque.

    Just imagine the grief if it was translucent :)
  • I downloaded Eric's gcc-propeller project. Now how do I build it on my Linux machine? It's been years since I built PropGCC, and it was under Cygwin. I recall having to run some type of config tool first, and then running make, but I can't figure out which directory to do this from.
Sign In or Register to comment.