Mark Mitchell announced the availability of GCC 3.4.1. Mark explains, “there are no new features in this release, but there are a lot of improvements for various languages and architectures.”
GCC 3.4.1 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Why don’t you ask the guys who wrote the current python & ruby implementations if they could write a compiler?
GCC is mainly intended for “industry standard” languages, and the C dialects seem quite widely spread.
PLUS: python and ruby are supposed to be mainly scripting languages, i.e. compiling stuff wouldn’t make much of a difference for their intended audience.
Why would you want to compile something that is *MENT* to be interpreted at run-time?
Has anyone tested this feature yet? Are there any benchmarks that compare compile time for different software with and without precompiled headers?
Why would you want to compile something that is *MENT* to be interpreted at run-time?
Why is there GCJ?
There is gcj because Java is _very_ widely used, and because Java is more of a static language than Python or Ruby.
Also, Java’s original implementation is not open-source, that’s why GNU chose write their own I suppose.
Python is open-source, and of course they are free to add any amount of compilation (or runtime translation+optimization) they like, they just didn’t until now (but there’s Psyco).
There’re no plans to compile Ruby code ‘cos the language is design to be dynamic, and blurs the line between compile-time and run-time.
There’re two projects for creating a Ruby bytecode interpreter.
One’s Ruby2 Rite, the other’s Parrot, currently being develop for running Perl6 bytecode, but can be use for Python and Ruby as well.
To all of the people who work on this project, I want to give a big ‘hats off’ thanks!!!
Relentless in your work you are, and without your ‘ware, the free software (BSD as well as GPL) would still be in the dark ages.
Are there any experiences compiling linux kernel yet? Last time I checked it was not quite possible…
I built my running kernel (2.6.7) with GCC3.4, and it runs flawlessly.
“Why would you want to compile something that is *MENT* to be interpreted at run-time?
Why is there GCJ?”
Because Java is not interpreted. What is next are you going to complain ’cause there is no Perl support either?
Stay in school kiddo, your troll skills are lacking.
asking for python support is ridiculous 🙂
i’m taking my hat off fot the deep magicians who wrote a compiler that enables me to use so many different packages of software!
java source code is meant to be compiled, albeit compiled for a very specific machine architecture. it just so happens that pretty much noone owns a machine capable of running java natively and so it has to run in a virtual machine (which is by design for java anyway)
@Roman
…they still develope that thing? Call me when they finally get around to make it compile Ruby and Python…
Without GCC Python and Ruby can’t be compiled :]
> it just so happens that pretty much noone owns a machine capable of running java natively and so it has to run in a virtual machine
I’m really confused by that statement… “noone owns a machine capable of running java natively” … what does that mean?
He means that you need the VM to run Java bytecode since bytecode is different from native machine code.
>He means that you need the VM to run Java bytecode since bytecode is different from native machine code.
I read his statement of:
————–
It just so happens that pretty much noone owns a machine capable of running java natively and so it has to run in a virtual machine
————–
As though their _is_ a machine capable of doing just that (when he says “pretty much noone”, assuming their is a few elect that “do” own a machine capable).
Is he getting the GCJ confused with the JVM???
There exist processors that are designed to run Java bytecode. Don’t think anyone has actually tried to clobber up a PC from them though.
…they still develope that thing? Call me when they finally get around to make it compile Ruby and Python…
Without GCC Python and Ruby can’t be compiled :]
Aw shucks, spoiled again. But on a positive note: I learned something new today.
Stay in school kiddo, your troll skills are lacking.
I’m still learning.
no-one, nobody, no person, owns a machine that can run java byte-code as it’s native machine code. Java requires a Virtual Machine – a processor implemented in software – to run it’s bytecode. Modern Java VMs are little more than just-in-time compilers that compile the bytecode to the particular processors machine code on the fly
To the folks who want GCC to compile scripting languages:
GCC is used to compile the Python, Ruby, and Java interpreters – I belive they’re written in C or C++.
It’s then the job of these binary interpreters to interpret their respective .py, .ruby, and .java source files.
Back to the topic at-hand: the GNU *Compiler* Collection 3.4.1. I was able to build it on Sparc64, x86 (AthlonMP), and x86-64 (Opteron) architectures. Here are my config lines:
$ grep name /proc/cpuinfo
model name : AMD Athlon(tm) MP 1900+
model name : AMD Athlon(tm) Processor
$ gcc -v
Reading specs from /export/pkg/lang/gcc-3.4.1/bin/../lib/gcc/i686-pc-linux-gnu/3.4.1/spec s
Configured with: ../gcc-3.4.1/configure –enable-shared –enable-threads=posix –disable-checking –enable-__cxa_atexit –enable-languages=c,c++,f77 –prefix=/pkg/lang/gcc-3.4.1 –enable-g2c
Thread model: posix
gcc version 3.4.1
$ grep name /proc/cpuinfo
model name : AMD Opteron(tm) Processor 242
model name : AMD Opteron(tm) Processor 242
$ gcc -v
Reading specs from /pkg/lang/gcc-3.4.1_64/lib/gcc/x86_64-unknown-linux-gnu/3.4.1/specs
Configured with: ../gcc-3.4.1/configure –prefix=/pkg/lang/gcc-3.4.1_64 –enable-shared –enable-threads=posix –disable-checking –enable-__cxa_atexit –enable-languages=c,c++,f77 –enable-g2c –disable-multilib
Thread model: posix
gcc version 3.4.1
Sparc64, gcc -v:
Reading specs from /home/kcroft/local/gcc-3.4.1/lib/gcc/sparc-sun-solaris2.8/3.4.1/specs
Configured with: ../gcc-3.4.1/configure –with-tune=ultrasparc3 –with-float=hard –enable-threads=posix –prefix=/home/kcroft/local/gcc-3.4.1 –enable-languages=c,c++,f77 –enable-shared -enable-g2c
Thread model: posix
gcc version 3.4.1
It’s then the job of these binary interpreters to interpret their respective .py, .ruby, and .java source files.
No one interprets .java source files. At least no one I know off 😉
But I’m curious about gcc 3.4 on the Opteron. Do the generated binaries run faster? I know gcc 3.4 adds the -march=k8 option and it would be interesting to know how much additional performance this flag brings.
“I’m really confused by that statement… “noone owns a machine capable of running java natively” … what does that mean?”
This means that normal processors only execute other opcodes, like x86 code, or PowerPC code.
The JVM defines its own machine language which can be translated to other machine languages (by JIT-compilation or static compilation) or interpreted on other machines.
I differentiate compiled vs. interpreted be the following:
compiled code runs directly on the hardware, not another layer of software.
Interpreted code runs one one or more layers of software.
The Java Virtual Machine is compiled and runs on the hardware, ‘java binary programs’ ride on the virtual machine and are therefore interpreted (my definition anyway.. it’s all semantic if we take it from there)..
I think some of these lines are blurring, for example cell phone manufactures using a firmware virtual machine – which is cool. Eventually there will be Java CPU which will do away with the VM.
As for native 64-bit builds on the Opteron; we’re seeing between a 40% and 60% speedup of our scientific codes over 32-bit builds.
There are Java CPUs, for example ARM processors with the Jazelle extention.
But it seems much more practical to have an open architecture, that can run C (and other languages) as well as Java (like most archs do). A JVM-only CPU would be horrible IMHO.
People who want/need static compilation can just use gcj or tweak a normal JIT-java runtime to dump its compiled code.
[quote]no-one, nobody, no person, owns a machine that can run java byte-code as it’s native machine code. Java requires a Virtual Machine – a processor implemented in software – to run it’s bytecode. Modern Java VMs are little more than just-in-time compilers that compile the bytecode to the particular processors machine code on the fly[/quote]
Wrong. SUN developed and sold (maybe even still sell) Java CPUs. The native micro-code for the CPU was Java bytecode. They even developed and sold a thin-client computer based around this called the JavaStation. It ran a Java-based OS, but never really took off.
> There are Java CPUs, for example ARM processors with the
> Jazelle extention.
– thanks for the heads up, I just read about it here http://www.arm.com/products/solutions/Jazelle.html.
> But it seems much more practical to have an open
> architecture that can run C (and other languages) as well as > Java (like most archs do).
I agree; having compilers and VM’s do the work of producing architecture-specific machine instructions from artchitecture independent languages allows for cross platform computing.
> A JVM-only CPU would be horrible IMHO.
Yes, people writing compilers would then have to parse C, C++, Fortran only to produce Java-byte-code; aaaiieeee, over the cliff of nonsense we go!
It means that there is no computer that understainds java in it’s “hardware”…
I would say that SUN has a processor that runs java bytecode nativelly (not sure if it’s hardware implement everything either).
But for sure that a CPU like the transmeta ones can be “taught” to run java bytecode… (not sure if it has internal memory to “morph” the whole JVM).
i love being misquoted
anyway to clarify (which several have already done quite a good job at this)
java source code is meant to be compiled into java bytecode. java bytecode is intended to run on a “java computer” just like most people on this website run an “x86 computer” or a “ppc computer”. sun has made several cpus which run java bytecode natively, however these are not widespread (but they DO exist, sun’s mcnealy made a big deal out of pimping one he had built into a ring on his finger during a tech show several years back).
all a JVM is, is a “java computer” emulator running on top of your “x86 computer” or your “ppc computer”. it is just like playing old nintendo roms on your pc, you are emulating the hardware that they need to be able to run.
Languages aren’t “meant to be interpreted” or otherwise. Python could be compiled just as easily as any other language, just as easily as C could be interpreted. Dynamic/static has nothing to do with it — highly static languages like ML can be interpreted, and highly dynamic languages like Smalltalk are often compiled. It’s simply a matter of a different set of compilation techniques.
“Python could be compiled just as easily as any other language, just as easily as C could be interpreted.”
Thanks I needed the laugh….
I’m told that PCH for IA-32/i386 systems is not good. Wait for GCC 3.5 for better support.
C’mon, don’t be so hard on yourself. You don’t have to laugh at your own ignorance!
any language that contains an exec(string programcode); function cannot be compiled (without the compiled executable including a copy of the entire compiler of course).
The ignorance of some of you people is breathtaking.
With gcj (part of the gcc suite the article talks about) you can compile Java source code directly into a native binary. This no different from converting C, C++ etc. … into a native executable. Also, with gcj you can mix ahead-of-time code with just-in-time bytecode. Very cool work by the gcc/gcj crowd.
Check out this month’s Linux Journal for an article on native compiled Eclipse (http://www.linuxjournal.com/article.php?sid=7413). I belive it can also be compiled to native on Win32 as well
nb. .NET requires a runtime too, so who cares if someone needs a VM. And .NET can also be ahead-of-time-compiled. The difference between .NET and Java of course is that Java is platform-agnostic (.NET implementations don’t have *full* library support for any platform other than Windows).
any language that contains an exec(string programcode); function cannot be compiled
Sure it can. There are tons of compiled languages that have eval().
(without the compiled executable including a copy of the entire compiler of course).
In highly-dynamic languages (Python, Lisp, Smalltalk), it’s very useful to have the compiler at runtime anyway. It allows for some very cool optimization/extension possibilities. Since the compiler is already written, it’s trivial to package it as a shared library that’s dynamically loaded by the application. Hell, you can do it yourself for any C program (see libtcc). Anyway, as I originally said, it’s not any harder to compile Python than it is to compile a static language like C or Java.
Partition your problem space intelligently. For the pieces that are known at compile time, use boost::python and write in C++, then just import into a python script for the dynamic pieces.
See http://www.boost.org for detail.
“Anyway, as I originally said, it’s not any harder to compile Python than it is to compile a static language like C or Java. ”
And again just because youse say it it doesn’t make it so. Thanks for the laughs anyways, the compiler as a shared library was a classic. Cheers to you!