Your computers and this hot weather

That happened to me and found the box locked up.

But remember that there exist/are available a couple of modules that can cancel such a box after a short delay.

I use NoError 1.00 (18 Sep 2003).

Any chance of dropping cooperative multitasking in favour of preemptive?

Preemptive is not a magic fix. Hardware stuff like controlling the processor speed to advert meltdown ought to be handled at a level below the entire multitasker…

Wouldn’t the kernel or module do a better job?

You’d have thought so, as like that it’ll be able to work all the time instead of just when the Wimp is running (and not blocked by a busy app)

But if an app is busy, surely you’d want it to run at full speed so that it can finish quicker?

In bizarro Acorn land, putting the logic for CPU-usage based CPU throttling in the Wimp makes perfect sense, because the Wimp is the one that does the task swapping and scheduling.

Remember that we don’t have any form of threading, so there’s no idle thread which the OS can drop to when it’s got nothing to do. Instead we just have the Wimp, and umpteen loops which sit and wait for other bits of hardware to catch up with the CPU. Some of those loops will be smart and do their own power saving (e.g. via Portable_Idle), others will be dumb and sit there burning silicon.

For temperature-based throttling, yes, it makes sense to put it in a module so that it can be active no matter what programs are doing. But for usage-based throttling you can only really do something sensible if you have a way of measuring CPU usage, and the only generic way that can be done at the moment is via the Wimp.

Or its sitting unattended with an error box on the screen

That happened to me and found the box locked up. Make sense now

FWIW that issue (Wimp not doing power saving when showing an error box) was fixed back in November 2015. But the change was post-RC14, so it’s possible you saw it in that.

Preemptive is not a magic fix

You’re right, but it would be the first step.

if an app is busy, surely you’d want it to run at full speed so that it can finish quicker

A lot of time you’re waiting on IO, so it’s pointless. Plus you could have a certain percentage higher than what was being used to ensure efficiency without compromising performance too much.

You’re right, but it would be the first step.

Never going to happen.

Don’t get me wrong here, there ought to be a fairly simple (!) way of having the Wimp understand that a program is “busy” and can be pre-empted at that point. The Wimp, upon the Wimp_PreEmption, 1 SWI can set a ticker to X centiseconds, and if the ticker fires, it will save state and behave as if Wimp_Poll had been called. This can continue until Wimp_PreEmption, 0 or Wimp_ReportError is called.
There would be a few wrinkles to sort out, such as what to do with Wimp events that occur during the preemption. The simple way is to say “tough” and discard them. The complicated way is to queue them and hope that stuff that relies upon a timely response (drag-save, etc) can cope. The logical way is to allow the program to register an entry point that can be called by the Wimp for simple polling activity notifications. The Wimp can issue redraw requests, for instance, it is up to the application if it wants to do that or not at that specific time. Obviously this may have problems with BASIC code, but it’s a start at getting something useful going.

As for converting the entire Wimp to pre-empted. No. Why? Because its behaviour under a preempted system would be sufficiently different to what is now that it risks either having a hell of a lot of bodges to maintain something that looks like current behaviour (and the Wimp API already has some yucky bodges as it is¹), or “every single application needs to be rewritten”. We’ve been in that game enough times that if there was a choice between CMT and apps or PMT without apps, I betcha I can tell you which everybody would choose.

if an app is busy, surely you’d want it to run at full speed so that it can finish quicker

Depends what it is doing. Some measures of busy can sit in the background doing what they do a little more slowly without naffing up the rest of the system with periodic hiccups.

