OS_ClaimProcessorVector again

Personally, I really don’t feel the need for a modern browser on RISCOS. NetSurf does for any browsing I do on RISCOS. I use a Mac for normal browsing. I don’t expect my Pi to do everything I use a computer for. The Pi is there to do the things RISCOS is good at.

Personally, I really don’t feel the need for a modern browser on RISCOS.

It’s not all about you Clive:-)
NetSurf also meets 90% of my browsing needs, but my wife who runs RISC OS on a pi cannot do her online shopping without reverting to a Windows laptop and would much prefer to keep everything on the one machine she does email and everything else on.
My children who grew up with RISC OS refer to it as JOS (Joke OS) and their children ask what did you do in the war Grandad?
Iris, Goddess of the Rainbow, is a sign of hope.

It’s not all about you Clive

8~) Of course; hence the “personally” bit!

Note VRPC DL can run at least 4,5 and 6.

VRPC DL can run at least 4,5 and 6

5? Really? No mention of RO5 here:
http://www.riscos.com/shop/products/107/index.htm

in summary, we should stop supporting & updating older ancient CPUs, while still continuing to support & update older slightly less ancient CPUs.

I mean, who are “we”? and how do “we” make such a decision?

I’d say about 5% the regular names on the forum, and about 95% the people actually doing the work.

That’s why I said that I think the vector handling will likely be split out into it’s own source, and then a second copy updated with older machines getting the original (no longer updated) code.
Because as much as it is necessary to look to the future and bring an end to supporting machines over a quarter century old, I don’t imagine there’s much appetite for cutting off those machines unless absolutely necessary.

Personally, I really don’t feel the need for a modern browser on RISCOS. NetSurf does for any browsing I do on RISCOS. I use a Mac for normal browsing.

The more one needs to switch systems to get stuff done, the less one will be favourable to RISC OS.

I’ve not actually sat in front of RISC OS for a couple of weeks now. I write my blog articles on the tablet and do browsing on the tablet or phone. Because Firefox can cut it. Netsurf really cannot.

and would much prefer to keep everything on the one machine she does email and everything else on.

This. If people have to swap machines because of the limitations of one, how long until they simply stop using the limited one?
I know I’ll keep on using RISC OS, it’s an emotional thing for me. But for people we’re trying to attract? There’s so much of the modern world that is out of reach, and we really need to be looking to ways (even crowd funding) to try to make some of that happen. If continuing support for ancient machines is holding back development, it’s time to make some difficult decisions.

My children who grew up with RISC OS refer to it as JOS (Joke OS) and their children ask what did you do in the war Grandad?

It’s still being developed and runs on contemporary machines. That’s better than most operating systems of its time.

No mention of RO5 here:

Maybe he meant four and a half? ;)

Sure, I’d love to do everything on RISCOS. But is that really a realistic objective?

But yes, I’m one of the regulars, not one of the workers. Don’t take any notice of me.

I’m one of the regulars, not one of the workers

Me too – and it’s an important distinction.

I justify my interventions (to myself) by (a) a commitment to RISC OS lasting almost thirty years; (b) being a regular user with a practical, as well as emotional, commitment to the platform; (c ) that feedback based on experience might be useful occasionally. But I am well aware that the heavy lifting is being done by others, and I am very grateful to them for doing it.

I mean, who are “we”? and how do “we” make such a decision?

The “we” that make the decisions are the people doing the work. Which as far as I can tell, means about one person talking in this thread (and quite likely a few others who aren’t interested in discussing it with the armchair experts on the forums).

I am well aware that the heavy lifting is being done by others, and I am very grateful to them for doing it.

Exactly.

with the armchair experts

Armchair? It’s posh you are then.
Oh, I can only dream of a chair with arms.

(cue somebody pointing out that the ARM is in the Pi…)

So in summary, we should stop supporting & updating older CPUs, while still continuing to support & update older CPUs. Got it! ;-)

Pretty much! It’s clear from the discussion above that some people still want to maintain older machines, so !System maintenance will have to stay for the forceable future. What I’m advocating is to drop them from the current OS kernel, so you don’t have to make compromises around modern standards and security to support them.

In regard to the OP, I’m suggesting we follow ARM ARM and start addressing the user code elevation issue.

