ksattic (+1.5)
21/3/04 6:30PM |
GCC is easily one of the most important ongoing projects for RISC OS because so much other software just wouldn't exist without it. Thanks are due to the developers for all their kind work. |
pipalya (+1.5)
21/3/04 9:55PM |
What implications has this for already
existing software? |
mrchocky (-1.0)
21/3/04 10:30PM |
In reply to pip:
I don't know what you mean. Implications of GCC 3.3 on software? That they're able to be compiled with a newer compiler? |
wuerthne
21/3/04 10:46PM |
In reply to pipalya:
I think you misunderstood what ksattic meant: The existence of GCC, a free compiler, enables software authors who could not afford the commercial C compiler to write software, so because of that, as ksattic wrote, much other software would not exist without it. A new version of the compiler has no implications for existing software, how could it?
Martin |
rmacf
22/3/04 12:33AM |
As a non-techie I wondered the same thing as Pipalya. Does this upgrade make it easier to re-write existing programmes, to make them compatible with 32bit systems, any easier?
BTW could you contact me please Pipalya? |
simo (+1.5)
22/3/04 6:30AM |
Nice to see 32-Bit and ELF in a "standard" gcc3 version, rather than three seperate releases. |
mrchocky (+1.5)
22/3/04 8:54AM |
rmacf: the situation is precisely as Martin has said. There's nothing made "easier" or anything new you can do, it's just a newer version of compiler (although that's significant enough by itself). I don't know why you'd suggest anything would have to be re-written.
In reply to simo:
You've oversimplified the matter. There was only one "release" of GCC 3.3 - previous versions were simply developmental versions.
As for 32-bit, it's been pretty crucial, and there would have been a lot of problems had a 32-bit version of 2.95 not been made.
The GCC 3.3 release doesn't contain any more ELF support than the previous 32-bit 2.95.4 GCC - i.e, just the assembler. The full ELF toolchain I did (which was an experimental version, and not a "release"), was done to demonstrate that full ELF support on RISC OS is possible. It's however, of limited usefulness until it can interact with AOF object files.
It's not uncommon on Linux systems to have 2 or 3 versions of GCC installed. |
mrtd
22/3/04 8:55AM |
macf: As a non-techie I wondered the same thing as Pipalya. Does this upgrade make it easier to re-write existing programmes, to make them compatible with 32bit systems, any easier?
No, but it adds some features that may be useful to programmers writing new programs. In some cases it will make porting programs from other platforms easier where the new compiler features have been used. It does nothing for converting 26 bit ARM programs to 32 bit.
|
JGZimmerle (-1.0)
22/3/04 9:43AM |
And it should provide a nice speed-up of programs wich are recompiled with the new GCC, because the new ARM backend in GCC 3.x generates much faster code. |
bernie
22/3/04 10:45AM |
I am a non-techie too, but I seem to remember a number of project/ports that can't be done with old versions of (RISC OS) GCC because of (lack of) threading. Am I right? |
em2ac
22/3/04 1:24PM |
"There also exist front ends for other languages, such as Objective C, Ada 9X, Modula-3, Pascal, Cobol and Java, however these have not been ported to run on RISC OS."
Damed shame, I like using Java!
But mostly Good Work  (Y)! |
mrchocky (+0.5)
22/3/04 1:43PM |
Right, I've just run some benchmarks using nbench with the two compilers.
The result? There seems to be a very marginal speed increase in the 3.3 compiler. No doubt there are some cases where the code is much better, but those might be pretty limited.
The output from GCC for ARM is actually pretty good, so I would be surprised at overall substantial improvement. Having said that, the output from optimising for XScale or StrongARM may well show marked improvement.
Moral of the story: please check your technical claims. |
jonix (+1.5)
22/3/04 3:48PM |
've played a bit with the pthreads support in Unixlib and it's coming on very nicely. A big thanks to all involved. |
imj (-1.5)
22/3/04 6:34PM |
FWIW, Chocky, you also didn't provide any "evidence or justification" for your statement that the speed improvements were only marginal. |
piemmm (-1.5)
22/3/04 7:13PM |
Interest rates can go down as well as up  |
NoMercy (+1.5)
23/3/04 12:22AM |
Wow, that's almost freaky, I picked out an old acorn user issue, which had a few news articles about the GCC effort and ROL looking into aquiring the C++ compiler from ARM, and then I flick onto Drobe the next day, and wooo new GCC version... ok my life is shallow and without meaning, but woo new GCC version! |
adrianl (+1.5)
23/3/04 1:54AM |
"StrongARM binaries will be faster on an XScale than ARM6 ones"
If that means that the compiler knows about load-use delays and tries to schedule instructions between an LDR Rd,[] and any use of Rd then yes.
IIRC unexecuted LDM/STMs are also cost more than 1 cycle on SA so knowing that can also improve performance on the XScale.
Of course, that's knowledge of the SA/XScale's performance characteristics rather than usage of new instructions, but I think that's by far the greatest benefit to be had. Some small improvement may also be gained be use of halfword loads/stores which are new to post-ARM6 CPUs but most of the other new instructions are not really useful to a compiler. |
quatermass (-1.5)
23/3/04 11:41AM |
Hmmm, the image of two cats on both sides of a fence comes to mind..... |
philipnet (-1.5)
23/3/04 11:56AM |
bored now. |
not_ginger_matt (-1.5)
23/3/04 12:02PM |
If you take a few moments out from attempting to beat down JGZimmerle and making yourself look really rather childish, you'll notice that you've also often used a "poor choice of words". I believe there's some moral about people in glass houses throwing stones that you might like to look up.
On one hand you say that "It's certainly true that GCC 3.3 will generally generate faster code" and then after running some benchmarks you still say "No doubt there are some cases where the code is much better". Of course, later on you can't resist another mindless attack on JGZimmerle and rant on how it's impossible to say that the compiler is ever "much faster". Not content with this you say that this is "plainly clear to everyone" even though it didn't appear to be clear to you prior to that post.
Of course, no personal feud (as this appears to be what we are witnessing) would be complete with out at least a small helping of hypocrisy. So, all I ask is "Please don't go round making these statements without justification", and when you run some tests to demonstrate that your current stance is correct then at least provide the results or the compiler options you used to get them. Simply saying that there is "a very marginal speed increase" negates your "Scientific method" and really doesn't really help anyone out.
Feel free to consider this a "Peer Review". |
mripley (-1.5)
23/3/04 12:05PM |
It's all very defensive, why ? is there some toe treading going on here that we're missing. Or is it simply a case of "I'm always right all the time and I'll argue forever until you all agree with me".
When my kids behave like this, its no more sweeties time |
| 9 comment(s) are below your moderation threshold. Login to view them. |
| Use the forum for more comments on this article |
A public pre-release version of GCC 3.3.3 is now available from the 
