GCC 3.3.3pre1 released | Drobe.co.uk archives

GCC 3.3.3pre1 released

By Chris Williams. Published: 21st Mar 2004, 17:58:34 | Permalink | Printable

Biggest official release in two years

A public pre-release version of GCC 3.3.3 is now available from the GCC for RISC OS website. The project considers this release to be "stable enough for general use but may contain a few rough interface edges that need polishing". It's also described as the biggest, official update to RISC OS GCC in two years.

On this weekend's release, project manager Nick Burrett commented: "Though this is a pre-release, the compiler toolset should be considered stable."

The GCC package includes a C/C++ and Fortran 77 compiler as well as an assembler, a linker and the standard run-time libraries, plus Libio, Libstdc++ and a pre-release of UnixLib 4.0. Also available is the GCCSDK, which is useful for cross compiling RISC OS executables on Linux, BSD and other Unix-like systems. GCC 3.3.3pre1 requires at least 8M of memory to work and by default will generate 32bit compatible code. Users who want to follow the progress of the project or submit feedback are encouraged to join the project's mailing list.

The weekend's release of GCC for RISC OS brings the project in line with the mainstream current release of GCC, the popular compiler package developed by the GNU. As well as the changes made to the mainstream version, the RISC OS version also now includes threading support (pthreads), emulation of /dev/random and /dev/zero, improved C99 standard compatibility, ELF support in as and various other updates to UnixLib and other components.

Links

GCC for RISC OS website - official pre-built packages, CVS details, GCCSDK, etc.
Unofficial GCC builds from riscos.info - ELF executable generating GCC for RISC OS and a 32bit GCC 2.95.4 GNU's GCC website - changes and features new to 3.3.3

Previous: Software news
Next: GAG-News celebrates 12th birthday

Discussion

Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

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.

ksattic on 21/3/04 6:30PM
[ Reply | Permalink | Report ]

What implications has this for already existing software?

pipalya on 21/3/04 9:55PM
[ Reply | Permalink | Report ]

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?

mrchocky on 21/3/04 10:30PM
[ Reply | Permalink | Report ]

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

wuerthne on 21/3/04 10:46PM
[ Reply | Permalink | Report ]

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?

rmacf on 22/3/04 12:33AM
[ Reply | Permalink | Report ]

Nice to see 32-Bit and ELF in a "standard" gcc3 version, rather than three seperate releases.

simo on 22/3/04 6:30AM
[ Reply | Permalink | Report ]

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.

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.

mrchocky on 22/3/04 8:54AM
[ Reply | Permalink | Report ]

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.

mrtd on 22/3/04 8:55AM
[ Reply | Permalink | Report ]

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.

JGZimmerle on 22/3/04 9:43AM
[ Reply | Permalink | Report ]

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?

bernie on 22/3/04 10:45AM
[ Reply | Permalink | Report ]

JGZ: Careful. Please don't go round making these statements without justification. It's certainly true that GCC 3.3 will generally generate faster code, but I've seen nothing (yet) to backup "much faster". Someone's welcome to make some benchmarks or point to references to back this up.

bernie: Yes, there is has been considerable pthreads support added since the last official release. However, this support is in Unixlib, so is also present in the 32-bit 2.95.4 version. The number of potential ports that use threading is actually very small.

mrchocky on 22/3/04 11:05AM
[ Reply | Permalink | Report ]

"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)!

em2ac on 22/3/04 1:24PM
[ Reply | Permalink | Report ]

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.

mrchocky on 22/3/04 1:43PM
[ Reply | Permalink | Report ]

've played a bit with the pthreads support in Unixlib and it's coming on very nicely. A big thanks to all involved.

jonix on 22/3/04 3:48PM
[ Reply | Permalink | Report ]

I had checked my technical claims. As you suggested yourself, if optimising for StrongARM or XScale there is a noticible speedup. Why should one not optimise for modern processors? One can always provide a second binary file for older processors as well and do the selection wich one to use at run-time.

JGZimmerle on 22/3/04 5:37PM
[ Reply | Permalink | Report ]

JGZ: oh dear. No, you didn't check at all (this is a common theme with you). You didn't offer any evidence or justification for your claims, and you don't seem to have run any benchmarks. All you said was that it was "significantly faster", which clearly isn't true.

