OSDev.org

Posted: **Mon Mar 12, 2012 5:46 pm**

I am curious what the difference between gcc compiler and a cross compiler is?

I thought gcc is a cross compiler on its own since it can compile to x86 , x64 ,...mips ,...etc
gcc -march=mips2 ...etc

But then I see from the tutorials you build gcc for a specific arch with ./configure ..., make,..etc

But what I am wondering about is why can some of the different archs, are just switches to the gcc compiler like mips. And others I don't see a switch for and you may have to build gcc for that specific arch.

My confusion is why don't they just have switch that you specify the arch that you want to compile to. I just don't see any reason for building a specific gcc compilers when somebody could easily implement a compiler switch to specify the different archs to compile to.

My understanding of a cross compiler is a compiler made to compile to a specific arch that is not your standard arch. ( i.e a native arch )
But then I don't see any reason why the make you build/configure gcc for a different arch when they could provide it as a command line switch to gcc at run time ?

Posted: **Mon Mar 12, 2012 5:49 pm**

Why do I need a Cross Compiler?

Now with intuitive naming and a painstakingly detailed discourse!

Posted: **Mon Mar 12, 2012 5:55 pm**

well, I just don't see the point?

since why not make gcc with a switch to allow you to compile to any arch you want as your target.

Why go thru the trouble of building gcc for a specific arch.
Just download gcc and specify a target arch that should be it.
Why do they not build gcc in away that supports all currently known /mostly known archs
that way you wouldn't need to go thru the trouble of building it your self?

why go thru the trouble of building gcc from scratch?

Seems like gcc can be made to be a cross compiler itself so why don't they do this.
Is it just size issues or something else?

Posted: **Mon Mar 12, 2012 6:38 pm**

...why?...

Well, because it's GNU software. And as we all know, it's not manly enough to just work out of the box - you need to recompile everything.

Posted: **Mon Mar 12, 2012 6:55 pm**

If you use clang you can compile for another arch using flags.

Posted: **Mon Mar 12, 2012 11:46 pm**

Sam111 wrote:why go thru the trouble of building gcc from scratch?

GCC - GNU Compiler Collection.

Different archs mean different backends, different headers and runtimes (crt0.o). Some GCC-supported arches require non-free support files not existing in other environments but the target one. You either need additional compiler executables, or increase the size of the one executable significantly.

All that trouble, when 99.9% of all users won't need another target than their native one, ever?

Posted: **Tue Mar 13, 2012 1:40 am**

Solar wrote:Different archs mean different backends

What prevents GCC to have these backends to be built-in?

Solar wrote:different headers

Not an impossible task to unify headers for multiple archs.

Solar wrote:and runtimes (crt0.o)

It's up to linker. But again, you may have full collection of libs in the package.

So I suggest to introduce new term: half-cross compiler.

Posted: **Tue Mar 13, 2012 2:14 am**

Yoda wrote:
Solar wrote:Different archs mean different backends
What prevents GCC to have these backends to be built-in?

Distribution size.

Yoda wrote:
Solar wrote:different headers
Not an impossible task to unify headers for multiple archs.

I'd be interested in "unified headers" that support x86_64-suse-linux, powerpc-ibm-aix6.1.0.0 and i686-w64-mingw32 at the same time. How do you think that will work? Especially since the AIX headers are under proprietary license.

Yoda wrote:
Solar wrote:and runtimes (crt0.o)
It's up to linker. But again, you may have full collection of libs in the package.

Only if they're freely redistributable.

Or, to put it differently: Of course you could come up with a GCC distribution that includes backends for each of the >40 supported hardware platforms, headers and runtimes for all supported operating systems etc.

Nothing keeps you from setting one up yourself. GCC provides the necessary options to select between them.

Such a distribution would be several hundred megabytes larger than your current one, making it rival your office suite in size.

And 99.9% of the people would only ever use 1-2% of the available targets.

