No more big 32-bit cores for RISC OS from 2022

these people could be shut down with a single link to that vision and hopefully a plan to get to where the community wants to go.

I already gave you a link to the existing Roadmap document.
Have you read it?
What do you think needs adding?

Not wanting to add a second toolchain to build the product because some people might not need it is a pretty weak excuse for not doing it

A question of developer resources and priorities, methinks.

You do realise I’m talking about the situation 8 years ago? “this is exactly what I wanted to help avoid”

The interesting things about the 2012 thread that Gulli highlights are:

• Most of the developers contributing to it who aren’t around any more were prolific at the time, contributed a lot, but seem to have been advocating the “higher-level” approach,

• Most of the people who are still around are either still quietly using the “higher-level” approach, or are still vocal advocates of hand-coded assembler and Norcroft only whilst not being obviously active in actually adding stuff to the core of the OS,

• A strong argument against Terje’s ideas seems to have been that 32-bit ARM wasn’t going anywhere, and you were a fool to believe otherwise,

• Those who do contribute to the core of the OS seemed to take a far more nuanced view of Terje’s ideas, and didn’t dismiss them.

It’s interesting that new ideas and new people get dismissed out of hand. We’re keen to get new people involved, but:

• We shoot down people who tinker with the OS on hardware that they own,

• Argue with anyone who doesn’t share the “RISC OS Way” of doing things from the 1980s, and

• Reject out of hand any suggestions that those whose experience has been elsewhere for the past decade or more might expect things like modern dev tools.

You only have to look at the patronising way that people have responded to some of the “new” posters in this thread to see why people don’t hang around. “Your ideas are different to ours? Well, you can’t have been around here long enough to realise why you’re wrong, then.”

@ Stuart

“Daily Unstable Desktop”? Pish. We’ve had people successfully running businesses on Archimedes and successor systems for decades.

Yes also on the Commodore 64, and I still have people who reported running my code from the 90s (which I think it’s crazy lol). So, sure yes there are and there will be, but honestly does that means RISC OS IS stable and robust for the average Jo user?

Just as an example, I copied a CD ROM ( not even full, so ~500MB) in a zip file using SparkFS on RISC OS 5.28 (SparkFS allowed to use more than 32MB RAM) it worked till the very end and then when 0 bytes were left to copy the entire system crashed… This on a Iyonix, fully working fine, new PSU, 512MB RAM and powered via Pure Sine power unit.

So, Stuart I am not trying to argue with you ok? But are you absolutely sure you would recommend RISC OS Desktop over a Linux Desktop or even a clean Windows for stability? Just curiosity.

over a Linux Desktop or even a clean Windows for stability?

My experience with a live CD of Ubuntu – whatever is the one that annoyingly and counterintuitivly puts all the menus at the top like a Mac – was not good.

It failed to deal with my fairly generic sound hardware, while giving a smiley face to say all was well. Brasero (CD writer) ignored my chosen speed setting and burned at maximum speed, turning two discs into coasters in the process. A lot of things seemed bug ridden and unfinished. And eventually, for some reason, the whole thing threw in the towel with a kernel panic.

As for Windows, it’s better these days but the BSOD is infamous for a reason. Sometimes in the W95 era, ejecting a CD at the wrong time would bring down the system.

On my XP box, if I use a USB serial port (programming the ESP32) while the USB WiFi adaptor is connected, instant freeze. No error, just completely frozen.

In other words – systems can and do crash. They’re not supposed to, but it happens.

You do realise I’m talking about the situation 8 years ago? “this is exactly what I wanted to help avoid”

I, for one, am not criticising.
I’m simply asking what ideas you’ve got, what you would like the limited developer resource to look at.

A strong argument against Terje’s ideas seems to have been that 32-bit ARM wasn’t going anywhere, and you were a fool to believe otherwise,

Well, it got faster and erm, yes… 64 bit

But then if you look at things like that then you have to realise that 64 bit is going nowhere because 128 bit will be along in a similar time period and I’m sure 128 bit will be “so last year” and

Of course some of the “32-bit is going nowhere” comment will have come from people who didn’t want to let 26-bit go and hadn’t quite realised how many years it had already passed since the last 26-bit CPU was made.

So, here, now. 32-bit and hopefully move to a less limiting source language.

To do what?
Locked down, secure, stable and awkward to hack or
Open, insecure and easy to hack for study, learning, development.
Or both, somehow. Off the top of my head I mentioned a woolly idea earlier.

Most 64 bit chips (not just ARM) are have only 48 bit wide address buses, so there’s plenty of headroom before 128 bit is need – if ever (think about the size of the numbers). As for data bus widths, that’s largely uncoupled from the core ISA due to SIMD instructions and GPUs.

So 64 bit is going to be where the price and performance sweet spot is for a few decades yet.

