We've made a number of changes to gcc 3.3.2 (for MIPS) to support the vagaries of an embedded system we're working on. gcc 3.4 and later appear to have substantially improved the MIPS code generation, so I'm planning to port our changes forward. The question is which gcc version should I target: 3.4.4 or straight to 4.3.2? Its a substantial amount of work to port the changes, I don't want to do it twice and pick the better result.
The Linux-MIPS project still recommends gcc 3.4.4, and MIPS Technologies maintains a modified SDE toolchain based on gcc 3.4.4. Though my embedded system is not running Linux, I respect their expertise.
From what I've read the MIPS backend does not benefit from the higher level optimizations in 4.x, and actually produces slower code than 3.4.4. Can anyone confirm or deny this?
I haven't used MIPS since the classroom so I can't directly answer your question.
I would suggest sending an e-mail to someone on the Linux-MIPS project, and ask when they plan to upgrade. Assuming it is not soon. It looks like 3.4.4 is a worthy upgrade.
Related
Initial note: The question mentions AIX because it is the initial context but the question really pertains to gcc itself, most probably regardless of the platform.
AIX is supposed to be backwards binary compatible: a C program compiled on AIX 5.1 will run as is on 5.2, 5.3, 6.1 and 7.1.
In my understanding gcc should be built to target a specific system (whether the current one or another one in the case of cross-compiling). So, gcc built on AIX 6.1 targets AIX 6.1, and produces binaries usable on both 6.1 and 7.1 thanks to binary compatibility.
Yet gcc itself built on AIX 6.1 is a 6.1 program, so it should execute on 7.1 as is. Of course if I compile a program with it on 7.1, this program might get linked or use headers specific to 7.1, thus making the resulting binary requiring 7.1. So as far as I understand it, I should be able to run gcc built on AIX 6.1 onto a 7.1 machine, and produce maybe non-optimal yet perfectly valid binaries, although they would require 7.1 as a side effect of linking.
This looks too much like rainbows and unicorns dancing in glittery skies. I smell something fishy but lack any knowledge of gcc innards. Please mighty crowd, enlighten me.
tl;dr: Can gcc built on and targeting a version N of an OS/platform be run and used on version N+1 by virtue of platform binary compatibility to produce binaries running on version N+1? If not, what mechanism would prevent it?
Here's enlightenment: your question is way too general. In order to answer it, someone would have to have knowledge of
the operating systems you care about
the OS versions you care about
the gcc versions you care about
and then research the binary compatibility in this three dimensional matrix.
Mechanisms preventing binary compatibility are too numerous and directly correlate to your OS and compiler vendor's ingenuity at breaking it. One of the more common and documented ways being official deprecation of API calls, removal of compatibility libraries shipped, and bridges being burnt, like going from a.out to ELF.
I'm developing a GPS application under Linux, with ARM7 microprocessor.
Which compiler do you recommend? Do you know if there is any toolkit with libraries ready to develop GPS applications?
A friend of mine recommended gcc... what do you guys think about it?
Thank you
I don't think that the compiler matters that much. What is more important is your precise understanding of the library you are using, or of the actual device you are invoking.
However, I will recommend GCC, and I do recommend using a very recent version of GCC. For instance, GCC 4.6.2 is appearing these days, and there have been lot of work recently put in GCC to improve its perfomance for ARM processors. So, if possible, us a 4.6 GCC, not a 4.3 one (some hardware vendors don't give recent GCC with their ARM development kit; you should consider in that case building your GCC (and perhaps binutils) from their source code.
I know nothing about GPS itself.
Setup: I installed Cygwin with the GNU programming lineup (gcc, g++, make, and gdb) and successfully compiled an ran a program that I was working on. Then I decided to install boost into Cygwin because I will need to use typical boost stuff as my program develops. So, using the Cywing setup.exe, I installed boost. After this, the program that I had just successfully compiled and ran no longer worked. (And recall that it didn't depend upon boost.)
I found out that when boost installed, it also installed a new compiler, g++-4.exe, whereas previously I had been using r++-3.exe. Boost had also symbolically linked g++.exe to the new compiler. After I changed back the symbolic link my old program compiled correctly.
Is there any reason that I should be using g++-4 rather than g++-3?
g++ 3 is very old and the gcc community has long since dropped maintenance of it. (GCC 4.3 is currently the oldest maintained release series.) There have been lots of language conformance improvements in newer versions (both in accepting valid code and rejecting bad code), so you'll have an easier time going forward if you bite the bullet now. You can check the release notes for each series (e.g. for 4.0) for explanations of these improvements and the code changes they might require. Personally, I find programming much more enjoyable when I can reason about programs according to a precise language specification, and only rarely be forced to understand the quirks of a particular compiler.
Also, Boost support for g++ 3 seems to be nearing an end, as Boost 1.44 considers GCC 3(.4.6) as an "additional test compiler" on only a single platform (RHEL). Boost development is linear (not branched), so you can find yourself in a situation where you need to upgrade to get bug fixes, but then find that your platform is no longer supported.
I am a complete newbie to the ARM world. I need to be able to write C code, compile it, and then download into an ARM emulator, and execute. I need to use the GCC 4.1.2 compiler for the C code compilation.
Can anybody point me in the correct directions for the following issues?
What tool chain to use?
What emulator to use?
Are there tutorials or guides on setting up the tool chain?
building a gcc cross compiler yourself is pretty easy. the gcc library and the C library and other things not so much, an embedded library and such a little harder. Depends on how embedded you want to get. I have little use for gcclib or a c library so roll your own works great for me.
After many years of doing this, perhaps it is an age thing, I now just go get the code sourcery tools. the lite version works great. yagarto, devkitarm, winarm or something like that (the site with a zillion examples) all work fine. emdebian also has a good pre-built toolchain. a number of these places if not all have info on how they built their toolchains from gnu sources.
You asked about gcc, but bear in mind that llvm is a strong competitor, and as far as cross compiling goes, since it always cross compiles, it is a far easier cross compiler to download and build and get working than gcc. the recent version is now producing code (for arm) that competes with gcc for performance. gcc is in no way a leader in performance, other compilers I have used run circles around it, but it has been improving with each release (well the 3.x versions sometimes produce better code than the 4.x versions, but you need 4.x for the newer cores and thumb2). even if you go with gcc, try the stable release of llvm from time to time.
qemu is a good emulator, depending on what you are doing the gba emulator virtual gameboy advance is good. There are a couple of nds emulators too. GDB and other places have what appear to be ARMs own armulator. I found it hard to extract and use, so I wrote my own, but being lazy only implemented the thumb instruction set, I called mine the thumbulator. easy to use. Far easier than qemu and armulator to add peripherals to and watch and debug your code. ymmv.
Hmmm I posted a similar answer for someone recently. Google: arm verilog and at umich you will find a file isc.tgz in which is an arm10 behavioural (as in you cannot make a chip from it therefore you can find verilog on the net) model. Which for someone wanting to learn an instruction set, watching your code execute at the gate level is about as good as it gets. Be careful, like a drug, you can get addicted then have a hard time when you go back to silicon where you have relatively zero visibility into your code while it is executing. Somewhere in stackoverflow I posted the steps involved to get that arm10 model and another file or two to turn it into an arm emulator using icarus verilog. gtkwave is a good and free tool for examining the wave (vcd) files.
Above all else you will need the ARM ARM. (The ARM Architectural Reference Manual). Just google it and find it on ARM's web site. There is pseudo code for each instruction teaching you what they do. Use the thumbulator or armulator or others if you need to understand more (mame has an arm core in it too). I make no guarantees that the thumbulator is 100% debugged or accurate, I took some common programs and compared their output to silicon both arm and non-arm to debug the core.
Toolchain you can use Yagarto http://www.yagarto.de/
Emulator you can use Proteus ISIS http://www.labcenter.com/index.cfm
(There is a demo version)
and tutorials, well, google them =)
Good luck!
I've found a company that provides GCC based toolchains for ARM, MIPS but I don't know in what are they different from the vanilla GCC, of course, they bring other software pieces such as Eclipse, but when looking only at GCC and Binutils, are they different or just the same?
One big difference between a pre-compiled toolchain (like those provided by Code Sourcery, MontaVista, Wind River, etc) and one built from source is convenience. Building a toolchain from scratch, especially for cross-compiling purposes, is tedious and can be a complete pain. Also, the newest versions of glibc (or uClibc), gcc, and binutils aren’t always compatible as they're developed independently. There are open source tools to make this process easier (like crosstool-NG), but having a proven toolchain that’s been optimized for a certain platform can save a lot of time and headaches. This is especially true at the beginning of a new project. It also helps to have technical support when things go screwy. Of course…you have to pay for it most of the time.
That being said, compiling your own toolchain will most likely save you money and can allow more flexibility down the road. MontaVista, as far as I know, doesn’t include support for older platforms in their newest toolchain releases. For example, if you bought MontaVista Pro 4.X and it included a toolchain with gcc 3.3.X, that’s the toolchain you’re most likely going to be stuck with for the life of your project. Upgrading to a toolchain with gcc 4.X most likely wouldn’t be an option.
Hope that helps.