RISC OS Open
A fast and easily customised operating system for ARM devices
ROOL
Home | News | Downloads | Bugs | Bounties | Forum | Documents | Photos | Contact us
Account
Forums → General →

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

Subscribe to No more big 32-bit cores for RISC OS from 2022 520 posts, 46 voices

Posts per page:

Pages: 1 ... 11 12 13 14 15 16 17 18 19 20 21

 
Dec 22, 2020 4:15pm
Avatar Terje Slettebø (285) 243 posts

I notice that DavidS has got a fair amount of “flak” for his view, drawing comparisons with Flat Earthers and the like.

I must admit that before I had read more of his postings, where he described in more detail his ideas and the reasons behind them, his support for the 32-bit ISA made me wonder if he was some kind of Luddite, stuck in the past.

However, having read his later postings, I realise he’s neither a Flat Earther nor a Luddite, quite the contrary. For me, he’s a visionary, and as such, you tend to attract a fair amount of criticism from those who support “status quo” (AArch64).

I’m reminded of this quote:

“It ought to be remembered that there is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things. Because the innovator has for enemies all those who have done well under the old conditions, and lukewarm defenders in those who may do well under the new.”

- Niccolò Machiavelli

I’m all for experimentation, especially when the best way ahead is not clear at all.

Yet, we also know what choice ARM Ltd has made, so it may not be wise to put all our eggs in one basket, something David readily admits.

Thus, I think there is space for going in both directions, meaning exploring a potential new 32-bit ARM ISA processor, while at the same time looking into how we may move our beloved OS to run on 64-bit platforms.

Thus, I very much welcome @tymaja’s initiative, of somehow booting a 64-bit ARM in 64-bit mode, running RISC OS in a 32-bit mode segment/core, and then starting to look into how we might write 64-bit running on RISC OS.

That’s the motivation for having recently acquired a Raspberry PI 4, myself: To be able to start playing with 64-bit ARM code.

As I’ve mentioned elsewhere, I also intend to look into the possibility of making a version of the extASM assembler for 64-bit code, meaning we’d be able to assemble 64-bit ARM code under RISC OS.

 
Dec 22, 2020 5:04pm
Avatar Charlotte Benton (8631) 86 posts

It’s ultimately a coffee vs tea situation, in that neither side is “right” and neither side is “wrong”.

RISC OS 5.x will still be here if some people depart to pastures 64-bit, and likewise, a project to create RISC OS 7 (or whatever a 64 bit version might be called) doesn’t need everyone to be on board.

 
Dec 22, 2020 5:07pm
Avatar DavidS (1854) 1863 posts

It’s ultimately a coffee vs tea situation, in that neither side is “right” and neither side is “wrong”.

Thank you for that. What I have thought as well.

 
Dec 22, 2020 6:20pm
Avatar Rick Murray (539) 10289 posts

as I am getting tired of arguing the same thing

The simple answer is… don’t argue.
There are those who wish to consider a potential port of RISC OS to 64 bit processors. And, obviously, those who would prefer to say with the platform as it is now.

Ultimately, one is not going to replace the other because it’s unlikely that with the exception of simple BASIC programs, any 64 bit incarnation is not going to be in any way binary compatible and may well have a notably different API.

ARM as in the 32bit ISA

Call it ARM32 or something, because AArch64 is ARM too, only different.

is likely to still be in new products for at least the next ten years before the switch to application level AARCH64 is complete.

Citation needed. And please don’t say, again, that one can still buy ARM7500 or whatever it was. Those are likely left-over chips in inventory. Not something actually being produced. Not something actually being used.

Meanwhile, in the world, mid and higher end Android phones and most (all?) current Apple phones have already made the transition. I can imagine it slowly trickling down to the lower end hardware. As ARM have put an actual end date on 32 bit, this transition will only accelerate.
Even on the Pi family, for the last two major versions there has been a choice of 32 or 64 bit.

We have zero reason from my view to run from our ISA to something different. We should be spending this effort on modernizing RISC OS as an ARM OS.