I mean, who are “we”? and how do “we” make such a decision?

The “we” are the community and “we” don’t get to decide anything, all we can do is air our opinions on the forum. The OS devs make the decisions as they are doing all the work.

In regard to the OP, I’ve added my view on the proposed change as someone that has good knowledge of Abort handlers, and someone that would have to change current code to support the changes. Why other “armchair experts” have joined in is probably because my comments have either stuck a chord or a nerve ;)

I don’t have a problem with the armchairs myself, you don’t have to be coding the thing in question to offer an opinion on its direction. All of my own coding is community led after all.

@ David Ruck

If we go for ARMv7 minimum we can get the FP sorted out standardising on VFP3 and Neon. That will enviably cause incompatibility for ARMv6 and earlier, but then no one uses FP on RISC OS do they? :)

It might be time for RISC OS 7 that requires minimum ARMv7 so that it can be speed-optimized with NEON and hardware VP, maybe 3D GPU and video GPU support on the RK3399. When multi-threading is ready it is time for a new number and a new chapter of RISC OS.

@Bryan Hogan

There are millions of Pi 0,1,2 out there.

Right but do they want to run a desktop system? If we can get 0.01% of all Raspberry Pi 3 & 4 users that would be already a revolution for RISC OS and therefore that should be our aim (or one of them).

@Jeffrey Lee

So in summary, we should stop supporting & updating older CPUs, while still continuing to support & update older CPUs. Got it! ;-)

Forget about ARMv6! Everyone can buy a Raspberry Pi 4 for 50 UKP. If not we better get donations for them instead of leaving RISC OS unattended in the ICU. We need multi-threading soon (maximum 12 month) and not in some years. So please(!) focus on getting the job done and not getting stuck in side-features that nobody needs.

We have Iris now which supports HTML5 and Javascript but the speed cannot compete yet with a Windows machine as it is only 1 core-powered.
To close that gap we need the multi-threading.
So multi-threading will be a game changer for RISC OS. NO multi-threading – NO competative speeds!

Stefan

Forget about ARMv6! Everyone can buy a Raspberry Pi 4 for 50 UKP. If not we better get donations for them instead of leaving RISC OS unattended in the ICU. We need multi-threading soon (maximum 12 month) and not in some years. So please(!) focus on getting the job done and not getting stuck in side-features that nobody needs.

Stefan, are you employing Jeffery at commercial rates. He is doing this work in his own spare time, for nothing and for the love of RISC OS. For which I thank Jeffery for all his hard work.

So Stefan, its NOT up to you to dictate to Jeffery what he does with his time, or when its ready, it will be ready when its ready.

We have Iris now which supports HTML5 and Javascript but the speed cannot compete yet with a Windows machine as it is only 1 core-powered.?To close that gap we need the multi-threading.?So multi-threading will be a game changer for RISC OS. NO multi-threading ? NO competative speeds!

Here you go again! Iris is only configured to work on one core currently so would need more work at a cost. Once again you are pushing Jeffery here about multi-core, please stop Stefan. I know you had multi-core as part of your Cloverleaf roadmap which was not on a realistic timetable.

So multi-threading will be a game changer for RISC OS.

I trust that you understand, Stefan, that any multithreading will be a bolt on separate system that “compatible” tasks will be able to make use of. There will not be multiple core task sharing around the available processors within RISC OS as it stands.

If you disagree, please explain how you plan to overcome things such as the numerous parts of the OS that are not reentrant (we already have to be really careful in service call or vector code) and also how you think things like Wimp_MessageRecorded would work when tasks are running asynchronously on multiple processors.

I have advocated in the past that other cores are treated in a way similar to the Tube where the primary core (and RISC OS) is in control, and applications can pass code to the other cores to be executed. It’s not “proper” multi core, but perhaps the best we can expect without a rewrite of large parts of the OS (and the API). At least like that the extra processing power will be available in some manner.

but the speed cannot compete yet with a Windows machine

Hmm, 1.x GHz ARM vs 3GHz x86? ;-)

Right, I’m off to have a needle stuck in me by a nice woman who’s the daughter of somebody I work with.
Must. Stay. Conscious.