I’m simply asking what ideas you’ve got, what you would like the limited developer resource to look at.

In a way that could come across as somewhat patronising.

If someone is asking about things that they could do, we’re not talking about the “limited developer resource” – we’re talking about them. So it doesn’t matter a bit if it seems useful to you, unless it’s also interesting to them.

In the case of the 2012 thread, there was no reason at all for Terje not to re-write the sprite code in C++ and benchmark it. They were clearly interested in writing and benchmarking it, so at the end it would be clear if it worked or not, and there was no obligation on ROOL to include their work in the OS anyway. And since they weren’t working on the OS in any other way, it wasn’t tying up the “limited developer resources”.

But no, that wasn’t to be. ROOL, Jeffrey and a few others were supportive, but other feedback was rather less so.

• At the risk of appearing a ludite, I can’t help feeling that moving away from Norcroft, when it has served us so well for this in the past, is a little too progressive.

• If C++ genuinely brings benefits in terms of stability without significant overheads, then I can see the desirability of that… if we can get the coders in to do it! — Er, you’ve got a coder offering to try it, and you’re telling them they’re an idiot?

• Since we’re talking about C and C++, I ran headlong into this over the weekend when going in to update the Mpro editor. Whilst the whole of Mpro and MsgServe is in C, the editor is in C++, using several template/class libraries. And I was only going in to add a “simple” extra button for something… Facepalm! — Huh?

• To quote Paul Daniels. Not a lot If it is not broke, don’t fix it.

• Who is going to rewrite an entire OS to be exactly what we have now, only a different language? — Er, there’s someone wanting to try a module and benchmark the results?

To be clear, there are all comments in response to someone who is spending their own time recoding a single module into C++ to be able to benchmark it and see how it compares to the ARM original. They’re not proposing to forcibly include it in the ROMs, or require anyone else to use GCC and C++. They’re doing it out of interest.

They’re proposing to spend their own time, as someone who wasn’t currently working on the OS, trying out an idea that interested them and might have given us all useful information at the end.

And still we drove them away.

Eight years on, going by the replies in this thread, we’ve learned very little. RISC OS is now Open Source, so if someone fancies tinkering with C++ or porting some of the OS over to another build system, the response isn’t “Seriously – I don’t have GCC here. I have the DDE, so I don’t have a need (I’m not interested in C++ and GCC can’t build the OS yet).”

The response is “Have a go – we can’t help with time, but if you need advice, we’re here and we’d really like to see how well it works”. In the end, there’s no requirement to use their work, but it might just prove very valuable indeed. And if they have fun doing it, that’s what matters.

But no, eight years on, the same faces from that 2012 thread are tutting at people for not buying ARMBooks, or telling people that their ideas are wrong because they don’t involve hand-optimised ARM code or Norcroft, or use ELF binaries.

It doesn’t matter. If someone is interested in something, welcome them and let them experiment, even if you personally don’t like the idea. By all means point them towards the “right” direction, prior work and resources that might help them along the way, but if they’re clear that they’re not interested in any of that, support them in tinkering with what they are interested in and consider the finished result if and when it arrives.

Oh, and remember that anyone coming new to the platform is going to be expecting better dev tools that the DDE plus Zap/StrongED and a bunch of folders on their hard disc. If they want to cross-compile and utilise the facilities that they can get via that, let them. It doesn’t affect you, and may just bring the familiarity required to keep the project interesting to them.

The learning curve for someone coming new to RISC OS code is likely to be steepish, so don’t add the complexity of having to lose the tools they’re familiar with as well.

Where’s the “like” button?

The clash of future visions is the other big reason why financial investment is required¹. Money doesn’t just buy labour; it buys unity and cooperation. People are far more amenable to doing things the “wrong way” if they get a cheque for doing so. (That’s partly the reason why we don’t have volunteer pilots, spacecraft engineers, etc, even though there are numerous qualified people who’d gladly do the job for free.)

¹ Where the money comes from is left as an exercise for the reader.

It doesn’t matter. If someone is interested in something, welcome them and let them experiment, even if you personally don’t like the idea.

+1

Seriously – I don’t have GCC here.

Just to clarify as it seems a bunch of different things have gotten mixed up here, my point regarding GCC is that I don’t feel that the existing build process needs two different and independent toolchains just because of one small bit of code. It’s a lot of added complexity.

However, what I feel should not be any reason for somebody not to try stuff. When something exists (the “show me the code” part), it can be evaluated on its merits.

or telling people that their ideas are wrong because they don’t involve hand-optimised ARM code

Citation? Because anybody seriously promoting the use of pure assembler has clearly failed to learn the multiple lessons of the last, oh, three decades?

or Norcroft, or use ELF binaries.

Well, if something is intended to be built into ROM, how well that thing can interact with the existing build process is a rather fundamentally important question, don’t you think?
And if it’s not intended to be baked into ROM, then this entire discussion is kind of moot. ;-)