The thing is, we’d need to toss out most of the existing codebase in order to make a transition to 64 bit, so this offers the potential of an exciting journey in which RISC OS can be redesigned with regard to modern practices and not what was “the way” in 1982, plus recreating it in a higher level language (probably C as we’re not exactly blessed with lots of compilers), plus a potential wider range of available hardware. If the new RISC OS is not as firmly tied to the processor architecture as it is right now, it ought to be possible to backport it to 32 bit ARM, or maybe even to x86? Okay, that last one is a bit left field, but if it is possible then one could say we’re doing the remake correctly.

Again, there are people still happily using functional RiscPCs; so if we all run off and install RISC OS in place of Windows (well, I can dream…) this doesn’t mean that RISC OS 5.28 running on your Pi2, Pi3, Pi4 (etc) will suddenly cease to exist. They’ll still be there, and there may be a number of people who choose to stick with the old simply because learning a whole new system and API is just not something they can be bothered to do. Some will, some won’t. It’s natural.

Trying to make it an AARCH64 OS is a waste of resources that could be better spent improving it as a ARM based Operating System.

I will agree that a rewrite for 64 bit ARM is a pretty long shot, given that RISC OS has survived for far too long with what is pretty much volunteer effort – I’m not demeaning this, I’m just pointing out that the smallish amount of work “around other (paid) work” is the reality, so quite how an AArch64 bit version would actually happen is… um… yeah… oh look, a unicorn!

RISC OS does indeed need improvement. A lot of improvement. But this doesn’t mean that we should simply forget about any “going forward” in terms of ARM evolution. Looking at stuff that has been done along the way, it looks like rather a lot of it is “scratching a personal itch”. Look at the project to get RISC OS running on Linux. Look at Gerph’s pyro server. None of this had to happen. But they did because somebody thought “hmm, wouldn’t it be nifty if…”.

RISC OS needs a lot of modernisation. But this shouldn’t preclude the possibility of evolution.

getting my CPU documents retyped and up on my site.

You know anybody with an all-in-one printer? A quicker solution might be to simply scan the documents and make them available as PDF or JPEG images?
Alternatively, there may be people around these parts who could do some OCR on them of they’re printed and not handwritten?

Coming back to people attempting to flee the ISA has been exhausting at the least.

and:

then the one that every one trashes, as a waste of time by everyone that has coded for it in the last 20 years, will still have a use to someone.

You say things like that and then wonder why people get upset with you.

Nobody is “fleeing” anything. If, and it is a BIG if, RISC OS starts to make realisable plans for a 64 bit version, the existing 32 bit will still be around.
It will still be open source.
It will, likely, still be built at regular intervals for those using machines that are not 64 bit compatible.
And, as such, I can imagine people will still provide code and bugfixes and such for it. It may receive less “official” support because “exciting new project” and all, but it isn’t suddenly going to vanish.

Likewise, to suggest that everybody who has coded for the current RISC OS for the last 20 years has been a waste of time is, frankly, offensive.
32 bit RISC OS is right here, right now. All of the work leading up to this point is available to run on the machines we’re using today.
Is that somehow insufficient? Inadequate?

I am even working on an outline to add a desktop environment more Atari like in nature once the other Atari stuff gets far enough,

You accuse those of us who think an AArch64 version as a good thing of “fleeing”, pointing out numerous things about the differences between 32/64 that are basically complete fabrications, and yet at the same time you want to turn it into some sort of Atari clone?

And as for the Atari desktop… you mean something like this?

Or: http://xaaes.gokmase.com/images/screenshots/mathias1.jpg (1679×1049)

Wow – in terms of visual appearance, it looks even more dated than RISC OS! I don’t know what to say, so I’ll just stop here and go cook some farfalle…

 
Dec 22, 2020 7:05pm
Avatar DavidS (1854) 1863 posts

Thus, I think there is space for going in both directions, meaning exploring a potential new 32-bit ARM ISA processor, while at the same time looking into how we may move our beloved OS to run on 64-bit platforms.

I agree with that view.


Citation needed. …

Ok as you are attempting to twist meanings AGAIN, not going to even attempt to argue.


Ok herein is an attempt to one last time be clear in my view on this issue, as I am getting tired of arguing the same thing:


ARM as in the 32bit ISA we have all been using for the last 33 years, is likely to still be in new products for at least the next ten years before the switch to application level AARCH64 is complete.

This gives those in the community plenty of time to get work done on a CPU design to replace the ARM, while being 100% ARM ISA.