¹ We can start with “TASK” to indicate “actually multitask, not the lame Arthur method”, then we can add “arbitrary version number requests to enable/determine features” instead of something useful like a flags word. Don’t get me started on how the nested windows got bodged into the existing API. Or the mess you have to go through to turn a window co-ordinate into a dot on the screen. Or the fun of who decided a system capable of 255 character paths (at the time) can put all of that information into a 256 byte block where the first twenty bytes are information to the Wimp. Let me see, 256 minus 20 minus 255 is…uh… And a pet peeve of mine, how Unicode keys got bodged in using multiple keypress events, primarily because the Wimp uses a bunch of key codes >255 to handle function key presses. This being the Wimp that is unable to actually distinguish Page Up from Shift-Up, likely because the OS itself can’t, likely because “that’s how we did it in the BBC MOS”. Actually, there’re a number of keys that are not distinguished one from another. Look at the source of David Pilling’s XXX_Keys module (Hearsay, Ovation, etc). It’s for that exact reason.
I’ll step down from my ranty soapbox before there’s a blown gasket, steam, and such…

Hardware stuff like controlling the processor speed to advert avert¹ meltdown ought to be handled at a level below the entire multitasker…

¹ In a future dystopia, people are going to get arrested, jailed! maybe even executed for messages of hate! promoting terrorism! and such. And you know what? It’ll turn out to have been autocorrect inserting what it thought you meant instead of what you really typed. Did you notice the unexpected exclamation marks? That’s iOS deciding for itself that my commas lack impact so need to be replaced by more forceful punctuation…half a sentence later. I’ve left them in for the sake of example. But, with such….dare I say “advances”…in technology, are our words really our own any more, or even what we intended to say?
I mean… JAILED! HATE! TERRORISM! …reads like a Daily Fail Mail headline.

there ought to be a fairly simple (!) way of having the Wimp understand that a program is “busy” and can be pre-empted at that point

I’m not sure wimp is the best interface to implement multitasking. You’re right though, there is no simple solution.

The complicated way is to queue them and hope that stuff that relies upon a timely response (drag-save, etc) can cope.

The mouse should be handled by IRQ or FIQ (Idk which, not an ARM expert) so multitasking shouldn’t affect it if properly implemented.

The Wimp can issue redraw requests… it is up to the application if it wants to do that or not at that specific time

That’s quite a normal behaviour

risks either having a hell of a lot of bodges to maintain something that looks like current behaviour

I worry that bodging is encouraged in the RO community in general because we lack some modern frameworks and features. It is the only way to get things done, at the moment. It needs a clear roadmap and preparatory work needs to be done to modernise and stabilise the system.

We’ve been in that game enough times that if there was a choice between CMT and apps or PMT without apps, I betcha I can tell you which everybody would choose.

Absolutely. You cant break things overnight. It needs to be a gradual and slow implementation, and that means ROOL needs a clear map so contributors and developers can make their application future proof.

Talk is cheap and I’m talking a lot. I really need to fully understand RO to properly suggest how and why we should consider going in a certain direction. This is what I am spending all my spare time on, so hopefully I’ll have something useful to contribute to the community.

Although I’ve read a few OS development books, I will say this. I am a terrible assembly programmer, and I’m a mediocre C programmer at best. This makes me hesitant to go and play around with the RO source, because once I do I will be glued to it and I’m not sure I’m the kind of guy anyone wants actually writing the code for their OS, so I’ll probably be wasting my time and annoying ROOL as they keep rejecting my subpar code.

It needs a clear roadmap and preparatory work needs to be done to modernise and stabilise the system. […] ROOL needs a clear map so contributors and developers can make their application future proof.

Hmm. You’ve not been around here long, have you…?

RISC OS is hamstrung by the vast number of abandoned applications which many users “can’t live without”. One of the problems that faced ROL on RISC OS 6 was that it was becoming very obvious that the kinds of changes which they envisaged simply weren’t possible without breaking “essential” applications that weren’t being maintained (and perhaps didn’t even have viable source code any longer). There were other issues, but that one was starting to become relevant and users were starting to mutter.

The RISC OS 5 world was slightly different, because 32-bit lost all of the “dead” applications back in 2002. That was 15 years ago, however, and we’ve now got a whole load more. If you try to change something as fundamental as the way that the Wimp multitasks without making it completely backwards compatible, then you’ll have another software extinction event and lose a good chunk of the current users. Look at how many refuse to run high vector ROMs for an idea of what I mean.

