No more big 32-bit cores for RISC OS from 2022
Pages: 1 2 3 4 5 6 7 8 9 10 11 ... 19
Alan Robertson (52) 420 posts |
The countdown clock for our beloved 32-bit RISC OS has begun. ARM has announced that “Starting with Arm’s 2022 IP, all future Cortex-A “big” cores will only support 64-bit”. i.e no more 32-bit cores for RISC OS to run on. There is no mention of what will happen to the smaller, less powerful class of cores such as the Cortex-A53, so these may still be around for a bit longer. So rough timings might be: We all knew this day would come, but the date is quite close. I realise that RISC OS probably has a few years after the 2022 cut-off before there are no more platforms available to us, but the clock is now ticking. |
Rick Murray (539) 13804 posts |
https://www.theregister.com/2020/10/08/arm_32bit_support/ Rather inevitable really, everything else that is commonly used is compiled, so can be built for 32 or 64 bit as required, and since pretty much everybody has gone to 64 bit, keeping the 32 bit around makes about as much sense these days as keeping 26 bit around did back when Acorn met its demise.
It always has been. The question is, what’s the way forward? |
Kuemmel (439) 384 posts |
…raise a 64-bit bounty & find people who can and want to do the job ;-) |
Steve Pampling (1551) 8154 posts |
There will be more knowledgable heads on this but at a guess the options are:
I did consider adding “give up on the future proofing and hoard some old boards to use, forever” but that doesn’t match the “way forward” element of your question. |
Dave Higton (1515) 3496 posts |
That’s the one that seems logical to me. This is a good moment to thank Julie Stamp for having made a start on the process. Note that the source includes the HAL. I’ve recently spent some time working on a small part of it, and it reminds me how much I wish it had been in C already. |
Steve Pampling (1551) 8154 posts |
Forcing a move to a native 64 bit is “interesting” – when I said
… I could see all the devotees of things like Impression-X having screaming fits.
Indeed. It’s a long task and probably little thanks.
Given its origin (much involvement in the RO-wars) I’m surprised it isn’t totally in C, but it seems C is only 8.5% (Kb of source) what that comes down to in terms of final code will surely differ. |
Rick Murray (539) 13804 posts |
This, I feel, is likely what will happen in reality.
This may or may not be a good thing. For sure – we need to be in something that is not raw assembler for continued viability (like in 2026 when the ARM API changes in some weird way and Linux just shrugs it off as a three-line patch). However, given that apart from BASIC programs, absolutely NOTHING from the past will run on a 64 bit system, perhaps it might be time to look at the behaviour of the OS as a whole, with a view to fixing some of the rubbishy bits once and for all. Concepts such as modules running with the same access level as the kernel should be killed with extreme prejudice. All OS workspace should be completely inaccessible to the user mode apps, and things that need to access kernel level stuff should have an API where the data is copied to a temporary buffer that is user mode readable. No longer pass SWI by embedded number (it may be that ARM64 doesn’t do that anyway – I haven’t looked). Along with this, look at having a mixed co-operative/pre-emptive Wimp. With a kernel that is aware of the fact that different processes exist. So it’ll be “RISC OS like” but in a way a little more 21st century and a little less 1987. O’course, the eternal question – who is going to write such a thing?
This is why I see some sort of emulation being the most likely outcome – because otherwise huge swathes of software would simply vanish. Take a look in !Store and PackMan. That’s your lot, as stuff still available could be updated (depending on how much the API changes and how difficult that makes it). Impression? Artworks? Both assembler, aren’t they? PhotoDesk has a lot of assembler. That’s not to say it’s impossible, just quite unlikely. |
Steve Pampling (1551) 8154 posts |
Keyboard handler and allied items. Wimp Poll, Key_Pressed Highest character code? &1FF
Hence my comment about Impression X. Is that even fully 32bit yet? I don’t mean “mostly but it works with a bit of help from Aemulor”, no, really 32bit. |
Andy S (2979) 504 posts |
Convert every element of the OS source to C and compile for a 64 bit platform Would it be feasible to write a tool to decompile most of the assembler automatically (to C or some other intermediate representation)? Or does one already exist? I guess there’d be a few bits like self-modifying code that would need manual intervention. Create a 64bit emulator for a generic 32 bit platform and run the OS and applications in that emulator. I think the ideal solution would be a sort of combination of the two: converting as much of the OS as possible to run as native 64 bit code but including an emulation layer for any applications (or bits of the OS) that haven’t been ported. I’m not sure if this is more work than option 1 or if it saves time. It could even include 26 bit emulation. I also wonder if Jon Abbott’s JIT compiler would be useful here if it could be persuaded to output 64 bit code. |
Rick Murray (539) 13804 posts |
Argh! I wasn’t going to go near that nest of horrors. |
Clive Semmens (2335) 3276 posts |
I wonder how many other RISC OS users are like me, in not really caring about 99% of the old software? For me, if I could have !Draw, !Zap, BBC BASIC & the WIMP desktop, I wouldn’t miss anything else. Apart from a certain amount of nostalgia, “give up on the future proofing and hoard some old boards to use, forever” may well be the way I’ll go. Sadly. I might – or might not – get myself a Pi4. I wonder how long my Pi3 will last…such things don’t last forever. But then neither will I. Our son, who cut his teeth (metaphorically!) on a Psion 5, moved on years ago. |
Clive Semmens (2335) 3276 posts |
Actually, even the loss of !Zap wouldn’t upset me too much, as long as I still had BBC BASIC and the WIMP desktop: I don’t use much of its (amazing) functionality, and what little I do use of it I could replicate in an app of my own, written in BASIC, fairly easily. |
Steve Pampling (1551) 8154 posts |
Does self-modifying stuff work properly on the modern machines? |
Steve Pampling (1551) 8154 posts |
Of keyboard handler:
:) Worse though, in some respects, is the constant shifting with the regard to use of particular registers for a particular purpose. Different developers for different modules clearly choosing register numbers by throwing darts at a set of playing cards blindfold or something. |
Rick Murray (539) 13804 posts |
That would be cataclysmic. If I had a clue about how text editors worked, I’d think of writing something that “behaves like a simple Zap” in C. 1 With the exception of StrongEd, that can do most (if not all) of what Zap does, only differently. I’m not taken with its visual appearance though… |
Rick Murray (539) 13804 posts |
I wonder how much of that is due to botching the keyboard interface into a BBC-like OSBYTE clone, and then bolting on stuff without addressing the fundamental issues with the keyboard subsystem?
He who is in possession of the pink dinosaur gets to pick the registers, and everybody else can STFU until it’s their turn. ;-) |
Andy S (2979) 504 posts |
I guess there’d be a few bits like self-modifying code No idea but I know SpriteExtend generates ARM code dynamically for some rendering operations and in Paint the code for my ColourTrans transfer function is defined using an array of hex values. OK, both those are from C but it shows RISC OS does run 32-bit ARM code that is generated or loaded at runtime. |
Bryan (8467) 468 posts |
I have a cupboard full of old boards. Pi 1, 2, 3, 4? |
Clive Semmens (2335) 3276 posts |
I had a cupboard full, not including a 4, until we moved. Now I only have one 3B, our son has the rest and may be playing with them, he said he might. He’ll do things with them I wouldn’t have; he’s not a RISC OS man, and is also more inclined than I am to bother with the GPIO side of things.
Totally agree. Atom is what I use on the Mac, but Zap is one of the reasons I flip over to the Pi fairly often. I’d certainly miss it, but the features of it that I use – like you, switching to hex words or bytes, and code colourization* – are all things I wouldn’t find too difficult to replicate in a BASIC app. (In C? Impossible…for me at any rate.) In an earlier version of Zap that I used to run on A5000s and RiscPCs but which no longer works on the Pi, I had managed to make my own variation that displayed all the normally non-printing bytes as single characters, colour coded, which gives you the same information as the byte display, but a little easier to read and a lot denser on screen. I’ve not (yet) bothered to replicate that in BASIC…harder would be the equally handy keyboard driver that enabled me to touch type any of the 256 bytes using one character key possibly combined with one or more modifier keys… * Although I’d only bother with HTML & BASIC colourization, and I’ve already got the HTML colourization in Atom… |
Chris Hall (132) 3554 posts |
Presumably applications written in BASIC would just work on the 64bit OS (once RISC OS works on a 64bit processor). Perhaps it would be better to rewite the simpler apps in BASIC rather than c to future proof them. Aemulor will need to exist for some time for Impression so will have to cope with 64 bit – we should have a bounty for updating Aemulor to run in 64 bit. |
Steve Pampling (1551) 8154 posts |
Isn’t that increasing the workload? There’s probably already a cross-platform compiler that can do the C recompile today1. There is no trace of a RISC OS BBC BASIC interpreter for 64 bit hardware – for obvious reasons. I think the change will probably be option 1 and 2 in bits. As for Aemulor, it’s a stop-gap. A crutch for 26bit reliant items that’s extended the usable life of some things for nearly 20 years. Time to move on or emulate a 26 bit environment in something like RPCEmu for items of historical curiosity. 1 Guessing, but quite likely. 2 No doubt if he did then Fred would find himself with a partner in the StrongED modifications |
Rick Murray (539) 13804 posts |
Which part of “That would be cataclysmic” implies abandonment? The hard cold harsh reality is that stuff written in assembler for a 26/32 bit OS will not work in a 64 bit world. So, as much as I like Zap and as much as I want to keep on using it, if RISC OS makes a transition to 64 bit, Zap will be a casualty. Another one lost to the changes of the ARM. So it’s worth thinking ahead to potential alternatives. To ask “what is it that makes Zap…Zap?”.
Unlikely – isn’t StrongEd also written in assembler?
Simple indeed. Things that don’t need speed (won’t be crunching numbers), don’t need anything resembling semi intelligent memory handling (unless you’re happy to manage it all yourself), and don’t need to mess too much with data structures (because native BASIC is a bit icky there).
Easy way to obliterate that argument is to point you at any Linux kernel. As long as a compiler exists, stuff written in C can be compiled. Some careful coding and not making dumb assumptions (like the size of int or structure packing) and you ought to have something that will happily build for whatever architecture is under discussion as soon as there’s a compiler for it. Consider also OvationPro. Not only 32 bit native, there’s also an x86 version. ;-) |
Steffen Huber (91) 1948 posts |
Maybe, if the source is available, a machine translation could do 99% of the work. After all, the 64bit ARM should be a lot faster, so for legacy software you don’t have to worry too much if you lose some performance on the way, so you can do the translation very “conservative”. In “binary only world”, it is a lot more difficult. Besides full emulation – no idea. Anyway, with the current state of RISC OS, you’d first need to get an idea what will have to change to make RISC OS happy on 64bit ARM. Then, you’d need an automatic translation approach for the ASM stuff – rewriting everything in C is a nice idea, but I fear the lack of competent developers will make this unlikely to happen. The problem with the “auto translation” approach is that you need experts on both 32bit ARM and 64bit ARM, with a good understanding of RISC OS thrown in. A big task. It looks a bit like the 1998 “end of Phoebe” situation – no HAL, no 32bit-clean OS, so it looked a lot like “it will be Emulation from now on”. |
GavinWraith (26) 1563 posts |
One of the reasons I keep pushing Lua is that is available on any platform with an ANSI C compiler. My experience with Linux is rudimentary, but I would be surprised if there were any Linux distributions that did not already incorporate at least one version of Lua 5.x (0 < x < 5) as a standard component. |
Chris Hall (132) 3554 posts |
The third option is to continue using Virtual Risc PC. |
Pages: 1 2 3 4 5 6 7 8 9 10 11 ... 19