I am even going through all my CPU design notes so that the research that I am aware of or have been involved in can be taken advantage of. As I retype this largely hard copy data, I am being careful to format it in a way that will be usable so that it can help move our platform (ARM not the new one) forward.

We have zero reason from my view to run from our ISA to something different. We should be spending this effort on modernizing RISC OS as an ARM OS. Trying to make it an AARCH64 OS is a waste of resources that could be better spent improving it as a ARM based Operating System.

Arguing this point of view is taking time that could be better used by me getting my CPU documents retyped and up on my site. A better break time is to work on my software instead of the restating my point ten-thousand times in response to strange re-twistings of the argument. At least I am attempting to spend some time on something that can keep our ARM32 OS around.


I am keeping a close eye on what is going on here, and will continue to do so. My plan in getting my health back and pushing back into the software world was to get some good RISC OS stuff added to the mix, at least in some manner. Coming back to people attempting to flee the ISA has been exhausting at the least.


By any one that looks it may be noted that, while not up yet, there is note of work towards some level of Atari compatibility. The primary reason that I have started on that road is in case RISC OS does attempt to jump ISAs, will still have a use to someone. So what if that someone is Atarians, if it comes to this point it would be looking like RISC OS users no longer want it. Though the hope is that there will be plenty of good users left, as there are good ones out there.

I am even working on an outline to add a desktop environment more Atari like in nature once the other Atari stuff gets far enough, as it may be the only thing left on RISC OS (Atari ST Support that is). We have always had more Atari stuff than many OSes, though we had also our own stuff.

So I push forward not only with my RISC OS stuff, though also with a layer that brings Atari over to RISC OS in a more direct way. The reason that RISC OS users are talking about running for a new ISA, so I may end up one of very few left. If that is the case may as well mix two of the ones I like together into one.


Paths forward we may not agree on. That is alright by me, so please do not try to invalidate the possibility I say. I support the decision of those that wish to go AARCH64, I will not be following, and I hope there will still be a reasonable of RISC OS users left on the ARM (ISA of 33 years age).

The path forward that I look at is the improvement of the OS we have, running on ARM32bit. And finally having the opertunity to play in assembly language without limit, as the ISA for ARM 32bit is never to change again. That is to say there will never be an incompatibility in future ARM 32bit CPUs, we know the ISA in every form it can take (from ARMv1 [a bit rare] through ARMv7 ISA, including the good idea to avoid SWP on newer ARM ISAs, though use it on older for multiple bus master systems).

The other paths forward, which I fully support, even if they are not of personal interest are:

  • An integrated system that is both Linux and RISC OS, almost an WINE though for RISC OS instead of Win16/Win32. This one could be interesting to see how it goes.
  • Going C in the core and then to AARCH64. Not sure what to call this OS, as it is not the same API not possible. Though I support it as well, I will not use it, though I support it.
  • Potentially running RISC OS directly on the Linux Kernel.

Additionally one area that could be of good application for RISC OS (or at least in part) is that of hosting emulation while better ARM hosted emulation evolves rapidly. This is that the 680×0 series of CPUs can be emulated on ARM now at speeds that are near half the native ARM speed, this is thanks to the details of the ISA’s as well as the support for running an ARM in Big Endian modes. I think it likely that the same level of performance could be achieved for emulating PowerPC systems. So a low level ROM build could be made that loads to a singletasking emulator, giving the illisuion of the emulated OS being native. The operating systems that could be well supported in this way include:

  • Classic Mac OS (PowerPC raange)
  • Classic Mac Os (680×0 range).
  • Atari TOS.
  • Atari MiNT.
  • Amiga OS (680×0).
  • Amiga WarpUp.
  • Amiga OS 4 (PowerPC).
  • Sinclair QL QDOS, SMS/QE, or compatible.
  • IBM Workplace OS (and OS/2 PowerPC).
  • BeOS (PowerPC).
  • X68000 (I understand there are people in western world that use).

Should note that the use of Macintosh System Software / Mac OS Classic, it should be possible to provide almost full support only emulating the CPU, so long as you patch the ROM Disk and QuickDraw routines to not use the native HW.