That is why distributors decide it's not worth the hassle of having their Linux distribution blown up by a significant percentage, especially when chances are high that the distributor has neither the hardware nor the manpower to actually test the functionality of such a multi-target distribution.

(Note that the GCC project itself doesn't distribute binaries at all; they distribute source and leave it up to the individual what kind of cross-platform, cross-language support is required.)

Face it: We - people actually requiring a cross-compiler - are few and far between. As a minority, we have to "make do". Complaining that the big players don't cater for us is juvenile, especially when workarounds are so easy to be had.

Posted: **Tue Mar 13, 2012 3:10 am**

well, couldn't they just cross compile gcc for all the different archs out their naming them
avr-gcc , armgcc , mipsgcc ,...etc and have a top level exe program called gcc with a command line switch that if set to avr calls the avr-gcc to compile/build the code,...etc etc

I don't see space being to big of a problem for HDD of today.
And you could compress it.
But even so their should be a gcc distro that contains all archs and maybe one that only contains the current platform as usual.
Just so developers that are developing for fun on different virtual machines can try out coding stuff fast with out having to create a cross compiler all the time.

Not an impossible task to unify headers for multiple archs.

true , you can do this with alot of macro's and ifdef with makefiles as well,...etc

Distribution size.

Don't see that as being a problem with 3000GB more of HDD space and compression now a days unless of course you are developing on a restrictive size system like some embed systems. But this would be rare since 99.9% of development is on a computer that is x86/64

neither the hardware nor the manpower to actually test the functionality of such a multi-target distribution.

Well with virtual machines you don't really need the hardware to test and manpower is not to much of an effort that is if you already have the code written for the different archs.

I see your point though about the not being needed very often or size issues as well maybe. ( but that doesn't mean they shouldn't make one version for download for the crazy person that wants to develop with it

Question
Is their a classification family of arch's out their meaning
I know their are tons of different archs out their but can they be grouped into a few different families.

For example once you know x86 very well then knowing x64 arch is pretty easy.
Once you know arm then mips is pretty easy to know .
Once you know avr it is not a stretch to know pic ..etc

Seems to me alot of the ISA for different archs are very similar, so is their away we can classify the different archs interms of a few groups of archs.

Just trying to see if one wanted to understand the most archs out their which ones should he learn to get a good bases of almost all of them or most.

For example it seems to me that alot of the different cpu/arch's work the same way for example amd uses gdt just like intel does and has similarly all the same types of modes ...real , protected , long...etc

Anybody know of a chart sort of like the linux distro chart but for arch's/cpu's.

Or maybe processors don't really follow that kind of classification like distro's / OS do.
But I think their should be something out their for classifying the major ones.
Curious how many major different archs are in current use today maybe it is just a handful don't know.... any body know for sure ?

Posted: **Tue Mar 13, 2012 3:31 am**

well, couldn't they just cross compile gcc for all the different archs out their naming them
avr-gcc , armgcc , mipsgcc ,...etc and have a top level exe program called gcc with a command line switch that if set to avr calls the avr-gcc to compile/build the code,...etc etc

They do, silly. Just learn to read.

Don't see that as being a problem with 3000GB more of HDD space and compression

Where did you get your linux? CDs, anyone?

Posted: **Tue Mar 13, 2012 3:35 am**

Question
Is their a classification family of arch's out their meaning
I know their are tons of different archs out their but can they be grouped into a few different families.

For example once you know x86 very well then knowing x64 arch is pretty easy.
Once you know arm then mips is pretty easy to know .
Once you know avr it is not a stretch to know pic ..etc

Seems to me alot of the ISA for different archs are very similar, so is their away we can classify the different archs interms of a few groups of archs.

Just trying to see if one wanted to understand the most archs out their which ones should he learn to get a good bases of almost all of them or most.

For example it seems to me that alot of the different cpu/arch's work the same way for example amd uses gdt just like intel does and has similarly all the same types of modes ...real , protected , long...etc

Anybody know of a chart sort of like the linux distro chart but for arch's/cpu's.

Or maybe processors don't really follow that kind of classification like distro's / OS do.
But I think their should be something out their for classifying the major ones.
Curious how many major different archs are in current use today maybe it is just a handful don't know.... any body know for sure ?

Another thing I am wondering about is classifying ISA into groups that are simalar and ones that are different. So if one was to learn one of each from the different groups of ISA they would have no problem in learning the rest of any of the ISA in any of the groups...
or at least mostly all possible ones.

Obviously we have the categories RISC and CISC but this is to general want to break it down into the main RISC archs/ISA that all RISC processors started from and go from their ,... similarly with CISC

Posted: **Tue Mar 13, 2012 3:52 am**

Sam111 wrote:I don't see space being to big of a problem for HDD of today.

Your HDD might not be a problem. But last time I looked, most Linux distributions still had to fit on a ISO image. And they have to be served (bandwidth). Most Linux distros also take pride in running on not-quite-that-recent hardware.

So you might not see a problem, but it's the distro maintainers making that decision. You could go and bugger them about it.

Just so developers that are developing for fun on different virtual machines can try out coding stuff fast with out having to create a cross compiler all the time.

As I said, that's a vast minority. YOu know the 80-20 rule, do you?

Not an impossible task to unify headers for multiple archs.
true , you can do this with alot of macro's and ifdef with makefiles as well,...etc

If you have read what I wrote, you might be aware that quite some of those headers are part of completely different projects (glibc, µlibc, newlib, ...). Even if you get the licensing issues sorted out (non-trivial e.g. in case of the glibc), do you really want to be the one responsible for keeping that "unified" header in-sync with the various upstream projects?

neither the hardware nor the manpower to actually test the functionality of such a multi-target distribution.
Well with virtual machines you don't really need the hardware to test and manpower is not to much of an effort that is if you already have the code written for the different archs.

I see you have extensive experience as the maintainer of a Linux distro and the process of keeping it tested.

Did I tell the story of the bug I found in the Boost libraries, that happened when you tried to compile Boost::regex with ICU support on an AIX machine? That bug was in there for years, in one of the most heavily-used C++ libraries around, because they didn't have anyone doing testing on an AIX box...

( but that doesn't mean they shouldn't make one version for download for the crazy person that wants to develop with it

Go forth and ask your favourite Linux distributor to do it. Or better yet, be the one who takes the responsibility of maintaining that package.

Question
Is their a classification family of arch's out their meaning

That's not English. As for your use of "their" instead of "there", check my PM from February 29th (which you haven't read yet).

I know their are tons of different archs out their but can they be grouped into a few different families.

They are, just not in the way you demand.

For example once you know x86 very well then knowing x64 arch is pretty easy.
Once you know arm then mips is pretty easy to know .
Once you know avr it is not a stretch to know pic ..etc

Seems to me alot of the ISA for different archs are very similar, so is their away we can classify the different archs interms of a few groups of archs.

The whole idea of high-level languages as those supported by GCC is the ability to program ignorant of the ISA, so why should they bother grouping them by ISA?

Posted: **Tue Mar 13, 2012 4:14 am**

Well, I am with you on the stuff about making a universal cross compiler out of gcc.
It is probably better to just build your own on the rare occasion.

As for the classification and ISA stuff.

They are, just not in the way you demand.

What do you mean... is their like a tree like chart of where all the different cpu/ISA fall under. Equivalent to a linux/unix distro derivation chart.

The whole idea of high-level languages as those supported by GCC is the ability to program ignorant of the ISA, so why should they bother grouping them by ISA?

I understand this that is not what I am disagreeing about.
I just simple wanted to know what the major ISA out their if you became an expert at.
Then you could code in / pick up any or almost all ISA in current use.

Plus when developing an os for multiple arch's you eventually have to use asm. If you want a reason why code in a low level like asm... some times their is no choice.

I guess in theory one could write his own translator/assemblier that just took his defined opcodes and wrote out the machine code corresponding to what he want to.

In theory I guess not even the opcodes exists to the computer/processor only the numbers/machine code associated to those labels. One could easily create different named labels for the same numbers/machine code.

But I was just more curious of 2 things
1) if one wanted to learn the most asm archs what ISA would he need to learn apart from the x86 ?

2) is their some type of percentage of what archs are in use today ?
For an analogy in networking 60% cisco , 25% juniper , 10% HP , 5% others
Is their some thing equivalent for processors/archs/ISA's?

