RISC OS Pi?

[DavidS]

DavidS,

The same way that the MIT license and BSD license are more open than GPL or did you forget the reason that submissions to the OBEX require the use of a MIT license (as GPL is to restrictive).

I reject the claim that a license which allows my open source code publications to be incorporated into and distributed in other peoples closed source software is "more open". It clearly is not.

As it happens, my open source publications are so trivial and/or useless that I really don't care much one way or the other. If somebody is smart enough to find a way to make a buck or two out of using it in their closed source software then good for them.

What I do need is a license that that prevents anyone putting the blame on me when they are dumb enough to use my code and results in their house burning down or other such disaster.

While definitely possible, very difficult to measure in a provable way (do to changes in network conditions across the internet)

Who said anything about "across the internet". The performance an behavior of a web server or other IP server can be evaluated in the controlled conditions of local LAN connections.

As they are single core programs it makes it fairly simple to do (SMP is new to RISC OS so still a bit more difficult than need be).

So what you are saying is the exercising graphics is not a good test of RISC OS, neither is a networking, and neither is multi-threading.

What does that leave? Perhaps some kind of work on files and file systems.

I actually suggested using OS graphics routines.

Now I know you are just attempting to kill the thread. And we are talking about the speed of the OS, so need to keep with using OS calls for everything that is done, not extended libraries.

No wild claims. Would you like to see how fast the OS is (not the speed of code that does not use the OS, the speed of the Actual OS), I have offered the opportunity.

That is exactly what I'm getting at. But we seem to have no way to compare RISC OS vs other operating systems.

YES THERE IS. What does the OS offer, it offers a means of multitasking, it offers text input output, it offers a windowing system, it offers a font engine, etc, etc.

Unfortunately for both systems being in comparison OpenGL is an extension, not part of the OS.

The problem comes in what AS AN OS the OS to coimpare to offers, which is not much. So lets add X and a WM to the OS we are comparing to, now we can compare the two in a reasonable fasion.

So we compare the Windowing abilities, the graphics primitives of the two systesm, etc.

Or are you just trying to kill a good thread?

Nope. Just separate the reality from the hype, as I said.

You are attempting to kill a thread. Otherwise you would actually read what I repeatedly say about what you try to nock.

You attempt to say RISC OS is not a fast OS, I attempt to propose a way to show that RISC OS is a fast OS (then you go off topic and attempt to suggest examples that do not use the OS, or that I am not curently setup to test [not currently set for LAN file transfers, web relies on non-OS components]).

Though you ignore and edit out my recommendations to show you the proof, you poo poo by taking out of context. So you are attempting to kill a thread, or at least dismiss an OS that you refuse to accept a means of understanding. I could understand if you had simply said yes or no, and then in a seperate thread we could have seen the challenge if you had said yes. Though in stead you are attempting to ignore the proof.

[DavidS]

jahboater,

That is an excellent idea. If DavidS got 9.1 working on RISC OS we would have a level playing field for the forthcoming RISC OS / Linux comparison.

We all know that I really do not care for GCC. So why would I want to port a newer version of GCC to RISC OS?

I use GCC where I have to, though often even on Linux I will use TCC instead with some assembly to achieve better performance when working in C. I lost my copy of Norcroft C (DDE) so I am stuck with either no C or GCC or my C on RISC OS, though on RISC OS I use assembly and BASIC primarily.

[DavidS]

And for reference GCC 4.7.4 is not an old version, it was released in 2014, so it has not even had a chance to cut its teeth yet.

[jahboater]

And for reference GCC 4.7.4 is not an old version, it was released in 2014, so it has not even had a chance to cut its teeth yet.

I'm afraid that's where we differ.

For you it might be a recent version, but most people would consider five major releases out of date as way too old. Especially as more recent versions are readily available for free.

Raspbian/Buster comes with GCC 8.3 which is fine.

You no doubt have spotted the crap ARM code that 4.7.4 emits and are using that as the basis for your observation that you can write better assembler than a C compiler. Really you should be comparing your code with the assembler that GCC 9 produces.

[DavidS]

And for reference GCC 4.7.4 is not an old version, it was released in 2014, so it has not even had a chance to cut its teeth yet.

I'm afraid that's where we differ.

For you it might be a recent version, but most people would consider five major releases out of date as way too old.

Raspbian/Buster comes with GCC 8.3 which is fine.

You no doubt have spotted the crap ARM code that 4.7.4 emits and are using that as the basis for your observation that you can write better assembler than a C compiler. Really you should be comparing your code with the assembler that GCC 9 produces.

I will leave updating GCC on RISC OS to those that are interested in both RISC OS and GCC.

On Linux I have compared my code against GCC 8.x, and considered comparing with GCC 9, they often do things in slow down ways for AARCH32. I think they are focussing on other ISA's and jsut using basic standard rules to for the AARCH32 targets, my personal view mind you.

I use RISC OS, sometimes I have to use GCC though I do not like it personally.

I thank you for the input though.

[DavidS]

Will a moderator please lock this thread before the argument that has over taken a significatn part of this thread gets to far.