Further, it could be worth someone creating a Amiga, Atari, Classic Mac, RISC OS Operating System combination, then add in the 68k CPU emulation layer. Though that would be potentially too much fun, and its users would not be able to complain about missing anything usefull, as they would already have it from at least one of the four system sources.

Other systems could be configured in a similar manner, while may not achieve the extreme level of speed in emulation still should be very usable:

  • Apple IIgs.
  • MSX.
  • Tandy 1000 series.
  • etc.

As it is used as a weapon to attempt to make my words apear different from what is said, the status of RISC OS projects at this time:

  • C Compiler, actually making a little usable progress on this.
  • The BASIC compiler of old. Moving forward, though maybe not a direction others will like, also quite slow progress.
  • CPU Design. Sorry I am not designing one this time around.
  • CPU Design References, I am getting them typed in, and am very hopeful to have them online with in the next 6 months, and some of the more important ones online before new-year hopefully.
  • Atari Software Support (TOS API Integration), I have most of the ‘Wind’ AES Library implemented, as well as some support functions. Still need at least soem event support before anything more than a test application can be run.
  • Games, very slow unfortunately. Seeing the anti-32bit talk saddens me and makes hard foccus on fun.

Please do remember that I do not make a living at all anymore. I am living in a medical care facility. So all my coding is hobby, when it apears it appears, no timelines no deadlines.


And in brief that is my point of view on the issue. Please read in full if you wish to respond to, I am tired of people reading parts and having to repeat myself because they did not read. Sorry this argument of the obvious is getting a bit tiring.

I am tired enough of this repeat self, see new argument that twists words, so change wording and repeat self, repeat pattern that I am making this my standard reply to these questions. I may add a paragraph IF a valid reason of question shows an omision in the above, though otherwise will just repeat this post.


You accuse those of us who think an AArch64 version as a goo

While your statement makes little sense. I say that AARCH64 is oone good way forward, if it is for you go for it. it is not for me. And not going to allow you to keep twisting to create an eternal argument over the color of the air or the weight of a rainbow unicorn.

Wow – in terms of visual appearance, it looks even more dated than RISC OS! I don’t know what to say, so I’ll just stop here and go cook some farfalle…

Differing views. For me when MS went back flat with XP and later, they went super retro in apearence, leaving us looking much more up to date.

And the particular combination of AES and Desktop is only one choice, not one I personally would use, not so much a good appearence to me. Though Yes that is one Atari AES with theme and Desktop.

 
Dec 22, 2020 7:08pm
Avatar DavidS (1854) 1863 posts

You say things like that and then wonder why people get upset with you.

As you change the meaning yet again. In context that is only a statement about the view of there only being one way forward, there are many. Good example of what I mean by you love changing the meanings of what I say in this topic anyway.

 
Dec 22, 2020 7:11pm
Avatar Stuart Swales (1481) 301 posts

Perhaps we need a new forum category for ‘Beyond Aldershot’. Alton.

 
Dec 22, 2020 7:29pm
Avatar DavidS (1854) 1863 posts

Perhaps we need a new forum category for ‘Beyond Aldershot’. Alton.

Hence why I am not even attempting to respond to those that change the meaning of words to sound negitive anymore.

 
Dec 22, 2020 7:56pm
Avatar Rick Murray (539) 10289 posts

As you change the meaning yet again.

Oh, FFS. Your interpretation of English must be remarkably different to mine if you don’t think statements like this are simply rude:

in case RISC OS does attempt to jump ISAs, then the one that every one trashes, as a waste of time by everyone that has coded for it in the last 20 years, will still have a use to someone

But since you seem to prefer to dismiss most of what I say with something about twisted meanings and then follow on with reposting the same thing I was responding to for a third time……welcome to my killfile.

PS:

Hence why I am not even attempting to respond to those that change the meaning of words to sound negitive anymore.

Except you did, for several screenfuls.

 
Dec 22, 2020 8:21pm
Avatar Steve Pampling (1551) 6322 posts

Perhaps we need a new forum category for ‘Beyond Aldershot’. Alton

Bognor1 has a royal precedent for dismissal.

1 Technically Aldwick.

 
Dec 22, 2020 8:40pm
Avatar John WILLIAMS (8368) 270 posts