Citation?

How about this? If you want more recent, then there’s been talk in this thread of re-writing it all in AArch64 not being a totally daft idea.

Well, if something is intended to be built into ROM, how well that thing can interact with the existing build process is a rather fundamentally important question, don’t you think?

Yes, and no. The fact that once again you’re raising this straw man suggests that you’ve either not understood, or that you’re still trying to impose your will on anyone who wants to tinker.

If someone wishes to rewrite the sprite handling, or anything else, in C++ and then benchmark it against the existing ARM code for their own amusement, that’s their call, and we should be welcoming them and encouraging them. It might not be fun for them if they did it in C, and they wouldn’t bother. It might not be fun for them if they couldn’t use the development tools that they’re familiar with, and they wouldn’t bother.

But if they do bother, in the way that they choose, then at the end of the project we might have some sprite code written in C++ with benchmarks, and we can decide what to do next. Is it fast enough? If it is, do we want to investigate how to use it in the OS build? If we do, how do we progress from there? Perhaps, with several months’ RISC OS experience under their belt, the person who did the work might be interested in making some of that their next learning project.

Otherwise, if we tell them to get lost or set the bar impossibly high at the start, we don’t get any of that. We don’t get the code, or the chance to hook a new developer, or anything else. We’ve just got our “Norcroft purity” and the same shrinking pool of developers.

Working on stuff in your own time has got to be fun, and interesting to you. After a time, that “fun” might include “helping out the platform”, but it won’t at first. And if something’s not fun, people go and do something which is.

And indeed let people write in C++, OO is certainly the way to go. Give them support.But if people want to contribute something in assembler ( 64 bit ) why no ?.

But back to 64 bit. Yes we should try to get RISC-OS working on 64 bit. But there are still 8 bit processors for sale ( 8051 for example )

How about this?

Read that; and when you look at the start of the post and the end Andrew seems to be pointing out the original reason for assembler and that maybe new machine are fast enough that the issue is no longer significant:

I certainly think making it more accessible is a good thing, but one must definately remember that the reason many chunks are written in assembler was for performance reasons.

and

But… maybe hardware is now speedy enough that the benefits of hand-optimised code aren’t as significant?

If you want more recent, then there’s been talk in this thread of re-writing it all in AArch64 not being a totally daft idea.

In which Mr. Swales side-steps the nomination to do the donkey work of what some see as a required step, and he thinks direct would be easier.

Then there’s my joke about Asperger’s (I have no idea where I sit on that spectrum, but if you can find me a person who is a techie, artist, musician that isn’t on the spectrum then I shall bow to the wondrous search abilities you have – and demand a retest)

and then there’s a vague suggestion from me that might spark something¹, or not.

So, in that I presume you were nominating Mr. Swales as the keen party? Although he doesn’t look that keen to me.

¹ Hmmm, Timo’s half interested.

B please.

I’d have thought most people would want C (both, depending on how you boot)

And indeed let people write in C++, OO is certainly the way to go. Give them support.

I agree the higher level language is likely to be more flexible and platform newcomers might have skills there already while ARM assembler isn’t an item you expect a Windows person to have.
My problem with the mental block on some of the ‘slightly more than basic’ concepts in C is my problem and counts for nothing overall.

But if people want to contribute something in assembler ( 64 bit ) why no ?

For the benefit of the future I think I’d rather they did it in C or whatever, but if they are set in an assembler mentality and this is something brand new – why not?

Is it possible to run existing SoC’s with different cores in different modes? (32 & 64)

It’s quite reasonable for an OS to specify that a single toolchain is used to build all the deliverable code, but only if it is up to the job. Norcroft is a fast and efficient compiler for integer C, and produces native file formats, but lacks support for the VFP and Neon, and has no meaningful C++ capability (CFront is a 1990s anachronism).

GCC supports all ARM integer and FP instructions, provides a migration path for building 64, has support for C++ and other languages. The draw back is non native file formats. LLVM/clang has similar advantages and disadvantages, but also a lot of very useful code analysis functions, and it would be very useful to port to RISC OS.

Given the above issues, the RISC OS build process needs to start incorporating a new toolchain, and eventually move to it exclusively.

As for 64 bit assembler in the OS, outside the bootstrap process and a few hand crafted bits of critical hardware vector code, I say no. It’s no longer the best way to produce code, as even besides the main reason of portability between architectures, it can’t take any advantage of new instructions and compiler technology.

Is it possible to run existing SoC’s with different cores in different modes? (32 & 64)

Yes. If an instruction to change mode is issued on one core, only that core is affected.

