Norcroft 64

I sometimes kick myself for overlooking things, but these issues now bugger me;

Norcroft 64 can be used by existing RISC OS compilers to compile existing 26/32-bit RISC OS programs to be compiled for (Arm, whatever) 64-bit CPU’s but RISC OS won’t run since it’s mostly assembler code? Are we in luck since RISC OS is a microkernel! and not require too much work for a little GitHub team (knowing early Arm asm,+Modern C) to at least have a text interface. and then work fro there? And it can hardly be a cosmic top secret what language(s) are used for Relocatable Modules, but if it’s C we’re home dry. Nearly.

microkernel

That doesn’t mean what you think it means.

these issues now bugger me

That really doesn’t mean what you think it means.

these issues now bugger me

That really doesn’t mean what you think it means.

No, but it probably counts as a fine example of normalcy¹ – at an angle to the real world – as well as providing unintended amusement²

¹ A word first abused by an American President who apparently couldn’t find “normality” in his dictionary

It’s no denying that the number of users has taken a dramatic nosedive since Acorn’s untimely demise for reasons we all know. In danger of repeating myself, I believe the only way to possibly turn this trend is for some pensioned(!) RISC OS Asm/C programmers to join forces on GitHub and rewrite the whole shebang in C (to make it a bit future-proof!) and compile it for 64-bit Arm CPU/GPU’s and also do an emulator for backwards compability. Otherwise the downward trend in users will result in a too small marketplace to support existing RISC OS-related companies. And that’s not a fate any supporter of arguably the most productive user interface wish to see.

Nah, in Wibble++

blah … C … blah … 64-bit … blah … GitHub … blah … marketplace … blah

Er, Bingo! … I think…?

I wish the downward trend in users would include the one three posts ago.

Nah, in Wibble++

Is that the Objectionably Oriented one where the AI IDE tells you Foxtrot Oscar if you ask it to do something beyond its capabilities?

I’m scoffproof and also achieved graphical feats for print over PostScri pt. Met Edward Detyna once (of EFF) who quipped “I have seen grown men cry trying to print PostScrift files..” – priceless. But I never had trouble there, including printing to film for printing.

Something RISC OS software is brilliant at is “Desktop Publishing” for professional printing. A font rendering system second to none. So that’s a main argument for getting such a system, even 32-bit. But 64 is better.

A font rendering system second to none.

Nemo! Nemo! You around, nemo?

Please come smack a clue into this guy.

I keep suggesting that we do not feed the troll.

Druck, I think he’s going to give up after his 64th comment or something but I haven’t being reading too closely. I found an old version of the Cerilica website and Vantage looks absolutely amazing. Is there anything modern that can beat that on any platform? Apologies if that’s a controversial statement? No-one ever mentions Vantage. Definitely looks worth the asking price back in the day. I think mr. s may have a valid point about RO software.

Vantage could have been fantastic, but it was too flaky for me to do anything with, and I tried.

I found Vantage to be rock stable when using it on my Risc PC, could do some nifty graded transparencies and stuff not easily achievable in ArtWorks unless Wizard Martin Wuerthner has swung his magic wand lately after I went Linux. Which doesn’t hold a candle to the productivity of the RISC OS user interface and software.

Mr s. by coincidence i’ve been thinking about the RO’s GUI tonight quite a lot. I wasn’t able to put it into words so I was unsuccessful in my analysis. Without emotive words like, but probably true, majikcal. Can you describe specifically what it is about the GUI that makes it productive please, without drag and drop and great applications? I ask because I notice you keep saying that RO is productive. That’s great I feel that way too. You may need to describe your workflow a little? Maybe we could take this chat out of the complier area and then others with our specific interest in RO could contribute? The offers there if you want to chat in another section. Sorry to use one of your replies up.

Mr s. …

As others have already said upthread:

I keep suggesting that we do not feed the troll.

There has been a large number (nearly 4700) of views and posts (115) on getting RISC OS to run on ARM 64-bit architecture, so is it a suitable project for a bounty? Some say ROOL has being doing some work on it, if so, what?
This is so important for the future of RISC OS can someone from ROOL make a statement on the matter?