May I suggest to all the use of Chris Gransden’s latest improved version for RISC OS of James Bursa’s “Sargasso”, an RSS feed with programmable exclusions!

 
Dec 22, 2020 9:31pm
Avatar DavidS (1854) 1863 posts

Except you did, for several screenfuls.

Nope just repeated myself word for word.

Though I did respond to the Atari statement. Yes what you show is one of many possible visual configurations for an Atari desktop today. It is not the one I would go with, though it is one for sure.

 
Dec 22, 2020 9:40pm
Avatar DavidS (1854) 1863 posts

Oh, FFS. Your interpretation of English must be remarkably different to mine if you don’t think statements like this are simply rude:

Two parts there, yes part of that was a bit bad wording on my part, my appologies on that.

The other is that that was an outlet of many days of having a good number of people say to me the meaning of “THERE IS ONLY ONE POSSIBLE WAY FORWARD, AND WE WILL NEVER BELIEVE THERE IS MORE THAN ONE WAY FORWARD”.
So I admit I allowed the frustration of the repeated rude anti anything attacks against the concept of more than one possibility.

Above I did not realise exactly where you quoted from, was not as clear. I do appologise as I had thought it was part of a different quote.

And yes I appologise for allowing myself to show my frustration in that poor choise of wording.


I do ask how it is that it is considered polite to repeatedly tell a person that you will never consider any option outside the only one you look at, though yet you will yell at the same person for even saying there may be another option. This is what finally got under my skin, and caused my poor choice of responce. After it being repeated multiple times per day against me it got a bit frustrating.

I do appologise.

 
Dec 22, 2020 10:13pm
Avatar DavidS (1854) 1863 posts

I removed the frustration feuled statement. Sorry about changing the text at those locations, though do to the negitive nature of the comment I felt it best to make the significant removal from the two posts where it showed up.

 
Dec 22, 2020 10:21pm
Avatar DavidS (1854) 1863 posts

But since you seem to prefer to dismiss most of what I say with something about twisted meanings and then follow on with reposting the same thing I was responding to for a third time……welcome to my killfile.

Do not know what a killfile is (I know it is not the 1980s definition in computing). I value what you say, hence why I take the time to read it, even when you seem to be beating me with the verbal “THERE ARE NO OTHER OPTIONS THAN ONE” that has frustrated me.

You may note that even if I do not like what is said by you i always take time to read it. The fact that it can frustrate me should tell you that it matters to me, as I respect you as a person and programmer.

Sometimes it may take a bit to reply to some statements as I usually try not to allow emotion to make a post negitive more than needed.

I did the repost out of a bit of frustration, for which I have and continue to appologised multiple times now. And I felt it better to repost than allow for an angered responce (I did not realise the super negitive was in that post, so sorry about that part).

I even removed completely the super negitive comment. That I had not realised I had actually posted. I had typed it in personal frustration, and then thought I had removed it before it was posted to the forum.

 
Dec 22, 2020 11:35pm
Avatar DavidS (1854) 1863 posts

Appologies, it seems I allowed myself to run to long in this thread, to keep replying to the anti-option posters. Should have backed out hwen those that will only see the solution of AARCH64 and not consider others began making that view known. So I messed up for staying in the thread, consider me backing out the door of where I am unwelcome.

 
Jan 12, 2021 8:31pm
Avatar Rick Murray (539) 10289 posts

Just want to dig up this topic to make an observation…

I have just received my new freebie Android tablet (take a year’s subscription at less than the cover price, and they’ll send you a free tablet… I fail to see how this is actually profitable for them).

Anyway, it’s one of these no name Chinese thingies with an RK3326 processor. That’s a quad core (up to 1512MHz) Cortex-A35 device with a Mali-G31 GPU. Not a bad screen on it, but sadly WiFi performance is lamentable and the “speaker” is comically poor. At least it has a headphone jack.

Of more importance, it’s an ARMv8 device. 64 bit capable, bit it is running Android 9 Go in 32 bit mode.

So if tablets that are given away are moving to 64 bit hardware, I think we really have to understand that 32 bit has had its day.

…