Futhermore, had you researched this a little, you would know that in fact, some of improvements for StrongARM cause XScale to slow down, and vice versa. GCC's default output is targetted to ARM6 level, which means code runs sensibly on all RiscPCs and later machines.

I'm not even sure how much difference targetting to these other processors will make on RISC OS - I do have some figures in mind from other OSes, but again, it's not something I will suggest without actually checking.

mrchocky on 22/3/04 6:11PM
[ Reply | Permalink | Report ]

FWIW, Chocky, you also didn't provide any "evidence or justification" for your statement that the speed improvements were only marginal.

imj on 22/3/04 6:34PM
[ Reply | Permalink | Report ]

I did provide justification - the benchmarks, and I'm happy to provide evidence if asked. What's your point?

On a different note, where the speed improvements _may_ be significant are for C++, since this has had substantial changes. But then again, it may not.

mrchocky on 22/3/04 6:50PM
[ Reply | Permalink | Report ]

Interest rates can go down as well as up ;-)

piemmm on 22/3/04 7:13PM
[ Reply | Permalink | Report ]

Well, binaries optimised fpr StrongARM will in most cases be faster on XScales than binaries optimised for ARM6. But of course you could also make three binaries: one for ARM6, one for StrongARM and one for XScale. Since RISC OS programs are quite small anyway, this would not be a problem, you could still fit hundreds of them onto a CD (for commercial apps) and most users have fast internet connections anyway these days, so it would also not be problem for people who download the software.

And I never said "significantly faster".

I kind of get the feeling that you are trying to damage my reputation. You have no way of knowing wether I checked my facts. You only know that I didn't provide evidence to back up my *opignion*. And to be honest I have better things to do than to argue with you about such trivial things, so I can tell you right now that I will not take the trouble to back my claims up. And concerning benchmarks: One can prove just about anyting with benchmarks. Just pick the right one and set the right compiler options and you should get the results you wanted.

And just in case you come round with the "this is technical discussion" argument again: I do not consider this level of discussion to be "of a technical nature". IMHO such terms are reserved for in-depth discussions of high-frequency electronic and digital IC technology (not sure these are the correct english terms for what I mean) and similar things.

Anyway, I've had just about enough of this kind of "discussions", so I have a feature request for drobe: Could you please implement some kind of ignore list list function, wich lets me create a set of users whos comments and forum articles will not be displayed to me?

JGZimmerle on 22/3/04 11:36PM
[ Reply | Permalink | Report ]

Uh oh, you're on a paranoid trip now. Probably no matter what I say, you'll presume it will be some kind of attack against you.

No, Julian. You've done plenty to damage your own reputation. My interest is simply to make the situation clear to the RISC OS public. You're right, I did slightly misquote you, but with almost the same meaning.

I've given many, many opportunities to back up things which you've said - but you've declined to do so. If you post misleading information, then it is not at all surprising that someone will correct you, or ask you for at least some kind of proof. It's only yourself you can blame for that.

I'm not sure how opinion comes into these things - for example, you claimed elsewhere that the Omega has a later Southbridge than the Iyonix - your opinion has little to do with this - in fact, you had only to open your machine to see if this was true or not.

And yes, I _do_ consider compilers a discussion of a technical nature. They are one of the most complex programs you can write. They are _extremely_ technical.

As for the issue which sparked this off - it's simply unacceptable for you to say something is "much faster" without any kind of proof _whatsoever_ - again, which I gave you plenty of opportunity to present. If you want to demonstrate some instance in which GCC 3.3.3 is much faster I would be most interested - however, nbench is an excellent representative of typical program behaviour, and it was run under the same conditions on the same machine, so it is extremely strong evidence that it is not.

Finally, I will question one more of your claims - that optimised StrongARM binaries will be faster on an XScale than ARM6 ones - is this true? I don't know. Again, I ask you to show some references for this, or evidence. I fear that once again, you will not bother, and we will once again be questioning your stance on telling us what is and isn't accurate.

mrchocky on 23/3/04 12:09AM
[ Reply | Permalink | Report ]

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!

NoMercy on 23/3/04 12:22AM
[ Reply | Permalink | Report ]

> 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.

adrianl on 23/3/04 1:54AM
[ Reply | Permalink | Report ]

I never claimed that the Omega has a later southbridge than the Iyonix. Why do you keep on twisting the words in my mouth?

