ROOL Forum: Recent Posts

Wed, 08 Feb 2023 02:16:13 -0000

@ nemo

Like Basic they are not tied to a specific CPU. So they aren’t a problem. But unlike Basic they won’t have inline ARM assembly, so they’re even less relevant to this discussion.

Thanks for reminding me, I have Lua DASM/DynASM half ported by a while, forgot to finish the work, too many spare time projects. Lua however (through the aforementioned) can do in-line assembly and it’s way more powerful than what BBC BASIC can do (just for the record).

You mean native code sitting on disc? Why would you care?

True, and even more true if one think that the so called “binary” gets actually interpreted in a “lower” level form called micro-code.

Tue, 07 Feb 2023 22:07:25 -0000

Phone a friend.

Tue, 07 Feb 2023 21:24:49 -0000

How have I never been bitten by this?

OS_GSRead must not be used from user-mode in a TaskWindow or other pre-emptor.

When expanding SysVars during GSRead the Kernel uses a stack of expansion buffers to capture the SysVar value(s) and previous state. However, the Kernel never got the memo about there being multiple threads since 1988. So as it treats these buffers as a simple stack, callers will get the wrong pointer restored if any GSRead expansion is interrupted by any kind of context switch.

Trivial demo inadvertently swapping contexts by context switching during SysVar expansion:

This can be solved by storing all context within the expansion buffer and employing the buffer number field of the R2 state, and hence having in extremis multiple linked lists of state unambiguously pointed to by each thread’s R2.

Care will have to be taken with correlating state with buffer in the case of buffer reuse due to exhaustion.

Thank heavens CLI is the heaviest user of GST.

Tue, 07 Feb 2023 21:22:49 -0000

It evently has two sensors one each side.

By which means can you test which sensor is giving the correct result?

Tue, 07 Feb 2023 19:29:07 -0000

Why should I care which CPU I have this week?

That’s such a last decade way of looking at things. 😜

Why should I care what OS I have this week?
I use RISC OS for fun. But it’s not my primary OS or “daily driver” (ugh, horrible expression).
What do I do? Emails. Websites. Watching videos, my own ones or Netflix/Prime. Listening to music. Streaming radio. Once in a while, writing, but nowhere near as often as I should. And erratically my blog.

My primary OS these days is Android. On a phone or on a tablet. I don’t pick Android because I’m a fanboy, I pick it because I don’t like Apple because (note – my experience of Apple ended with iOS 7):

• Some of the apps I use (like NewPipe) don’t have Google’s blessing, for obvious reasons. But sideloading is easy to do.
• Too many bait and switch with apps, or greedy devs who turn it from an app with adverts to an advert with functionality. So prior to upgrading, I copy the app’s APK in case I need to roll back.
• My content blocking is “deny by default”. With Firefox this is easy. The real Firefox, I mean. Which leads me to:
• Apple’s overzealous “WebKit or nothing” stance. Browsers aren’t big free. Sometimes some wonky content can crash them (though this is less of a problem than it used to be a decade ago). On any other system, you know if there’s a certain site that crashes Firefox or Opera or whatever, just fire up a different browser and you’re good to go. Mom found out the hard way that I might have two browsers on my iPad (Safari and Dolphin), but it’s the same rendering engine inside so it’ll crash on the exact same things.
• Access to the user side of the filesystem that doesn’t require a desktop machine and blood sacrifices to the Old Gods.

But I also appreciate:

• Small form factor, I can take the device with me.
• Battery power. So can be used where there isn’t easy access to mains.
• Decent battery life, doesn’t conk out after an hour and a half.
• Supports things like Bluetooth (headphones or keyboard) plus WiFi to connect whenever.
• (or, in the case of a phone, mobile hotspot so my WiFi devices can piggyback off the 4G so I don’t need to worry about public WiFi)
• Plus, reasonable expectations. I found Apple to be mediocre hardware ¹ at premium prices.

With all of those considerations, my current preference is Android. These days I only use Windows for ripping DVDs and backups to harddisc.

So, today, my preference is Android. If Google crashes and burns or the EU decides to pull their finger out and roll their own OS… does it have a reasonably active app ecology? It’s there an SFTP app? Netflix? A decent music player? Browser with configurable blocking? The app my bank needs for their so-called security? ² Etc etc.
If the answer is yes, then I would have no qualms about moving to it.