BTW, WTF has Mozilla done to Firefox? Just installed the latest version. It’s… awful. And looking at the available add-ons, there is a choice of eleven things. ELEVEN. That’s beyond mediocre.
This new Firefox? Best damn thing I can do is take it out back, stick a bullet in its head, and copy across the 60.0.2 apk file from my phone. Because this 84.1.4 build is just not exciting. It’s nice that I can add UBlock origin… But cookie autodelete? Tracking cookie obfuscator? RSS previewer? Smart referrer? Google search link unmunger? These are all essentials.
Did I mention the list of available add-ons lists eleven things? I think people are voting with their keyboards over messing with the extension system. I think I shall to, by downgrading to a version that does what I want it to do.

 
Jan 12, 2021 10:20pm
Avatar Steve Pampling (1551) 6322 posts

Ah, v60 to v84 culture shock. Scrapped the old NAPI

Open a PDF in the browser – no add on or 3rd party external required
Google search link fix is what I think you should look for
Various cookie managers as add ons, but “Delete cookies and site data when Firefox is closed” in the options sounds like what you’re asking for.
Tracking cookies – have a look in the Security options

And back to add ons / extensions, query in the search box – after you’ve checked what they’ve now built in.

 
Jan 13, 2021 11:01pm
Avatar Rick Murray (539) 10289 posts

v60 to v84 culture shock

Indeed it is. “One that works” → “WTF is this?”.
They scrapped more than the NAPI, if the official add-ons page is to be believed.

Open a PDF in the browser

Would rather download the file so I can read it in whatever.

but “Delete cookies and site data when Firefox is closed” in the options sounds like what you’re asking for.

No, it really isn’t. I don’t close Firefox on Android. It sort of gets pushed as a background app when I’m doing something else, and may or may not get unloaded by the OS (my S9 is quite aggressive here, my tablet less so).
It’s worse on the PC. I use Hibernate, so I don’t think I’ve closed Firefox in weeks.

No, what I’m looking for is something that will destroy cookies when a tab is unloaded, and otherwise every 120 seconds unless the given site is whitelisted. In other words, cookies are only active for as long as they need to be.

Plus something to fix Google’s search links to be non-tracking ones, and discard Referer text from Google (massive privacy leak, they send the entire search request). One I recall from a short while ago was somebody in Wales (going by IP) was sent to my ancient screenshots of a certain Buffyverse witch with the search phrase “Willow’s gorgeous titties”. The first word is correct, the rest, not so much. :-)
Plus something to detect RSS and display it in a nicely formatted style rather than raw xml (like Firefox used to do).

This evening, I downgraded to a working version of Firefox, installed all of my preferred add-ons (using Google because the Firefox site tried its best to be obstructive), now it’s all working nicely. ;-)

The processor is only clocking around 300MHz more, but this tablet is much more responsive than the older one. Nicer display too, you don’t have to look at it at exactly the right angle.

Anyway, I “fixed” Firefox, the sledgehammer method. :-)

 
Jan 14, 2021 1:25am
Avatar Lothar (3292) 118 posts

> So if tablets that are given away are moving to 64 bit hardware
> I think we really have to understand that 32 bit has had its day

The 64-bit A35 is mass-produced, and therefore much cheaper than the 32-bit A32, which is only used for embedded applications.

So we will soon end up with only high-priced 32-bit remaining, and most of these will have no GPU, or just RGB interface and no HDMI

Pages: 1 ... 11 12 13 14 15 16 17 18 19 20 21

Reply

To post replies, please first log in.

Forums → General →

Search forums

Social

Follow us on and

ROOL Store

Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.

Donate! Why?

Help ROOL make things happen – please consider donating!

RISC OS IPR

RISC OS is an Open Source operating system owned by RISC OS Developments Ltd and licensed primarily under the Apache 2.0 license.

Description

General discussions.

Voices

  • Terje Slettebø (285)
  • Charlotte Benton (8631)
  • DavidS (1854)
  • Rick Murray (539)
  • Stuart Swales (1481)
  • Steve Pampling (1551)
  • John WILLIAMS (8368)
  • Lothar (3292)

Options

  • Forums
  • Login
Site design © RISC OS Open Limited 2018 except where indicated
The RISC OS Open Beast theme is based on Beast's default layout

Valid XHTML 1.0  |  Valid CSS

Powered by Beast © 2006 Josh Goebel and Rick Olson
This site runs on Rails

Hosted by Arachsys