What the expression "much fater" means is open to interpretation. I did not say, it generates code that runs twice as fast or anything like that. I just made a general statement that can be interpreted differently by many people. Someone who knows what a complex field compiler-optimisation is and how much work is involved to mae even minor improvements will have a different view on what "much faster" means than someone who does not. And this is the point where "opinion" comes into the equasion.

If we were discussing compiler-optimisation in detail, then I would agree that were having a technical discussion. But we are not. We have only exchanged a few general opinions about their performance. This I do not consider a technical discussion. However, if you think that this is a technical discussion, then you obviously have a different opinion of what a technical discussion is.

However you are asking me to turn this into what I would call a technical discussion, by asking me to explain in detail how I came to my opinion of "much faster". However technical discussons can turn out quite lengthy and thus time-consuming. I told you before that I am not willing to invest this time and I am surprised that you seem to be. I would have thought that you also had better things to do in that time, like doing some productive work in your day-job or on your UPP? But obviously you seem to have a different opinion on this, too. I for one are working on some improvements to the forum software we use for the MicroDigital Owners Club in my spare time (wich I will offer to the maintainer of that OSS project in due course) and ATM try to learn as much as I can about video post-processing in the re-education course I am doing to become a media designer. Call me selfish if you want, but I do not see how I could gan something from a technical discussion about compilers. However this does not mean that I would not be able to participate in such a discussion, if I chose to do so. But surely you will question that, too. Unfortunately I can not find any english information about the job education I gave done before, however I can tell you that we had courses in processor-design, high-frequency PCB design and software engeneering for almost three years, and although I was not the best of my class in these courses, I still managed a "good" in most exams. And even though I have not worked in these areas for about four years now, I believe that I still know a bit about these things, especially since I have tried to keep an eye on the developments of the Omega and have had a few interesting technical discussions with David Prosser about it (personally and on the phone, so it was not so time consuming and while I was on holliday).

JGZimmerle on 23/3/04 9:50AM
[ Reply | Permalink | Report ]

Sorry, that should have been "English", no offence intended. And sorry for rest of the many typos, too. I am kind of short on time ATM and rushed this one out.

JGZimmerle on 23/3/04 9:55AM
[ Reply | Permalink | Report ]

Oh dear me. It's quite simple. There is _NO_ interpretation, no matter how exceptionally liberal your "opinion" is that GCC 3.3.3 on RISC OS is "much faster". I'm sure that's plainly clear to everyone. Except you - why you insisnt on defending this poor choice of words and actions, is really beyond me.

Frankly, you are simply playing words games, and going nowhere. Claiming that it is/is not a "technical discussion" is wholly irrelevant. Since you can present no evidence whatsoever, it is more than reasonable to presume that there is none. (Ever hear of "Peer Review" or "Scientific method"?)

As for the Southbridge - I quote from the Select list:

"IIRC the Omega uses a newer revision of the same southbridge. [Than the Iyonix]". I asked you to confirm this. This too, is not a matter of opinion. This is precisely the sort of misinformation you so relished in attempting to tell others off for.

As for "productive work" - making sure that misinformation does not spread is something I find extremely productive, because I do not have to deal with the extremely time consuming fall out later.

mrchocky on 23/3/04 10:02AM
[ Reply | Permalink | Report ]

Hmmm, the image of two cats on both sides of a fence comes to mind.....

quatermass on 23/3/04 11:41AM
[ Reply | Permalink | Report ]

bored now.

philipnet on 23/3/04 11:56AM
[ Reply | Permalink | Report ]

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".

not_ginger_matt on 23/3/04 12:02PM
[ Reply | Permalink | Report ]

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 ;-)

mripley on 23/3/04 12:05PM
[ Reply | Permalink | Report ]

ginger_matt: No, no and no. Anyone who thinks this is a "personal attack" should look again. I have nothing against Julian, _but_ what he said was clearly misleading.

My statements are about the "faster" code in GCC remain consistent - I also said that it's marginal. So, I don't really see the point of what you're saying, other than a weak attempt to take a contrary position just for the sake of it.

mripley: Nothing I've said is defensive. In fact, I've given Julian _ample_ oppurtunity to show that what he's saying is true. I'm quite happy for someone to demonstrate contrary evidence to what I've given. Julian has given none at all on this occassion, and many, many others