Before you can even consider messing with the Wimp’s multitasking, you’re going to need some compatibility scheme in place and working 100% for old software. I know that’s being considered, but it needs to be here before any “legacy” software is broken. I’m afraid that there’s a reason why RISC OS is still in the 1980s…

I tend to avoid consumer-grade equipment.
I agree totally with you. Anything consumer or home grade is just rubbish that hasn’t quite found it’s final state yet. Unfortunately even secondhand, consumer grade routers are painfully expensive.

I’m not thrilled about any of the routers I’ve had. They all seem to need hard rebooting daily after becoming incredibly sluggish then nonresponsive. Usually when they get like this they are noticeably hotter than during normal use too. I find it interesting. I’ve offloaded DNS to the Orange Pi Zero NAS, but that hasn’t helped much.

I’ve got something like a (D-Link(?) Cisco)?? router as the WiFi and LAN distribution point for the loungeroom. The only time I’ve ever had to reboot that was when I’ve done something dumb. It’s sleeping now because my dog wrecked the cable connecting the ADSL router to that router. It’s funny. They are maybe 6m apart but I had to do it because WiFi can’t penetrate the walls too well. Plus I’m not fond of WiFi for streaming.

I quite liked the Billion BiPAC router. Unfortunately it succumbed the way they all do. I just wish I could find the cause of the slowdown and collapse of them all.

I’m not sure wimp is the best interface to implement multitasking.

Well, it’s the only one we have that even understands the concept of “tasks” being a plural word.

The complicated way is to queue them and hope that stuff that relies upon a timely response (drag-save, etc) can cope.

The mouse should be handled by IRQ or FIQ (Idk which, not an ARM expert) so multitasking shouldn’t affect it if properly implemented.

Oh, I’m thinking way higher than that. You drag a file from Edit to “app”, the mechanism starts off with expecting “app” to acknowledge. If there is no such Ack, the Wimp will bounce the message and Edit will know that “app” doesn’t support drag saves. Pretty much the entire SendMessageRecorded mechanism works like that, and it’s going to be interesting getting that to carry on working in a multicore world.

The Wimp can issue redraw requests… it is up to the application if it wants to do that or not at that specific time

That’s quite a normal behaviour

Remember RISC OS internally doesn’t have a concept of tasks. It’s smoke and mirrors provided by the Wimp. As such, the API is fairly simple and tends to expect a response when you’re notified of an event.
When the Wimp tells you there’s a redraw, you’re supposed to ask for rectangles (parts of your window that need to be drawn) until there are no more. If you ignore your redraw request, does the Wimp cache this for later? I don’t think so. It might even end up triggering a panic redraw (easiest way to fix confusion – get everything to redraw everything).

I worry that bodging is encouraged in the RO community in general because we like some modern frameworks and features.

No, I think bodging happens because there are lots of grand ideas and about zero developer time.

It needs a clear roadmap and preparatory work needs to be done to modernise and stabilise the system.

And here we run into an impasse. I don’t think ditching CMT for PMT is the right way forward. There are so many things that need to be addressed before even thinking about touching the Wimp.
Consider the module area. Holds system extensions that run with privileges akin to the kernel. Way too late to change that, but it gets worse. This area is writeable from user mode applications.

Consider the module area again. Do you know what it actually is? It’s a giant OS_Heap block containing an unholy mix of executable code and data areas. And when I say data areas I mean thousands. Any module that wants to grab a little bit of workspace will claim some from the module area. Load another module, it’ll follow. Probably with its own claims following that. Overshoot an array and god knows what will get trashed…
Have a look at https://www.heyrick.co.uk/blog/index.php?diary=20160801

Absolutely. You cant break things overnight.

No, breaking things takes time and planning. Look at Brexit.

Sorry, you kind of walked into that one. ;-)

and that means ROOL needs a clear map so contributors and developers can make their application future proof.

