RISC OS on the RPi4, RPi 4

@Clive it sounds more like you are making rainbow tables, for some nefarious hacking purpose no doubt. You could use Python instead of BASIC, it has no problems with 64bit, I’ve been filling up a 192GB system with snakes recently.

The Pi certainly wouldn’t be the ideal machine for actually doing that factorizing,

Oh, I don’t know.

Maybe not, but I do. The ideal machine would have terabytes (or more…) of very fast memory, a 64-bit (or more…) wide address bus, a 128-bit (or more…) wide data bus, plenty of 128-bit (or more…) registers and original-ARM-like integer arithmetic instructions with carry bits so you can chain the integer arithmetic for very large integers (as you can on the original ARM…) – and thousands of CPUs you could give sub-tasks to. Don’t need symmetric multi-processing, one boss CPU and thousands of slaves would be just fine.

But don’t ask me to write the programs for that. I wrote them for a RiscPC, and will probably update them for (one CPU of) a Pi4 at some point, but beyond that – over to someone else.

Back in RiscPC days I wrote the heavily-used loops in assembler. I might rewrite them in 32-bit assembler – I’ve not actually rewritten them in BASIC yet.

You know, I hope, that “rewriting them in 32-bit assembler” might be as simple as simply using MOV instead of MOVS to return to BASIC?
Basically (haha, see what I did there?) the parts you need to look at are anything that messes with PC thinking there’s a PSR in there, and anything that expects flags to be preserved over function/SWI calls.

If your code isn’t written to do weird things, then you might find there’s actually very little that needs done to “32-bit” it.

Take a quick peek at https://heyrick.eu/blog/index.php?diary=20201003 (code at the bottom). It’s my tool to dump the MEMC page tables. Written on a Pi, runs on an emulated A305 running Arthur 0.30 and the Pi2 ¹. 32 bit ARM and 26 bit ARM are pretty much the same thing. :-)

The ideal machine would have […ridiculously over the top spec…]

Until a few years from now, when you’ll be back complaining that your 128 bit bus just doesn’t transfer the data quickly enough. :-)

¹ It doesn’t get very far as there’s no MEMC in a Pi, but it starts up and exits with a message and doesn’t go wonky.

If your code isn’t written to do weird things, then you might find there’s actually very little that needs done to “32-bit” it.

Oh, I’m sure that’s true – after all, I wrote the 32-bit architecture reference manual instruction set chapters. I’ve just never got round to it. One little issue is that the code is … ummm … not very well documented, since I never expected to pass it on to anyone else, or even keep it beyond what I thought was a fun little project. And I’m rusty as hell on Assembler, full stop.

I tried to interest Acorn User in an unlimited precision calculator application, but when they said, “only if it’s floating point”. I thought for a little while about that. It’s feasible, of course – a perfectly reasonable extension of the unlimited precision integer arithmetic, and my integer routines include x^y and MOD(x^(a/b)). Oh, but trig functions? And logs (natural and otherwise)? Umm. That would mean WORK…

The ideal machine would have […ridiculously over the top spec…]

Until a few years from now, when you’ll be back complaining that your 128 bit bus just doesn’t transfer the data quickly enough. :-)

Oh, indeed. The more OTT the spec, the more ridiculously big the products of ridiculously big prime numbers that you could factorize (in finite time) would be – and the more insight you (might) be able to get into more and more cunning tricks to do it.

But short of quantum computing doing magic, or some new mathematics that breaks a lot of pretty well-established understanding, factorizing the products of really big primes will remain forever out of reach. You can go further and further and faster and faster with ever higher-spec machines, and perhaps with ever more cunning tricks, but the hill just keeps on going up forever. And all for what? Apart from burning the ecosphere to a frazzle…

Are there any comparisons between the RPi 4 and other RISCOS computers, particularly RPi 3, as regards performance?

Chris Hall’s site has romark benchmarks for pretty much all the current RO hardware.

https://www.svrsig.org/HowFast.htm

Here are the highlights of the pi400, pi4 and pi3 columns

                Pi400      Pi4        Pi3
Processor       2527%      2187%      1615%
Memory         35649%     34608%     15170%
Rect Copy        535%       535%       521%
Icon Plotting   2849%      2830%      1681%
Draw Path       1005%       949%       580%
Draw Fill        196%       181%       143%

Something to look out for is if you use a basic USB KVM, something in RO crashes on the Pi4 which seems to kill USB. So there’s no way to click the button to find out what does it
Also I can’t speak for anyone else, but ObjAsm just seems to hammer the CPU and lock up on the 4.

Are there any comparisons between the RPi 4 and other RISCOS computers, particularly RPi 3, as regards performance?

I’ve found the Pi4 to be around 2.5x to 3.5x as fast as a Pi3 on a range of C, C++ and Python programs. That is at the default clock speeds, the Pi 4 can be overclocked to 2GHz for an extra 25% performance.

Something to look out for is if you use a basic USB KVM, something in RO crashes on the Pi4 which seems to kill USB. So there’s no way to click the button to find out what does it

I experience that with an electronic USB switch, I’m still attempting to get some evidence of the crash location, if and when RISC OS isn’t totally hung.

Also I can’t speak for anyone else, but ObjAsm just seems to hammer the CPU and lock up on the 4.

I’ve not noticed this, is there any particular source file which exhibits this behaviour?

Thanks for response. I will look at Chris Hall’s website.
I read somewhere that the RPi400 keyboard is not very good. Is that so?
Is the ethernet transfer rate much faster on the RPi4 than on the RPi3?

@David R. Lane
The Raspberry Pi 400 keyboard is not wonderful, and this is coming from someone who uses cheap Chinese membrane keyboards all the time, so normally not fussy. Its a bit ‘hard’ with little key movement when pressed. You get use to it, but it takes you by surprise, as if the keyboard feels ‘stiff’.

So, is 4GB the maximum size of RAM for RISC OS on the Raspberry Pi 4?
I will also need to run Linux on the Raspberry Pi 4, and so would like the maximum RAM size compatible with running RISC OS too.

I think if you get an 8GB Pi4 (good for Linux) then RISC OS will work but simply ignore half the memory at the moment.

So, is 4GB the maximum size of RAM for RISC OS on the Raspberry Pi 4?
I will also need to run Linux on the Raspberry Pi 4, and so would like the maximum RAM size compatible with running RISC OS too.

Ahem… if you’re at the show (or even if not!) we may have something right up your street!

Err …., like the FOURtress?

Exactly like the FOURtress! Special show price, too!

@David R. Lane. The FOURtress is so good I have ordered another one to be ready for ’Paolo’s OS’ :-)).

Regards Ron.

To misquote NTNOCN: “I think the (FOURtress price) is far too low. I would willingly sell my house and all its contents to help the BBC^H^H^H RISC OS hardware development!”

To misquote Black Adder (very badly): “Done! It’s a deal!”

would willingly sell my house and all its contents

Let’s see, house is worth X, disposal of the crap inside costs Y. Therefore X – Y equals… oh crap, I’d have to pay somebody to take the house and its contents…!