My device does the stuff I want it to do in the way I’d like it to do it. You’ll notice my commentary on Apple was mostly things I didn’t like about iOS. Because it didn’t work in the way I would have wanted. But above and beyond that, it’s not that big a deal because really, when you get down to it, an OS these days is just the thing that provides the “look and feel” of the device and runs the software you choose to install. What it actually is? Far less important than what apps are available. ³

¹ My iPad Mini’s embarrassingly useless WiFi hasn’t yet been beaten. Even a €60 ebook and €25 internet camera can catch and hold a weak signal better than the iPad. Of course, encasing the thing in a big piece of metal probably wasn’t ever going to help, but “it looks cool”.

² I don’t particularly want a banking app, but as part of their especially awkward interpretation of the recent EU banking rules, they require that I periodically enter a special PIN into the app to, somehow, prove that I’m me. It’s worth noting that the other bank I use (I have two accounts) does not require all this crap.

³ As Microsoft expensively discovered.

Tue, 07 Feb 2023 17:06:03 -0000

Herbert missed several points with

how about Python, PHP, Lua

Like Basic they are not tied to a specific CPU. So they aren’t a problem. But unlike Basic they won’t have inline ARM assembly, so they’re even less relevant to this discussion.

I needed so many software updates for things to run on StrongARM

CPU-specific.

why I still need Aemulor to run publisher

CPU-specific.

make it run on current hardware natively

CPU-SPECIFIC

What does “natively” mean? I’ve been using a JIT compiling emulator for twenty years – so it IS running natively. You mean native code sitting on disc? Why would you care? What happens when your silicon changes?

Regardless of what you do to the Kernel, the programs it exists to run are written in ARM code and, as you described above, most are written in 26bit ARM code. So why are you rewriting existing Kernel code into another language to compile onto a specific CPU? The programs have to be emulated. What do you think you’re gaining by rewriting PrettyPrint in C, introducing new bugs and failing to match the API completely in the process?

This is such a Twentieth Century way of looking at computers! Why should I care which CPU I have this week? Android Apps don’t care about CPU. Web apps are written in JavaScript and Wasm. ChromeOS, Fuchsia, .NET/Mono and even Windows are multiple CPU.

Why would anyone think “We’ve learned the lesson of targeting one physical silicon design with ARM written on it by targeting this other one physical silicon design with ARM written on it”?

Make RISC OS virtual and it lasts forever.

Tue, 07 Feb 2023 13:55:32 -0000

More worrying, the lack of redundancy in the sensors, the push to try to make an aircraft that behaves in a fundamentally different way seem to be “the same thing” to make it more attractive to potential purchasers (if it’s not different, pilots don’t need training/recertification).
And, of course, America’s big aircraft manufacturer and America’s air worthiness auditor, both hand in glove with each other and asleep at the wheel.

It’s a culture that means if I ever fly anywhere, I’ll specifically ask if it’s a Boeing, because…it shouldn’t have taken two.

Tue, 07 Feb 2023 13:38:53 -0000

A. Yes, it’s possible to convert assembly language into C code.

Yes. It’s not hard to translate assembler into C.

The process involves understanding the assembly instructions and then mapping them to equivalent C statements.

No, the process is simply translating assembler into C that is logically equivalent.

There’s no understanding, so what you’ll end up with is a sort of bastardised version of the assembler code, written in C.

It will be as much a pain in the arse to maintain as the raw assembler. Perhaps moreso, as it won’t quite look like assembler to an assembler programmer, and it won’t look enough like C to a C programmer.

Additionally, the behavior of the resulting C code may not be exactly the same as the original assembly code,

Which is another way of saying No. ;)

due to differences in the way that C and assembly handle certain low-level operations.

Another problem is that the C runtime, if you’re actually going to use any of the useful parts of C, has certain prerequisites. Take a look at what CMHG does in order to bash a regular RISC OS entry point (SWI, vector, etc) into something C-friendly.

Given that pretty much all of RISC OS is an assembler API with a largely immutable format (you cannot randomly mess with other registers), I wonder how much C-ification is actually possible?

Tue, 07 Feb 2023 11:24:06 -0000

Hilariously badly – see https://www.riscosopen.org/forum/forums/2/topics/17593?page=3#posts-136657

Tue, 07 Feb 2023 11:06:56 -0000

I was thinking of being able to take out all of the grunt work set it on a task let it do all the boring endless stuff see what comes out the other end.

Tue, 07 Feb 2023 10:32:14 -0000

Watch the rest of the series.

The epsisodes are really fascinating.