Somewhere on the forum there’s a thread about how to handle multicore. I think it runs to dozens of pages, hundreds of posts, and we’re not really any further forward. There’s some code to get other cores started, but nothing that is integrated with the system. I suspect something will turn up some day out of the blue with no discussion beforehand because everybody has their own idea of the best multicore mechanism, it’s just none of these ideas agree.
I, for instance, favour PMT-lite (described above) and an implementation of multicore that runs a small fake kernel that kicks everything it can’t do for itself back to the main kernel. This isn’t because this is what’s “best”. I’m simply being pragmatic. A lot of the nicer ideas require huge swathes of RISC OS to be rewritten so they’ll work at all – and it’s just not going to happen, developer time is limited. Hell, do you have any idea how old the TCP/IP stack is? People are afraid to look at the code as it’s so old even the cobwebs have evolved…into something nasty with rows of teeth.

Anyway, pragmatic means “might happen” while the best ideas in the world means “never happening”…

Talk is cheap and I’m talking a lot.

…this is a forum. It’s what we do.

I will say this. I am a terrible assembly programmer,

Oooh, and the heart of RISC OS is pretty much hardcore assembler, with liberal use of macros and declarations scattered all over the place.

I’m not sure I’m the kind of guy anyone wants actually writing the code for their OS, so I’ll probably be wasting my time and annoying ROOL as they keep rejecting my subpar code.

Don’t submit it. Run it. If it works for you (in extended use, not just a few quick tests), then come back here and ask for volunteers with other systems to give it a try. If it’s still good and works well, then you give it to ROOL to look at.
When I fixed a bit in CLib, I whinged about it on the forum, but I took a while before doing all of the boring regression testing (as CLib needs to work on everything from RO3.10 up), not because I was lazy or couldn’t be bothered, but because I’d already made the change in my ROM build and my own software uses it, so I wanted to know it works just as well after long uptimes. I didn’t see any reason why it shouldn’t, but I wanted to demonstrate it to myself.

If I wrote a whizzy new way to swap tasks, I wouldn’t give the code to ROOL. I’d run it myself. And if my machine behaved as expected, I’d put a ROM image up for others to try, maybe share the code with people who can build for other machines like the OMAPs or the Ti. If it worked on various other people’s machines, then I’d send code to ROOL. Not so much point involving them sooner, if the code isn’t proven. They’re the operating system maintainers, not my personal beta testers. ;-)

It’s amazing how I have a discussion in General that looks aldershot, and an aldershot discussion that is more General. Sorry about this.

Hmm. You’ve not been around here long, have you…?

Haha, no I haven’t. I am aware, however, of RO communities love of legacy. Here’s the thing, though. I love legacy software and I wip it out from time to time. I use Win 3.11 sometimes but I don’t expect Win 3.11 updates. It’s unnecessary.

As I understand it, ROOL was founded so RO5 wouldn’t die out, and so they could attract developers and bring the OS into the 21st century. Am I mistaken? Eventually a line needs to be drawn regarding legacy applications or RO will never be modernised. If a legacy app is no longer supported, that could be a gap in the market for a current developers to fill, no?

If you try to change something as fundamental as the way that the Wimp multitasks without making it completely backwards compatible, then you’ll have another software extinction event and lose a good chunk of the current users.

I agree. I’m sure there’s a way around this, but I need to become a lot more acquainted with RO5 to give any specific suggestions.

you’re going to need some compatibility scheme in place and working 100% for old software.

Absolutely. If there’s a way to do it, we should. I don’t think you should be to quick to abandon software, but it has to be acknowledge that sometimes it is necessary. Whether it is necessary here or not, I cannot say yet.

I’m afraid that there’s a reason why RISC OS is still in the 1980s…

I thought it was because of a lack of developers. xD

As I understand it, ROOL was founded so RO5 wouldn’t die out, and so they could attract developers and bring the OS into the 21st century. Am I mistaken? Eventually a line needs to be drawn regarding legacy applications or RO will never be modernised.

Totally agree, if you look at the ARM-on-ARM discussion Jon and Jeffrey have been running you will see that what people would like is something that will run at the speed of a legacy machine or better and run legacy software but be updated as each change of OS occurs so that new OS versions don’t break legacy apps.

