The parent poster is wrong. IA-64's assembler syntax _has_ to be different from the AMD64 syntax because it is a totall different architecture with a completely different instruction set and many features that no x86* chips have. For example you need to mark bundles and add stop bits, and so on. So what the heck is the parent poster talking about. Flaimbite, if you ask me.
FWIW, the IA-64 assembler syntax (at least the form used by the GNU assembler) is much easier than all x86 and AMD64 assembly I have seen and worked on.
Add to that the near-total lack of participation and support from HP and Intel for third-party compilers, and you know why so few good IA-64 compilers (if any) exist.
The problem with Itanium is that it was hyped as the greatest thing since sliced bread. But when Merced ("Itanium 1" so to speak) was finally released to the market, two years after its originally planned introduction date, it was already outdated and being outperformed by competing CPUs including x86-based ones. Also, Merced was overpriced, was over-designed, produced more heat than the sum of all its competitors, and the market was still not ready for Itanium because specifications were released so late (even to NDA signers).
With over-designed, I mean it had way too many features that nobody would have cared about if Itanium would have been a success in its own right. Things like supporting ix86 on the chip; supporting HP-PA; supporting both big endian and little endian; supporting 32 bits pointers and 64 bits pointers (OK, the last one is perhaps useful sometimes, but still...).
To illustrate how bad the heat was: At the company I work for, in the south-east of Germany, we had an entire floor that didn't need heating in the winters -- each room had an Itanium work station and that was enough. In the summer those machines were turned off whenever possible.
Anyway, within a year after Merced, McKinley was released, and it was a huge jump forward compared to Merced when comparing heat consumption and performance. It was almost a competitive product, except for the price and the lack of easy hardware support for virtualization. Hell, it is not clear to me to this day what market Intel and HP were trying to attack, but it definitely was already a declining market at the time: Work stations (i.e. that market where Sun and SGI were performing so well in even then) and Big Iron, which is hardly a market large enough to sustain the huge development effort of Itanium.
By now, AMD64 was coming to the market as well, and it was cheaper, it was 64 bits, it had a great memory controler, and as a bonus it was backward compatible with the mainstream architecture of the day.
Now you make the business decision: What do you want to sell? Hot, underperforming, expensive Itanium-based machines for which no software exists? Or machines that are cheaper and which can run all the software on the market?
I know it has been said that Itanium is too difficult to compile for, and that GCC is to blame for the failure of linux-on-ia64. Or that Microsoft pulled the plug on Itanium when they decided to drop Windows-on-ia64. But if you see the market hype of the late 1990s and early 2000, 2001, Itanium was a hot topic and everyone was on that boat. In the end, it was Intel and HP trying too hard to make Itanium compatible with everything (which was never really possible, so what were they thinking?!) and initially not living up to their words about the performance potential of Itanium.
It is sad, because really if you look at it, there are some pretty good ideas in the Itanium.
The answer is in the text, from this doctor Nakashima, who appeared to be the only one around who was familiar with the symptoms of radiation disease.
The article says this (in part 4):
Nakashima differed with general physicians who have asked the regiment to close off a bombed area claiming that returned refugees are infected from the ground by lethal rays.
"I believe that any after effect out there is negligible. I mean to make tests soon with an electrometer," said the specialist.
GCC produces no worse code for SSE than it does for AltiVec. And Apple doing anything right for GCC is another thing that will not happen until hell freezes over. Now, I'll have to admit that today proves it could happen. But given Apple's current totally failing GCC engineering efforts, it would surprise me even more than this Apple move today.
You're all wrong. For the low-level stuff Uli is talking about (glibc, GCC), supporting minority targets is troublesome even when the best of coding practices are put to use. For example for GCC it means that every optimizer change can cause a regression on ill-tested targets. In the past, silly bugs in the mighty IP2000 or AVR ports could block a GCC release for weeks, until the Release Manager decided that the regression wasn't important enough to block a release.
Uli's point that the complexity of software grows exponentially with the number of supported targets is also without doubt true. So from an engineering point of view it makes sense to support as few platforms as reasonably possible. If that means dropping AIX, Solaris, and other proprierary UNIX flavors, and leaving the maintenance of those ports up to the companies that are interested in maintaining those ports, makes absolutely perfect sense. Needless to say, the community should try to be helpful when there would be issues with such ports that require more than a maintenance effort to resolve (i.e. something in GCC is too ELF-ish but a port still uses COFF). But the burden of fixing latent broken things in poorly tested ports now resides with whoever post a perfectly valid patch that exposes the latent bug, and that is IMVHO Just Wrong.
I agree it is sad that there are projects that ignore warnings.
I don't think his comments have much to do with Uli being a RedHat employee or not. I am not a RH employee and I still agree with him on most (but certainly not all!) of the issues he raises in his rant.
Typical for Apple in the FOSS world
on
Safari vs. KHTML
·
· Score: 1, Troll
Apple is just a lousy company to co-operate with in an open source project. It is interesting that the KDE people mention that the fixes from Apple are more like hacks that break other things. This is _exactly_ the same as what happens with GCC. Always quick hacks to pass some benchmark or validation suite, or to paper over real bugs in dreadful ways. Never any real, constructive co-operation. Somehow, Apple appears to be unable to work with a community, instead of against it.
In fact most -ftree-* options are turned on at -O1. At -O2 you get more sophisticated alias analysis and a few passes work harder to try and squeeze out some more optimization opportunities.
The differences between -O1 and -O2 for the RTL optimizers is much more significant.
Re:4.0.0 broke backward compatibility big time
on
A Review of GCC 4.0
·
· Score: 1
GCC 4.0.1 will fix a pair of bugs that make compiling KDE impossible. So in a couple of weeks your first point should be solved.
The other two points could be a bigger problem. On the other hand, all the major Linux distros are going with GCC4 for their upcoming releases, so at least the code shared between the BSDs and Linux (e.g. most of GNU iiuc?) should already be "GCC4-proof".
Re:Is anyone else curious what SSA trees are?
on
GCC 4.0.0 Released
·
· Score: 1
When you say "SSA form", my question is "SSA form for what?"
Single Static Assignment form in itself means nothing. Now, add the name of the intermediate representation to it. In GCC, that's GIMPLE, and the underlying data structures are called 'tree', from Abstract Syntax Tree node.
GIMPLE is the intermediate representation for function bodies that GCC will rewrite in SSA form. The proper name of GCC's SSA framework should be SSA for GIMPLE, but GIMPLE didn't exist when the tree-ssa project started. In fact there was not even a formal 'tree' based intermediate language at all. The first tree-ssa bits worked directly on the parse tree of the C front end. Only later a new source language independent and target machine independent intermediate representation was invented (first a rip-off of SIMPLE, used in McCat, later redesigned and "GNU-ified" to GIMPLE).
GIMPLE is lowered GENERIC. GENERIC is the language that the front ends target (i.e. C/C++/Fortran compile to GENERIC). The middle-end lowers GENERIC to GIMPLE, rewrites GIMPLE into SSA form, optimizes it, rewrites it out of SSA form, and from there the *cough* good old (target specific( RTL optimization framework takes over again.
There are in fact many many more companies selling support for GCC. The number of commercial GCC forks for embedded chips is simply huge. I know of at least a dozen companies selling GCC support. The most notable ones are of course Redhat, CodeSourcery, and Specifixinc, but there are many smaller ones, selling support for GCC for one or a fews weird embedded chips...
Re:"Paltry" is probably a poor choice of words
on
GCC 4.0.0 Released
·
· Score: 1
My understanding is that Apple uses a GCC 3.3 based compiler to build their distro, and GCC 4.0 is their "performance compiler", ie. something to pump out high SPEC scores with.
Re:GCC 4.0's biggest winner is probably KDE
on
GCC 4.0.0 Released
·
· Score: 2, Insightful
Well, it's a shame then, that GCC 4.0 cannot even compile KDE. It miscompiles it.
Maybe those core programs were not so excellent before they found wide-spread use via GNU/Linux. I have no historical data to back this up, but I would guess that very few GNU programs were actually used before Linux became popular (except the GNU tool chain of course).
Unless things have changed recently, their front end is derived from gcc 2.96 (which, as most of you know, does not actually exist), and their backend is the Pro64/Open64 Itanium compiler retargeted to AMD64. And Pro64 is itself mostly SGI's MIPSPro retargeted to Itanium. The PathScale team leader is also the former SGI MIPSPro compiler team leader (Fred Chow). MIPSPro rocks, and PathScale is also pretty good. The best part is that the compiler is GPL'ed (but only v2, and with a patent infringement clause that actually violates the GPL itself *sigh*),
See also this older LWN article for an explanation - kind of- of what SSA is: http://lwn.net/Articles/84888/
Re:Latest Fedora-development has gcc 4.0
on
GCC 4.0 Preview
·
· Score: 1
But the binaries are smaller if you use -Os. Most FC packages compile with -O2 and higher, and that means "compile for speed". Compile for size (-Os) is entirely different. See http://www.csibe.org/s-i686-linux.php for some nice graphs. The first data points are roughly GCC 3.4. The later ones are GCC 4.0. Ignore the final two data points, they are for GCC-4.1-to-be).
Re:More incompatibilities on the way?
on
GCC 4.0 Preview
·
· Score: 1
And you want to compile your legacy code with the latest-and-greatest compiler...why?
If you write code that is standard conforming, then GCC can compile even K&R C without trouble. If you rely on obscure, non-standard features, do not expect them to work. Your fault, not GCC's. Solution: Use an older GCC. They still work, you know.
Slashdot Mirror
Yes, but the difference is that on Itanium you can explicitly tell the CPU to rotate its register file. The result effectively is register renaming, and it can be used for software pipelining. See e.g. slide 7 of http://www.gelato.org/pdf/Workshops/geneva05/compi ling_itanium_muthu.pdf.
A better mod for the parent would be "shortsighted" instead of "insightful".
Maybe I should have said: "not a discovery of new facts" instead of "not news". Sorry to have stepped on your apparently long toes.
Anyone following the GCC maining lists knows this. It has come up many times there in the past few years.
The parent poster is wrong. IA-64's assembler syntax _has_ to be different from the AMD64 syntax because it is a totall different architecture with a completely different instruction set and many features that no x86* chips have. For example you need to mark bundles and add stop bits, and so on. So what the heck is the parent poster talking about. Flaimbite, if you ask me.
FWIW, the IA-64 assembler syntax (at least the form used by the GNU assembler) is much easier than all x86 and AMD64 assembly I have seen and worked on.
This is so true!
Add to that the near-total lack of participation and support from HP and Intel for third-party compilers, and you know why so few good IA-64 compilers (if any) exist.
The problem with Itanium is that it was hyped as the greatest thing since sliced bread. But when Merced ("Itanium 1" so to speak) was finally released to the market, two years after its originally planned introduction date, it was already outdated and being outperformed by competing CPUs including x86-based ones. Also, Merced was overpriced, was over-designed, produced more heat than the sum of all its competitors, and the market was still not ready for Itanium because specifications were released so late (even to NDA signers).
With over-designed, I mean it had way too many features that nobody would have cared about if Itanium would have been a success in its own right. Things like supporting ix86 on the chip; supporting HP-PA; supporting both big endian and little endian; supporting 32 bits pointers and 64 bits pointers (OK, the last one is perhaps useful sometimes, but still...).
To illustrate how bad the heat was: At the company I work for, in the south-east of Germany, we had an entire floor that didn't need heating in the winters -- each room had an Itanium work station and that was enough. In the summer those machines were turned off whenever possible.
Anyway, within a year after Merced, McKinley was released, and it was a huge jump forward compared to Merced when comparing heat consumption and performance. It was almost a competitive product, except for the price and the lack of easy hardware support for virtualization. Hell, it is not clear to me to this day what market Intel and HP were trying to attack, but it definitely was already a declining market at the time: Work stations (i.e. that market where Sun and SGI were performing so well in even then) and Big Iron, which is hardly a market large enough to sustain the huge development effort of Itanium.
By now, AMD64 was coming to the market as well, and it was cheaper, it was 64 bits, it had a great memory controler, and as a bonus it was backward compatible with the mainstream architecture of the day.
Now you make the business decision: What do you want to sell? Hot, underperforming, expensive Itanium-based machines for which no software exists? Or machines that are cheaper and which can run all the software on the market?
I know it has been said that Itanium is too difficult to compile for, and that GCC is to blame for the failure of linux-on-ia64. Or that Microsoft pulled the plug on Itanium when they decided to drop Windows-on-ia64. But if you see the market hype of the late 1990s and early 2000, 2001, Itanium was a hot topic and everyone was on that boat. In the end, it was Intel and HP trying too hard to make Itanium compatible with everything (which was never really possible, so what were they thinking?!) and initially not living up to their words about the performance potential of Itanium.
It is sad, because really if you look at it, there are some pretty good ideas in the Itanium.
The answer is in the text, from this doctor Nakashima, who appeared to be the only one around who was familiar with the symptoms of radiation disease.
The article says this (in part 4):
GCC produces no worse code for SSE than it does for AltiVec. And Apple doing anything right for GCC is another thing that will not happen until hell freezes over. Now, I'll have to admit that today proves it could happen. But given Apple's current totally failing GCC engineering efforts, it would surprise me even more than this Apple move today.
You're all wrong. For the low-level stuff Uli is talking about (glibc, GCC), supporting minority targets is troublesome even when the best of coding practices are put to use. For example for GCC it means that every optimizer change can cause a regression on ill-tested targets. In the past, silly bugs in the mighty IP2000 or AVR ports could block a GCC release for weeks, until the Release Manager decided that the regression wasn't important enough to block a release.
Uli's point that the complexity of software grows exponentially with the number of supported targets is also without doubt true. So from an engineering point of view it makes sense to support as few platforms as reasonably possible. If that means dropping AIX, Solaris, and other proprierary UNIX flavors, and leaving the maintenance of those ports up to the companies that are interested in maintaining those ports, makes absolutely perfect sense. Needless to say, the community should try to be helpful when there would be issues with such ports that require more than a maintenance effort to resolve (i.e. something in GCC is too ELF-ish but a port still uses COFF). But the burden of fixing latent broken things in poorly tested ports now resides with whoever post a perfectly valid patch that exposes the latent bug, and that is IMVHO Just Wrong.
I agree it is sad that there are projects that ignore warnings.
I don't think his comments have much to do with Uli being a RedHat employee or not. I am not a RH employee and I still agree with him on most (but certainly not all!) of the issues he raises in his rant.
Apple is just a lousy company to co-operate with in an open source project. It is interesting that the KDE people mention that the fixes from Apple are more like hacks that break other things. This is _exactly_ the same as what happens with GCC. Always quick hacks to pass some benchmark or validation suite, or to paper over real bugs in dreadful ways. Never any real, constructive co-operation. Somehow, Apple appears to be unable to work with a community, instead of against it.
In fact most -ftree-* options are turned on at -O1. At -O2 you get more sophisticated alias analysis and a few passes work harder to try and squeeze out some more optimization opportunities. The differences between -O1 and -O2 for the RTL optimizers is much more significant.
GCC 4.0.1 will fix a pair of bugs that make compiling KDE impossible. So in a couple of weeks your first point should be solved. The other two points could be a bigger problem. On the other hand, all the major Linux distros are going with GCC4 for their upcoming releases, so at least the code shared between the BSDs and Linux (e.g. most of GNU iiuc?) should already be "GCC4-proof".
When you say "SSA form", my question is "SSA form for what?"
Single Static Assignment form in itself means nothing. Now, add the name of the intermediate representation to it. In GCC, that's GIMPLE, and the underlying data structures are called 'tree', from Abstract Syntax Tree node.
GIMPLE is the intermediate representation for function bodies that GCC will rewrite in SSA form. The proper name of GCC's SSA framework should be SSA for GIMPLE, but GIMPLE didn't exist when the tree-ssa project started. In fact there was not even a formal 'tree' based intermediate language at all. The first tree-ssa bits worked directly on the parse tree of the C front end. Only later a new source language independent and target machine independent intermediate representation was invented (first a rip-off of SIMPLE, used in McCat, later redesigned and "GNU-ified" to GIMPLE).
GIMPLE is lowered GENERIC. GENERIC is the language that the front ends target (i.e. C/C++/Fortran compile to GENERIC). The middle-end lowers GENERIC to GIMPLE, rewrites GIMPLE into SSA form, optimizes it, rewrites it out of SSA form, and from there the *cough* good old (target specific( RTL optimization framework takes over again.
There are in fact many many more companies selling support for GCC. The number of commercial GCC forks for embedded chips is simply huge. I know of at least a dozen companies selling GCC support. The most notable ones are of course Redhat, CodeSourcery, and Specifixinc, but there are many smaller ones, selling support for GCC for one or a fews weird embedded chips...
My understanding is that Apple uses a GCC 3.3 based compiler to build their distro, and GCC 4.0 is their "performance compiler", ie. something to pump out high SPEC scores with.
Well, it's a shame then, that GCC 4.0 cannot even compile KDE. It miscompiles it.
Maybe those core programs were not so excellent before they found wide-spread use via GNU/Linux. I have no historical data to back this up, but I would guess that very few GNU programs were actually used before Linux became popular (except the GNU tool chain of course).
Actually, a substantial part of the new C++ parser in 3.4 was rewritten again for 4.0.
Unless things have changed recently, their front end is derived from gcc 2.96 (which, as most of you know, does not actually exist), and their backend is the Pro64/Open64 Itanium compiler retargeted to AMD64. And Pro64 is itself mostly SGI's MIPSPro retargeted to Itanium. The PathScale team leader is also the former SGI MIPSPro compiler team leader (Fred Chow). MIPSPro rocks, and PathScale is also pretty good. The best part is that the compiler is GPL'ed (but only v2, and with a patent infringement clause that actually violates the GPL itself *sigh*),
See also this older LWN article for an explanation - kind of- of what SSA is: http://lwn.net/Articles/84888/
But the binaries are smaller if you use -Os. Most FC packages compile with -O2 and higher, and that means "compile for speed". Compile for size (-Os) is entirely different. See http://www.csibe.org/s-i686-linux.php for some nice graphs. The first data points are roughly GCC 3.4. The later ones are GCC 4.0. Ignore the final two data points, they are for GCC-4.1-to-be).
And you want to compile your legacy code with the latest-and-greatest compiler...why? If you write code that is standard conforming, then GCC can compile even K&R C without trouble. If you rely on obscure, non-standard features, do not expect them to work. Your fault, not GCC's. Solution: Use an older GCC. They still work, you know.
No, propolice is something entirely different. That's a stack smashing protector. Mudflap is a bounded pointers implementation.