There is this

Thanks, Mikko, I wasn’t aware of the document.
I would still like to know whether it is a suitable project for a bounty, and, whether or not it’s a bounty, will it be expensive?

I would still like to know whether it is a suitable project for a bounty.

No, it’s probably many bounties.

and, whether or not it’s a bounty, will it be expensive?

Yes, yes it will.

I keep saying: Imagine rewriting RISC OS from the ground up to work on a MIPS processor ¹.

That ought to give you an idea of the degree of complexity involved. ARM64 is not a superset of ARM32.

My personal feeling is that the most realistic scenario is leaving the OS alone and working on an emulation solution that works better with whatever the actual hardware is, rather than pretending to be a RiscPC.

¹ Or x86 or RISC-V whatever, just some processor that isn’t ARM as we currently know it.

Will ROOL and ROD each produce their own, different, solutions? :-)

There is this

Personally, I think the proposal feels too focused on adopting a 64-bit address space and downplays the other solutions that would address the problem of hardware availability with (somewhat) less complexity. Not enough applications exist or are likely to exist that would justify the larger address space IMHO – plus, considering that not many current RISC OS machines actually have more than 4 GB of RAM, the increased pointer size would negatively impact the RAM usage of applications like Iris on existing machines.

Additionally, it still leaves a lot of questions. I know it says that the conceptual design is only 20% complete, but I can still think of a bunch of things that may either hurt backwards compatibility or make things significantly more difficult for programmers:

• How would pointers be represented in 32/64-bit neutral BASIC programs without breaking support for older RISC OS?
• How would mixed BASIC/Assembler programs work? Would it still be possible to generate 32-bit modules this way, or would it only be able to support the native architecture?
• How would 32-bit only BASIC programs be identified to allow emulation to take effect?
• How would SWIs that require callbacks or expose function pointers work since they directly expose code for the architecture that the module or executable?
• Would it be necessary to mix AArch32 and AArch64 code into the same executable or module to handle that use case? Mainstream toolchains tend to make this quite difficult.
• If the structures used by SWIs differ in size between 32-bit and 64-bit programs, how would this be handled in scripting languages like BASIC, Python, Lua or Perl?
• Are C/C++ developers expected to supply multiple variants of all applications for 32-bit and 64-bit machines, or will this only be needed for heavier applications? It’s a bit of a testing and maintenance burden to provide multiple builds.

Personally, I think the best approach here is 3, with 5 as an extended goal for certain components where the extended instruction set would come in handy or the overhead of emulation would cause severe performance hits (like Iris). I just can’t think of a case where the benefit of 64-bit pointers outweighs the complexity of getting it to work with existing programs. I’m happy to be proven wrong, though.

I keep saying: Imagine rewriting RISC OS from the ground up to work on a MIPS processor

If RISC OS is going to support AArch64, it would probably be wise to design it to be fully architecture independent so that it can handle whatever future architecture is new and trendy without requiring further design changes.

the conceptual design is only 20% complete

That just means there were five proposals and they picked one. ;)
We’re ridiculously far from anything that looks like code…

can still think of a bunch of things that may either hurt backwards compatibility

That’s why my preferred solution is emulation. Yes, it leaves RISC OS pretty much as it is right now, but let’s face reality. There’s what we would all wish for, and there’s what’s actually possible, and the two are really distant from each other (and, no, a ragtag group of motivated pensioners aren’t going to fix that).

it would probably be wise to design it to be fully architecture independent

Yes, I fully agree and have said that any future RISC OS needs to be processor agnostic. Like, if it’s going to be rewritten, it needs to be done correctly this time around.

It takes about two seconds further thought to realise that this means waving goodbye to the entire existing API (how do you do SWI on a machine that may not have such a thing, and/or different registers?), and with it, pretty much all software. A couple of seconds more thought would tell you that there’s no way in hell user mode code should be able to interfere with kernel memory (so there goes the RMA) and, ideally, third party modules should be segregated from the kernel as well so a problem there does not slaughter the kernel (so there goes the RMA again).

