GCC status
David Betz
Posts: 14,516
in Propeller 2
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.
Comments
Not me.
Gave up for now. Don't understand how binutil and bfd work at all.
Mike
You're not alone there. The GCC code structure is a bit opaque.
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
Are you referring to upstream GCC or PropGCC?
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).
The thinking is to become current with the latest tools and work forward and not be stuck in the past.
Mike
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.
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 ?
Like with PropGCC... :-P
?
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.
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)
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?
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.
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.
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.
Imagine ? Do you mean like how AVR Studio is tied to Visual Studio, and so is Windows only (and proprietary ) ?
Adding libraries is also very easy.
Mike
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.
Just imagine the grief if it was translucent