Posted: **Tue Mar 13, 2012 4:24 am**

Sam111 wrote:
They are, just not in the way you demand.
What do you mean... is their like a tree like chart of where all the different cpu/ISA fall under. Equivalent to a linux/unix distro derivation chart.

What I mean is that the GCC targets are grouped, but not by ISA (as it wouldn't make much sense). Try:

Code: Select all

$ cd ${PATH_TO_GCC_SOURCES}
$ ls -lR gcc/config

There's much to be learned there.

I just simple wanted to know what the major ISA out their if you became an expert at.

Syntax error. Cannot parse.

Anyway, teaching you about ISAs is not GCC's business.

1) if one wanted to learn the most asm archs what ISA would he need to learn apart from the x86 ?

Most people fail at mastering even one...

2) is their some type of percentage of what archs are in use today ?
For an analogy in networking 60% cisco , 25% juniper , 10% HP , 5% others
Is their some thing equivalent for processors/archs/ISA's?

In what area? Desktops? Servers? Embedded? Microcontrollers?

Learn about an architecture when the issue of using the hardware actually pops up. Before that, it's meaningless: Unused knowledge grows stale rather quickly.

Posted: **Tue Mar 13, 2012 4:26 am**

Solar wrote:
Yoda wrote:What prevents GCC to have these backends to be built-in?
Distribution size.