If a legacy app is no longer supported, that could be a gap in the market for a current developers to fill, no?

Ah, um…

I’m afraid that there’s a reason why RISC OS is still in the 1980s…

I thought it was because of a lack of developers. xD

I repeat “Ah, um…”
In some,rare, cases the developer open sources their stuff and someone else takes on the task of revising the source to match the new platform. The original Ovation and Rick Murray being one example. So we muddle along, slowly.

On the other side of the coin people find reasons to not use the high vector versions of RO5.23. I’ve just stirred the ants nest there of course.

On the other side of the coin people find reasons to not use the high vector versions of RO5.23.

…I think the prime one being that high vector breaks Aemulor, which is used to keep all those legacy 26 bit apps running…

Stir, rinse, repeat.

Stir, rinse, repeat.

Dunno about the rinse, but I do try on the rest :)

PS. ARM on ARM, bin the auto-in-flight-patch.

…I think the prime one being that high vector breaks Aemulor, which is used to keep all those legacy 26 bit apps running…

Wasn’t it the case that there is another change that broke Aemulor, regardless of high vector or low vector?

Looks like there’s a demand for a decent modern emulator.

Wasn’t it the case that there is another change that broke Aemulor, regardless of high vector or low vector?

IIRC there’s a few. Mostly changing hardware behaviour.

Basically James is right, modern ‘emulator’ required as well as moving on with the OS.

Wasn’t it the case that there is another change that broke Aemulor, regardless of high vector or low vector?

Aemulor works fine on my pi2 running RC15 (which is low vector): AIUI vector is the key issue here. But failing an Aemulor update some kind of ‘modern’ emulator is undoubtedly required.

Looks like there’s a demand for a decent modern emulator.

Or do the job properly and have available code and somebody willing to take the time to make the necessary modifications…

…you know my email address. ;-)

…you know my email address. ;-)

Not really, no. xD

https://www.heyrick.co.uk/blog/

Top of the page.

Although I’ve read a few OS development books, I will say this. I am a terrible assembly programmer, and I’m a mediocre C programmer at best. This makes me hesitant to go and play around with the RO source, because once I do I will be glued to it and I’m not sure I’m the kind of guy anyone wants actually writing the code for their OS, so I’ll probably be wasting my time and annoying ROOL as they keep rejecting my subpar code.

So what kind of thing are you good at? There’s more to life than assembler and C. E.g. although you might not be able to directly help out with a lot of the lower-level tasks, there are plenty of areas where a good software designer would come in handy.

Wasn’t it the case that there is another change that broke Aemulor, regardless of high vector or low vector?

There are definitely more changes beyond high vectors which break Aemulor; a few months ago I helped to track down exactly when things broke so that info about the relevant changes could be forwarded on to Adrian. (Unless Aemulor has been fixed to cope with those issues now? I’ll admit I haven’t been keeping track of when new releases have been coming out)

Looks like there’s a demand for a decent modern emulator.

This need/demand has been identified for a long time (see e.g. this bounty proposal from 2011: https://www.riscosopen.org/forum/forums/8/topics/660), but elegant solutions are difficult.

So what kind of thing are you good at? There’s more to life than assembler and C. E.g. although you might not be able to directly help out with a lot of the lower-level tasks, there are plenty of areas where a good software designer would come in handy.

I can program, but identify myself as a system administrator. With the exception of server-side applications, all the stuff I wrote is for personal use, aren’t for public consumption and never see the light of day. Due to this, they’re quick and dirty.

However, I have a lot of time on my hands now, and I want to develop my skills as a developer.

all the stuff I wrote is for personal use, aren’t for public consumption and never see the light of day. Due to this, they’re quick and dirty.

My stuff’s all originally written for personal use and is consequently quick and dirty, too. Some of it so dirty I’d be REALLY embarrassed to let anyone see it. But some of it looked as though it might be useful to others, so dirty as it is, it’s out there and people seem to appreciate it, and accept its filthiness, given that it’s free. Don’t be shy.

Obviously that’s all very well in an app – not so good in OS components!