I upvote a lot of what SteveF’s said above. I think there’s a tension in ‘RISC OS modernisation’ due to those who fundamentally don’t want it to be modernised. They are quite happy doing things the way they’ve done it for 30 years, and they would rather things wouldn’t change. Meanwhile the rest of the world changes underneath them and RISC OS falls further out of step.

I had this issue when working on packaging. There’s a subset of users who are adamant that they absolutely don’t want any automation, and want to be hand-copying everything and keep track of their module versions in a spreadsheet. That subset is rather vocal. What you don’t hear from is the set of users who have been installing apps on other platforms using app stores for years and wouldn’t know what a module is, let alone how to install one. That group is very much larger (since it covers people who don’t use RISC OS) but they don’t have a voice because they aren’t RISC OS users yet, and would be turned off by this kind of thing if they tried.

As Steve says, just let people do their personal thing, make that as easy as possible, help them where they get stuck, and review their pull requests if they come. If they don’t come, then someone had some fun on their personal project and the rest of the world doesn’t need to worry about it. The bazaar, not the cathedral.

It’s also worth saying that I have a use case for spending a little work time on RISC OS – if it were AArch64. It isn’t, so it doesn’t work for my purposes.

I think there’s a tension in ‘RISC OS modernisation’ due to those who fundamentally don’t want it to be modernised. They are quite happy doing things the way they’ve done it for 30 years, and they would rather things wouldn’t change.

I used to think that. But my view now is that I am happy to see RISC OS develop. And, if does go somewhere I am not keen on, my Rasberry Pi 4s and 5.28 will probably last longer than me.

Read that; and when you look

Yeah, there seems to be an aspect of cherry picking historical quotes mostly devoid of context.

Yes, and no.

Clarity. Good. That’s helpful.

or that you’re still trying to impose your will on anyone who wants to tinker.

I have no problem with people who want to tinker, fiddle, back, or rewrite the Wimp in Ada.

But what happens next ?
Oh, wait, forgive me for thinking ahead…

might not be fun for them if they couldn’t use the development tools that they’re familiar with,

Which raises the question – what is ObjAsm/cc/Link written in? What might (and this is just an idea) benefit us is if the toolchain was able to run on x86 (under Windows, under Debian…) so that people can use the sorts of tools that we’re lacking to build bits.
And given how quickly the average installation of 7zip can run (compared to what we have), I would imagine it’d be a heck of a lot quicker too.

That’s not to say flawless, there’s no x86 BASIC unless Brandy is up to the job ¹, and those pesky filetypes to sort out…

But there are still 8 bit processors for sale ( 8051 for example )

In your average bread maker or toaster, anything more than that is overkill. You’ll note that it’s either an 8051 clone or something in the Sam88 family, with maybe a couple of kilobytes of Flash and if you’re lucky, 256 bytes of RAM (and some of that are actually internal registers). You will, on the other hand, have a slew of timers, ADC channels (but probably only one actual ADC) and a bucketful of digital I/O.
They’re still hanging in there because when response time isn’t actually that critical, even the Cortex-M series is overspecified.

I’m not sure I’d want to see a 64 bit processor in a toaster. Damn thing would probably run a ten line Perl script for the toast functions, and forty seven other processes for the built in spyware.

Then there’s my joke about Asperger’s

That’s the point exactly. If a person is a jerk, they shouldn’t play a sympathy card in a place where a good number of the people are probably undiagnosed with exactly the same thing.
Plus, it gives those who actually have the condition in various degrees a bad rap.

I have no idea where I sit on that spectrum,

I “probably am” but when I was young, it was not something that anybody chose to admit to. All sorts of euphemisms instead (like “special” or “different”).

As to where on the spectrum? That part is easy – Cerulean. ;-)

due to those who fundamentally don’t want it to be modernised.

That’s why the 64 bit question is fascinating. The platform either stays as it is, under emulation, sort of frozen in time…
…or it makes its way to the new architecture, which is different enough that it’s worth rethinking parts of the API. Maybe, just maybe, we can finally put the lingering bits of the MOS to bed.

and they would rather things wouldn’t change.

Might explain those still using RiscPCs.

Meanwhile the rest of the world changes underneath them and RISC OS falls further out of step.

Don’t bother closing the stable door. That horse has not only bolted, it died of old age, got buried under stagnant landmass, and is now being extracted to refine as middling grade diesel.

and wouldn’t know what a module is, let alone how to install one.

Oh, I don’t know. Until sort of recently various installers for Windows were quite notorious for not correctly dealing with adding DLLs to the system so that “removal when count equals zero” could trash installed applications.

Don’t forget, also, that RISC OS has a long history of “open archive, drag app somewhere, installed”.

That said, as more stuff uses the shared libraries, there are more complicated dependencies, which would be a pain to sort out manually. Having that automated is only going to be beneficial.

¹ I don’t count BBfW as we’d want something platform agnostic to cater for Windows and Linux (and maybe Mac?)