So, we have a situation where someone has made an unjustified statement, and it's been corrected. Then that person has tried so defend their position - for what reason, it's not clear. Spreading misinformation has hugely damaged RISC OS in the past, and just because people are getting a little upset doesn't make it ok now.

mrchocky on 23/03/04 12:53AM
[ Reply | Permalink | Report ]

You know what IIRC means, don't you?

To me it looks like you have taken a stubborn "I'm right and so you have to be wrong" view of things, so I see no point of arguing any further.

I'm also wondering in what way such a small issue could hugely damage the RISC OS market. Except maybe by the childish discussion about it alianating some users until they leave the market.

And I'm sorry if I upset you, this was not my intention.

JGZimmerle on 23/03/04 1:21PM
[ Reply | Permalink | Report ]

And BTW, if the Omega does not have newer revision of the southbridge than the Iyonix, then how do you explain that the Omega's HDD interface supports ATA133, while the Iyonix only supports ATA100?

JGZimmerle on 23/03/04 1:25PM
[ Reply | Permalink | Report ]

Yes, I know what IIRC means. If you misremembered, then I'm happy to hear a correction - that's why I keep asking. You _still_ only have to check inside your machine to see if this is true. The question is simple - does or does not the Omega have the M1353+ SouthBridge which is present in the Iyonix - if not, then what? It should be clearly visible on the motherboard.

Of course I am being stubbon about the compiler issue - you've given me no reason whatsoever for anyone to change their mind about this, so I do not see what calling me that gains you.

I have no explaination for the ATA100/133. But again, that is why I asked, because it is inconsistent about what I've been told about the various SouthBridge chips.

mrchocky on 23/03/04 1:39PM
[ Reply | Permalink | Report ]

If I recall corectly, 'iirc' is regarded as 'I've just made this up'. So what revision of southbridge chip do each of the two computers have then? Does anybody know? Surly stating fact is better clarification than adding more confusion with questions like how do you explain so and so?

wilf on 23/03/04 1:44PM
[ Reply | Permalink | Report ]

wilf: as I just said, the Iyonix has the M1535+ SouthBridge chip made by ALi. My current understanding is that the Omega has exactly the same one, but waiting for facts on this matter is precisely what I am doing.

mrchocky on 23/03/04 1:48PM
[ Reply | Permalink | Report ]

Both my Omega and my IYONIX have the very same ALi M1535+ southbridge inside. ALi says that the M1535+ only supports ATA100.

There are, however, M1535D+ southbridges where the very latest revision apparently supports ATA133. However, neither my Omega nor my IYONIX have one.

Anyway, it is a non-issue. ATA100 and ATA133 are very similar in their performance characteristics, the differences are usually not detectable. And many modern drives only support ATA100 anyway - Hitachi/IBM, Seagate and WD. ATA133 seems to be a Maxtor thing. I guess we will see Serial ATA taking over instead of ATA133 getting a standard thing.

hubersn on 23/03/04 2:22PM
[ Reply | Permalink | Report ]

Thanks for clearing that up.

mrchocky on 23/03/04 2:41PM
[ Reply | Permalink | Report ]

& like you'd notice a difference on RISC OS...

what we need is RO5 PCI cards that do ultra320 SCSI

magic! :-D

epistaxsis@work on 23/03/04 8:17PM
[ Reply | Permalink | Report ]

May I ask if there is any particular reason the Objective-C front end hasn't been ported? Is it merely that it is of little use without an OPENStep implementation? (forgive the capitalization if it's wrong)

tabercrombie on 23/03/04 8:42PM
[ Reply | Permalink | Report ]

Tom: there is simply no demand. Peronsally, It's a long time since I've seen an Objective-C program. C/C++ are much more important. That's not to say someone couldn't do it.

mrchocky on 23/03/04 9:47PM
[ Reply | Permalink | Report ]

While we're being factual and constructive...

Has anyone compared the new GCC with Mycroft (the Acorn/Castle compiler)? Such a comparison would be interesting and constructive, even if the choice of benchmark was contentious.

I also gather that there may be a new release pending from Castle quite soon - I think that's what stuffed Edit in RO5.05 (all this based on a possibly incorrect conversation, so don't flame me ;-)

TonyStill on 23/03/04 10:45PM
[ Reply | Permalink | Report ]

