Slashdot Mirror
GCC 4.0.0 Released
busfahrer writes "Version 4.0.0 of the GNU Compiler Collection has been released. You can read the changelog or you can download the source tarball. The new version finally features SSA for trees, allowing for a completely new optimization framework." The changelog is pretty lengthy, and there's updates for every language supported from Ada to Java in addition to the usual flavors of C.
Glad to see they are targeting the AMD64 architecture for improvements.
Single static assignment is a way the compiler can rewrite the code (usually for optimization purposes) so each "variable" being analyzed is only written once. This makes a lot of optimizations easier to do, since it eliminates aliasing due to the programmer assigning different values to the same variable. You'd probably learn these things if you would RTFA.
Static Single Assignment, optimization techniques. Try here for more details.
To put it simply, SSA is an intermediate representation where each variable in a block is defined only *once*. If a variable is defined multiple times, the target of any subsequent definitions of the same variable is replaced by a new variable name.
SSA helps to simplify later optimizations passes of a compiler (for example: eliminating unused definitions, etc) as described in greater detail (with examples and flowcharts) in the article linked to.
That's the SSA form in short. Now I need to ask somebody the difference between the standard SSA form and "SSA for trees".
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
I can't wait to figure out what will (won't?) build with GCC 4.0.0. (One thing's for sure... JDK and OOo won't.)
FYI: Red Hat has a guy working full-time on building OOo on GCJ. His blog.. Not that everything works straight out-of-the-box. But it's not like nothing works either.
(And from what I've heard, you can't expect it to work out of the box either. Sun's coders have done a terrible job and adding all kinds of dependencies on undocumented Sun-internal classes. So it probably doesn't work on Apple's JDK either, and that one is Sun-approved!)
Try SBCL, CMUCL, GCL, or CLISP. They're all good Lisp implementations. SBCL and CMUCL compile to native code directly and are probably the fastest free CL implemetations, GCL compiles via C (and therefore GCC), and CLISP has a bytecode interpreter.
When they announced the release of Apple 10.4 "Tiger" I noticed this page: At that point I kinda figured gcc 4.0.0 had to be out by April 29th since Apple claimed they were using it for OS X.
Well, you're wrong because GCC doesn't follow Apple's schedule, or anyone else's for that matter. Even a cursory glance at the GCC mailing list will tell you that.
The reason Apple can promise this is that they're not actually shipping GCC 4. They're shipping their own fork of the GCC 4 code. It's probably about 99% the same code, but don't make the mistake of thinking they're shipping exactly what the FSF is distributing.
The parent poster is refering to the deprecation of Managed Extensions for C++ syntax in favor of C++/CLI (which is undergoing ISO standardization).
While it is true the syntax has changed (much for the better: templates are now supported in managed C++ code and so are generics, keywords replace ugly __gc, and more), support for the old syntax is still in the compiler (/clr:oldSyntax), and IntelliSense.
However, you will be unable to mix new syntax and old syntax code in the same project without taking some penalties (IntelliSense will break, at the least). The designer will even spit out old syntax code when designing an old form or control.
While the old syntax is definitely on its last legs, the VC++ team was very concerned about not screwing over those (early) adopters of C++ code for the CLR thus far.
A good resource to read up more on the subject would be Herb Sutter's Blog, Stan Lippman's Blog, or any of the other VC++ team member's blogs.
Take this from a former VC++ teammate who left during the Whidbey product cycle (posting AC since I've never bothered to get a slashdot account).
Trying to recall my knowledge of optimizing compilers:
SSA makes optimization easier, since it is obvious where a variable was assigned (since it was assigned in only one location) and what value it contains (since there is only one value being assigned to it). The complexity moves to register allocation, where there can be many more variables to allocate because of SSA. Register allocation is Hard, but doing an ok job is quite possible. Most optimizations are impossible unless you can prove various properties about the variables involved, which is often much easier with variables in SSA form.
Whoever corrects a mocker invites insult;
whoever rebukes a wicked man incurs abuse.
--Proverbs 9:7
Fedora Core 4 is GCC 4.0
Hmm. Funny. Seems like perfect timing, in retrospect. I just held a presentation on SSA (and efficiently transforming code into SSA) today.
Get the slides here.
HTH
Most linux distributions being built for i386 is mostly incorrect and when not, a half-truth.
Fedora Core, for example, relies on the improved instructions for atomic operations found in 486 and newer processors, necessary for certain threading libraries. The rpm program itself requires a 586, if I don't remember wrong.
Fedora Core also compiles all binaries optimized for P4. It was decided to use P4 optimizations, since these generally work just as well on Athlon processors, while Ahtlon optimizations is rather slow on a P4.
Furthermore, for CPU intensive applications such as many audio and video applications, CPU optimizations such as MMX and SSE are automatically activated at runtime if the CPU supports it.
The 'i386' in the name should really be called 'x86'. Of course, then there's also 'i686' packages, which basically mean 'x86 processors that support the CMOV instruction'. That is also wrong, as there are i686 processors which do not support CMOV, such as certain VIA and Cyrix variants.
CMOV is basically the only useful addition to the x86 instruction set since the i486 for general purpose programs. And programs not fitting into that category, already have hand written asm for time critical sections, which can take advantage of MMX, SSE, 3DNow, Altivec or VIS.
due to the fact that all its c++ shared libraries will now be 40% smaller due to the symbol visibility improvements (i.e., no runtime adjustment needed by the linker for internal-only functions). This translates into a significant speed improvement for all KDE code.
There have been several good answers to your question, but if you're really new to compilers, you might want a little more context. Want a quick lesson in how compilers work? If you're willing to accept some gross oversimplifications, here's how most modern compilers work:
1) Tokenize the input. For example, if you were compiling perl, you might choose to turn "print $foo" into three tokens; KEYWORD_PRINT, TYPE_SCALAR, and IDENTIFIER('foo'). The output is typically a stream of tokens. This step might be done by lex or flex.
2) Parse the sequence of tokens using a set of rules called a grammar. For example, "TYPE_SCALAR" followed by "IDENTIFIER()" is might match a rule to generate a variable called "$foo", and "KEYWORD_PRINT" followed by a variable means call the function print on the contents of the variable. The output is typically an abstract syntax tree (AST); a high-level data structure representing the program. This step might be done by yacc or bison.
3) Match the AST against a series of rules to output the final code. This might actually be two steps; you might generate something into a low-level register transfer language (RTL) that looks very much like assembly, and then turn THAT into actual machine instructions.
At each stage, you might choose to optimize the output. You might also insert optimizations passes between steps. (For example, you might insert a pass between 2 and 3 to optimize the AST into a simpler AST.)
Before SSA, GCC sort of skipped making any high-level AST; it used to go from parsing almost immediately into a RTL. You can still optimize RTL, but since it's pretty low-level, it misses out on higher-level context and made some optimizations really difficult.
SSA is simply a form used for the high-level AST. Why SSA? It is a very nice form to optimize. Read the wikipedia article for more details on why SSA is particularly useful for some optimizations.
Page 181 of this PDF file from the 2003 GCC Summit explains the flow of the GCC compiler.
They mean this patent owned by this company. What a surprise.
Debian has had pre-releases for 4.0 for a while now. I guess you'd know that if you were a developer and actually used Debian. Hell I have mono 1.1.6 on Debian -- not many distros even have that yet. =)
Let's say that Apple has 99.9999999% of all desktop installs. Even then, almost none of them actually use GCC.
Mac OS X itself is compiled with GCC 4. That was the point. Hence, all Mac users depend on GCC 4. That's 40 million and counting according to the latest figures.
Wrong. The SSE instruction set includes several instructions for doing vector integer ops, such as average and multiplication. These things are a huge speed win even in "average" applications, as the game compiler developer noted above. If you don't believe me, fire up a profiler and look at how much time an office app or web browser spends doing rectangle intersection calculations and TrueType font math.
Also, there aren't nearly enough people using MOVNTDQ to avoid polluting the instruction pipeline and dumping useless garbage into the system cache. If you're copying stuff into main memory and you aren't going to use it for a while, use MOVNTDQ to get a big speed win. If you do need it cached, use MOVDQA to get both caching and 128 bit transfers in one instruction! We all paid for these fancy schmancy new instructions in our processors, and it's extremely annoying to see programmers not use them.
-- thalakan
According to http://gcc.gnu.org/install/specific.html#powerpc-
i.e. you're using a forked version of GCC, and definitely not 4.0.0 out of the box.
the whole notion of "a fork" runs 100% counter to all that open-source stuff
No, actually, the importance of the ability to fork and wisdom to know when to fork is very important to "that open-source stuff".
Yes, gcl (formerly known as kyoto common lisp). But it doesn't need the assembler/linker part of the toolchain so it's packaged separately. But I think it is "Part of the GNU Compiler Collection", for what that's worth, and it does depend on GCC.
All's true that is mistrusted