Talk:Cross compiler

From Wikipedia, the free encyclopedia

I did a few Google checks, and it looks like the hypen dies. That is "cross compiler" wins over "cross-compiler". English, she is a difficult language.

Also, this is closer to a three way merge. There is a good write up on cross compilers in the compiler article.

I disagree. The cross compiler portion of that article links to here and so it should stay. There are only a couple of sentences in that one and it reads more like a dictionary definition than anything encyclopedic. I went away as dumb as I was when I first read the "good write-up". I guess I am just a grumpy old man:) so I'll try to be a little more positive. It's OK but should still link to here, and it does. It's not broken.

--Bill Buckels (talk) 23:07, 9 March 2008 (UTC)

Contents 1 Canadian Cross 2 Aztec C 3 Microsoft C 4 Plan 9 C compilers 5 Flaming Thunder

[edit] Canadian Cross

The section on the Canadian Cross lack context and an explanation of why it is done this way.

Jorge Peixoto 15:45, 9 February 2007 (UTC)

Some knowledge of how Canadian Parliament worked at the time including who the Liberals, Conservatives, and NDP Parties are would probably help you in your understanding. It would probably be clearer if a Donkey and an Elephant had been used, but nothing analoguous to a working-man's party really exists on a national scale directly South of The True North Strong and Free and cultural awareness has not traditionally been bi-directional, but to this Canadian Software Developer the "punnery" of it all makes perfect sense. In this context GNU must be the Bloc Quebecois which also makes me chuckle a little.

--Bill Buckels (talk) 23:51, 8 March 2008 (UTC)

I am Canadian and I still didn't understand why the compiling is done that way. A further explaination (using no or clearer metaphors) would be greatly appreciated. Grant E 67.43.138.51 (talk) 21:19, 17 April 2008 (UTC)

[edit] Aztec C

Aztec C and cross compilers were not necessarily common to some in the world of professional micro computer development back in the 1980's when I was cutting my first C code. Aztec C certainly was. Other developers like John Bridges who wrote PCPaint, the first Paintbrush Program on the IBM PC, used Aztec C for his first versions.

To me it never made sense to sit and develop programs on an slow old Apple II or Commodore 64 even if they were still in use by School and Home Markets. Like most developers, I didn't have much time to waste and using my IBM PC to write the programs in a cross compiler was by far the most productive use of my time, not to mention the most comfortable, since I always felt cramped on those "little boxes".

The GNU stuff came later and so did developing for the ARM processor which by the way Microsoft also offer a cross development environment for amongst others, so I put the Aztec C section at the top. I was however somewhat sensitive to the reasons for cross compilation and stuck my bit about emulators and enthusiasts at the bottom of the list. It is still notable though and deserving of its own unique purpose.

As far as the hyphen winning... it's optional. I didn't use it for this article but have used it professionally on and off in my own stuff for a lot longer than I would care to admit. As far as merging goes, I am against it with the rationale that cross compilers are special cases and do not deserve to be subclassed to some kind of a forced inheritance. It's analoguous to having two kingdoms in the world of compilers. 'Nuff Said.

--Bill Buckels (talk) 23:51, 8 March 2008 (UTC)

[edit] Microsoft C

After adding the section about Aztec C I thought about-it for a bit and then decided I'd best tell the rest of the story. The GNU-ish stuff seemed a little too parochial for my liking, lacking of the substance that led us here, but I didn't necessarily want to promote M$oft despite the fact that I have used their C compilers for almost 25 years. I have developed extensively in Unix and not just Linux over that time as well. I have done HPUX, Solaris, Sun and have had my share of AIX (and Panes too) since coming off the mini's back in the mid-80's and focusing on micros. I wrote what I wrote from memory so at least I haven't lost my mind completely throughout.

Now what I really want to leave you with is a "higher bar" for the rest of this article. There is lots more to tell and this isn't a dictionary... it's an encyclopedia. Some of the articles on WikiPedia are pretty constrained, and much is missing that is relevant, so when I do one I consider it a privilege to provide as much content as possible. This one is still no different and needs work, but two major wacks have been added, and in my opinion the two most significant.

After I wrote the section about the "Little Engine That Could but later ran off the rails", I slept on it, then I picked on the "Cash Cow that sat on the track and derailed them". Hope you enjoyed it.

--Bill Buckels (talk) 22:56, 9 March 2008 (UTC)

[edit] Plan 9 C compilers

I believe some mention should be made of how Plan 9 handles cross-architecture compiling. In short, there's a separate compiler targetting each architecture, which outputs object files named according to the target architecture. This makes cross compiling completely painless. The reference is http://plan9.bell-labs.com/sys/doc/comp.html. 78.52.197.102 (talk) 09:38, 26 March 2008 (UTC)

[edit] Flaming Thunder

Moved from the article. There are no reliable third party sources establishing the notability of this cross compiler. silly rabbit (talk) 01:09, 4 May 2008 (UTC)

Flaming Thunder is a single-asset 8-by-8 shotgun cross compiler^[1].

Cross compilers have inherent O(mnp) weakest-link and version-coherence ("DLL hell") problems, where m is the number of assets (files) in the tool chain (executables, libraries, etc), n is the number of hosts and p is the number of targets. For many cross compilers m, n and p are roughly comparable, so that the maintenance and debugging problems are roughly O(n³). A single-asset n-by-p shotgun cross compiler, such as Flaming Thunder, reduces those problems to O(n), the theoretical minimum.

Flaming Thunder supports 8 major architectures: FreeBSD 32, FreeBSD 64, Linux 32, Linux 64, Mac OS X Intel 32, Mac OS X Intel 64, Windows 32 and Windows 64. There are a plethora of minor versions within those major architectures (for example, Windows 64 includes both Windows Vista Ultimate 64 and Windows XP Professional x64, among others), but they are not counted as separate targets because the executables generated by Flaming Thunder auto-detect minor differences. Flaming Thunder, running on any of those 8 architectures, can produce executables for any of those 8 architectures, so Flaming Thunder is an 8-by-8 cross compiler.

Flaming Thunder is a single-asset cross compiler because all of the tools and libraries that Flaming Thunder needs are internal to the executable file for the Flaming Thunder compiler. Flaming Thunder compiles directly from source code to stand-alone statically-linked executables without using any external tools or libraries.

When running on a particular host, many cross compilers not only require external tools or libraries, but they require different versions of those tools or libraries for each target. Flaming Thunder, however, is a shotgun cross compiler: it can hit all of its targets using only the single executable file for the Flaming Thunder compiler. For example, the following command line (ft is the name of the compiler):

 ft file myprogram.ft target all

will produce 8 target executable files: myprogram-f32, myprogram-f64, myprogram-l32, myprogram-l64, myprogram-m32, myprogram-m64, myprogram-w32.exe and myprogram-w64.exe.