It might be time for RISC OS 7 that requires minimum ARMv7 so that it can be speed-optimized with NEON and hardware FP.

You can do this and support older processors.

We have Iris now which supports HTML5 and Javascript but the speed cannot compete yet with a Windows machine as it is only 1 core-powered.
To close that gap we need the multi-threading.

No. It’s easy to configure Chromium on Raspbian for 1 core… and see it still much faster than Iris.

the speed cannot compete yet with a Windows machine

… and it’s easy to use Chromium on a Pi4 to see it can’t compete with a Windows machine.

There will not be multiple core task sharing around the available processors within RISC OS as it stands.

Correct. If we have the equivalent of light threads, I’ll consider us to be very lucky. Full SMP/PMT is really another thing.

I have advocated in the past that other cores are treated in a way similar to the Tube where the primary core (and RISC OS) is in control, and applications can pass code to the other cores to be executed.

Perfect…

No. It’s easy to configure Chromium on Raspbian for 1 core… and see it still much faster than Iris.

We’re digressing from the OP here, but Iris’s performance issues will be down to a lack of multi threading and in particular the lack of a threaded file system. FileCore needs to be deprecated and replaced completely as there are too many issues with it, both with the Module and the FS.

@ Chris Hughes
Discussions in a forum exist to get other peoples opinion. I hope that my comments make sense and are logic.
I have nothing to order Jeffrey what to do or not to do. I am just making clear how important his work is for the future of RISC OS.
And that I do to motivate him to do the right thing as it really matters for RISC OS what he is doing.

This also change decisions if you do something for your own fun, or for 30 users or for x million of users.

PS: I have no idea how long Jeffrey will need to implement all what is needed. But I know one thing for sure: Working on stuff to include old RISC OS machines will delay the release of the multi-threading and should be prevented. As time means lost new users and less old users (RIP).

About !Iris:
You can’t expect that a first version of a program has the best performance and compare it to programs where probably hundreds of programmers work on when we have only one. The speed deficiencies might be caused also by other bottleneck like the TCPIP stack or Filecore (as mentioned by Jon Abbot). It needs to be detected which are these bottlenecks and they must be removed.

RISC OS has so many bottlenecks, there isn’t room the rest of the bottles.

In relation to the OP, you have to wonder how much time is spent on the SWI handler on apps such as Iris. Perhaps we need to modify CLib and the OS to replace CLib’s inefficient SWI handler with direct calls via a jump table? Just an idea. Iris needs profiling to find out where the delays are.

The hardware vectors themselves are pretty efficient, I’ve clocked 6+ million Aborts per second on self-modifying code on a Pi1 and the game in question was still running at it’s expected speed. Any multicore compliant replacement would certainly slow things down a bit due to the abstraction, but that’s vastly offset by virtue of other cores continuing to run code. I’m assuming aborts are core specific of course, stalling the whole CPU for one core would be bonkers.

Perhaps we need to modify CLib and the OS to replace CLib’s inefficient SWI handler with direct calls via a jump table?

CLib only uses SWIs for registering clients; the calls to the library functions have always been handled via a jump table. Compared to a normal function call, the only overhead is an extra LDR PC,[PC,#xxx] instruction. For frequently used functions on a modern CPU I’d expect the overhead to be one cycle or less.

I’m assuming aborts are core specific of course, stalling the whole CPU for one core would be bonkers.

Yes, aborts are core specific.

Is Jon talking about _swix() here – that is truly evil.

I have long railed against the horror of swix, but people seem to like the convenience and to hell with what’s going on under the bonnet… :/

https://heyrick.eu/blog/index.php?diary=20160106

Is Jon talking about _swix() here – that is truly evil.

Ah, sorry!

_swix() could be implemented as a compiler intrinsic, giving it performance that’s close to more direct wrappers like OSLib.

Direct calls (bypassing the kernel’s SWI dispatcher) would be tricky, since you’d still want to be able to do things like allow the target module to be killed (or replaced) in a safe manner, and for multi-core the kernel needs to spot when an unsafe SWI is being called so that it can force the system into single-threaded mode. And then for applications you’ve got the obvious things like needing to switch from user mode to a privileged mode, and dealing with callbacks & error raising on return.