In fact, distribution size doesn't prevent, does it?

As for size, I don't think that a couple of megs will play a role for a package of size of dozens megs.
On the other hand, GCC includes frontends for different languages and nobody says: "Get rid of that junk, I'll use pure C!"

Solar wrote:I'd be interested in "unified headers" that support x86_64-suse-linux, powerpc-ibm-aix6.1.0.0 and i686-w64-mingw32 at the same time. How do you think that will work? Especially since the AIX headers are under proprietary license.
...
Or, to put it differently: Of course you could come up with a GCC distribution that includes backends for each of the >40 supported hardware platforms, headers and runtimes for all supported operating systems etc.

To say that it is cross-compiler only backends are actually required. All other are system specific (including headers), not platform. May be with the exception of a very few headers and libs. For example, I may create small embedded system for an old 8086 and I don't need tonns of libs. All I need is just a C-compiler that produces executables for target platform. In fact I'd better say that libs and headers are not parts of compiler. To be more precise - compiler, libs and headers are three components of a specific development kit. But compiler may be (and frequently is) used as standalone tool.

Solar wrote:(Note that the GCC project itself doesn't distribute binaries at all; they distribute source and leave it up to the individual what kind of cross-platform, cross-language support is required.)

That's one of the drawbacks of GCC. I'd better prefer to have product that works out of box instead of spending much time digging lots of compilation options and guessing what to do to force compiler to work as I expect.

OSDev.org

cross compiler ?

cross compiler ?

Re: cross compiler ?

Re: cross compiler ?

Re: cross compiler ?

Re: cross compiler ?

Re: cross compiler ?

Re: cross compiler ?

Re: cross compiler ?

Re: cross compiler ?

Re: cross compiler ?

Re: cross compiler ?

Re: cross compiler ?

Re: cross compiler ?

Re: cross compiler ?

Re: cross compiler ?