Do you have any idea how many user mode programs mess around in the RMA? It’s where poll words live, it’s where untold bits of the OS hand out pointers to data in return to SWI calls.

And, of course, the entire system needs to be reengineered to modern concepts such as the OS telling the program what to do, not the other way around. The OS needs to (excuse me) “take back control” (sorry). One of the major factors here would be pre-emptive multitasking, which the current Wimp API doesn’t cope with (consider how registered messages are passed around, or redraw requests).

All of which are, you know, a big pile of deal breakers.

I think the best approach here is 3, with 5 as an extended goal

I think the most realistic approach, given our limited resources, is 2.

To put this into context, work is advancing on WiFi support, that has been present on hardware since 2016 (eight years ago).

We still have no system-wide utilisation of “the other three cores” and they’ve been around since 2015 (nine years ago). Think how much faster Iris could be if the work could be spread across four cores instead of stuffing it all into one. Recent RISC OS hardware (Pi 3B+, 4, 400) isn’t that different in spec to a low-end Android tablet.

We’re still wasting huge amounts of time in C programs emulating an ancient FP chip instead of using the VFP which has been available on (IIRC) everything post-Iyonix. The Beagleboard had it back in 2008 (sixteen years ago). Both BASIC and ABC have been given VFP capabilities leading to the slightly absurd situation where BASIC compiled with ABC can easily outperform anything written in C if it needs to crunch numbers.
There’s a reason my experiments with ray casting was written in BASIC. C just wouldn’t cut it. The FPE took far too long.

So with all of that in mind, “just make a 64 bit version” is, I think, seriously underestimating what is going to be involved.

And, anyway, if we’re talking about preserving as much of the current API as possible, then this implies carrying on the inherent design deficiencies that have been an issue since the ’90s…

Security and stability are the words these days, especially in the modern connected world. RISC OS offers neither and the only reason it hasn’t become a zombie toaster is because it’s far too obscure. But obscurity is no security at all, just “luck” and “hoping”.

How would pointers be represented in 32/64-bit neutral BASIC programs without breaking support for older RISC OS?

Is it possible to have a 32/64 bit neutral program? What happens if you set -1? That’s an easy way to set &FFFFFFFF. Will this be preserved, or will it become &FFFFFFFFFFFFFFFF? Which will TRUE be, and will the two equate? BASIC has no inherent support for casting, so if a 64 bit TRUE is different to a 32 bit TRUE, difficulties will ensue.
But, then, you can’t just think “oh, it’s comparing with a 32 bit, we’ll chop off the top half” because the top half might be different. &7FFFFFFFFFFFFFFF is not TRUE and shouldn’t equate to it.

would it only be able to support the native architecture?

Given how different ARM64 is, I think only supporting native architecture is the logical approach. There is plenty of precedece, BASIC has only ever supported the native architecture, be it 6502, Z80, or ARM…

How would 32-bit only BASIC programs be identified to allow emulation to take effect?

Probably assume that all are unless it makes some sort of specific call to say otherwise. You can’t retrofit the past, but future code can say “hey, I know this”.

How would SWIs that require callbacks or expose function pointers work since they directly expose code for the architecture that the module or executable?

Is the service call API going to look anything usefully like the one in current use?

Would it be necessary to mix AArch32 and AArch64 code into the same executable or module to handle that use case? Mainstream toolchains tend to make this quite difficult.

I think it’s probably best to keep the two separate. Again, other differences might require this to be so.

We got very lucky in that ARM32 wasn’t that different to ARM26. This isn’t the case now.

Are C/C++ developers expected to supply multiple variants of all applications for 32-bit and 64-bit machines, or will this only be needed for heavier applications? It’s a bit of a testing and maintenance burden to provide multiple builds.

True, but look at it like this: Would developers be expected to supply multiple variants of all applications for x86 and ARM machines?

The 64 bit ARM is ARM only in name. In terms of what it is and how it works, it’s a very different beast.

The OS needs to (excuse me) “take back control” (sorry).

Heavy emphasis on the OS_Exit then :)