Tony: I'm hoping to do a complete collection of benchmarks of various compilers/options which I will publish on riscos.info. I can't say how soon I might do that, however. It's Norcroft, btw, Mycroft is something else ;-)

mrchocky on 23/03/04 11:00PM
[ Reply | Permalink | Report ]

What's wrong with !Edit in RISC OS 5.05? Is anything else affected?

Chris.

diomus on 24/03/04 06:50AM
[ Reply | Permalink | Report ]

Chocky: Mr. Mycroft is one of the chaps in Norcroft, though

(The other being Mr. Norman.) So Tiny was half way there.

nunfetishist on 24/03/04 09:26AM
[ Reply | Permalink | Report ]

@hubersn:

Does the serial number of your Omega start with 250 or 327?

JGZimmerle on 24/03/04 10:34AM
[ Reply | Permalink | Report ]

AFAIK

IIRC means If I Remember Correctly. This does imply that I am not sure and so could be wrong. Thus I do not claim this to be abolute fact. However, there are different revisions of the ALi M1535+, with quite major differences, for example some older revisions had a bug in the USB host controller wich effectively rendered its USB part useless.

JGZimmerle on 24/03/04 10:53AM
[ Reply | Permalink | Report ]

State your references, Julian. Or do you expect that we trust you? ;-)

Spriteman on 24/03/04 11:23AM
[ Reply | Permalink | Report ]

Great, we've got GCC. Can someone do something useful and port Perl 5.8 to RISC OS? ;-)

quatermass on 24/03/04 11:25AM
[ Reply | Permalink | Report ]

SH: we've had GCC for a long time. And perl for that matter. Try using drobe's search tool:

[link]

mrchocky on 24/03/04 11:29AM
[ Reply | Permalink | Report ]

And before you say anything, Chocky isn't Drobe's search tool. :P

Spriteman on 24/03/04 11:58AM
[ Reply | Permalink | Report ]

Sure, you can look it up in the datasheets from ALi: [link] ;-)

JGZimmerle on 24/03/04 2:43PM
[ Reply | Permalink | Report ]

Chocky: I look forward to seeing the benchmarks. As to Norcroft, you're quite right - I coincidentally stumbled across Mycroft's web page (which credits his design input to the compiler) and had his name on my mind; didn't look right when I wrote it.

Chris: Edit in the RO5.05 ROM reacts very badly (and then crashes) to some scroll circumstances, mostly it's fine - I still use it. I gather that it was compiled with a pre-release version of the next compiler; since it is unlikely that Castle has touched the source, a compiler problem seems likely but I'm not definitive on this.

TonyStill on 24/03/04 8:33PM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

+++ Message board +++

Read messages or start a new thread

Search the archives

Today's featured article

Online banking with RISC OS
We thought this would be of high interest

28 comments, latest by devine on 25/9/05 8:30AM. Published: 1 Sep 2005

Random article

South East 2007 show preview
What to expect at this weekend's event

30 comments, latest by jess on 24/10/07 12:12AM. Published: 18 Oct 2007

Create a new account
Forgot your password?

Useful links

News and media:
Iconbar • MyRISCOS • ArcSite • RISCOScode • ANS • C.S.A.Announce • Archive • Qercus • RiscWorld • Drag'n'Drop • GAG-News

Top developers:
RISCOS Ltd • RISC OS Open • MW Software • R-Comp • Advantage Six • VirtualAcorn

Dealers:
CJE Micros • APDL • Castle • a4 • X-Ample • Liquid Silicon • Webmonster

Usergroups:
WROCC • RONE • NKACC • IRUG • SASAUG • ROUGOL • RONWUG • MUG • WAUG • GAG • RISCOS.be

Useful:
RISCOS.org.uk • RISCOS.org • RISCOS.info • Filebase • Chris Why's Acorn/RISC OS collection • NetSurf

Non-RISC OS:
The Register • The Inquirer • Apple Insider • BBC News • Sky News • Google News • xkcd • diodesign

© 1999-2009 The Drobe Team. Some rights reserved, click here for more information
Powered by MiniDrobeCMS, based on J4U | Statistics
"We accept Drobe likes to be [controversial], no problem there - but a sinister pattern has appeared over the past year or so"
Page generated in 0.1618 seconds.