No more big 32-bit cores for RISC OS from 2022
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 ... 19
Andy S (2979) 504 posts |
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. This is why my naive idea is that you could automatically translate the assembler into C and then recompile it with optimisations for 64 bit ARM. Arithmetic operations, SWIs and function calls should all translate easily to C but I suppose it’s hard to know what to do with memory addresses, to know whether they’re just jumps within the code or to external code, accessing storage that could safely be turned into an array, or actually addresses of hardware devices or a particular region of the OS’s memory. Is this idea unrealistic? |
Dave Higton (1515) 3494 posts |
I’ve had a little experience in automatic translation (though not enough to make me an expert by any means). Visual Basic to VB .Net, and (a somewhat different thing) VHDL generated by a visual state machine design application. One problem is that the resulting generated code can be difficult to maintain. It isn’t like code that human beings would write. So you may well find that it’s useful once, but considerably less useful in the long term. |
Paolo Fabio Zaino (28) 1821 posts |
Similar experience for me, in the past with ARM ASM to x86 ASM automatic translation. So, one possible way is Binary Translation (at installation OR runtime and just for runtime). This would mean translating AArch32 binaries into AArch64 as well as emulating the 32bit API (somehow and not in 32bit mode, in this case emulating means “preserve the form”). This is what is being done already for AArch32 to AArch64, so it’s proven to be working. (Of course on RISC OS it may be different, but as a principle it works). |
Steve Pampling (1551) 8145 posts |
Erm, that should actually be option 2:
Unless you want to pay Aaron to rewrite VRPC as an ARM64 ↔ ARM32 build.1 Do bear in mind that VRPC is just emulating a 25+ year old unit with what even niche fans2 regard as historical niche status. 1 The logical, future proof (to an extent) emulation of an RPC is actually RPCEmu – the source is freely available, unlike VRPC, so other emulations are possible if someone has time and talent. 2 Be honest, we’re niche computer fans. |
Steve Fryatt (216) 2101 posts |
BASIC being easily portable to 64bit, of course, seeing as how it’s written in a nice, easy to maintain… oh. |
Chris Hall (132) 3552 posts |
BASIC being easily portable to 64bit, I was not thinking it would be easy, just one of the essential steps if RISC OS was ported to 64 bit. |
Clive Semmens (2335) 3276 posts |
While I understand and appreciate much of what is being written here, and have a great deal of nostalgia for ARM and RISCOS – RISCOS without BBC BASIC, !Draw, and ideally !Zap, is completely pointless for me. Everything else I want to do I can do at least as well on another platform, and remain compatible with the rest of the world. I’ve already lost the International Keyboard Handler Generator (IKHG) which was one of RISCOS’s great assets from my POV; and I no longer feel any need to write in assembler, because BASIC programs run so much faster than they used to. I suspect a Pi4 (which I don’t even have yet) may be my last RISCOS machine; whether any future machine will be ARM based or not makes little difference to me, absent RISCOS. BBC BASIC on another architecture? It’d be great for me, but for how many others? And obviously not a “porting” job; it’d need rewriting from a spec – really a reverse engineering job. That applies as much to 64-bit ARM as any other architecture. And then there’s all the WIMP stuff in any app written in BBC BASIC – that’s not going to work on anything but RISCOS. |
Chris Hall (132) 3552 posts |
RISCOS without BBC BASIC, !Draw, and ideally !Zap, is completely pointless for me I agree completely, and would add Impression to the list. And then there’s all the WIMP stuff in any app written in BBC BASIC – that’s not going to work on anything but RISCOS. Well I did manage to convert my signalbox multi tasking application to work under BBC BASIC for Windows as a multi tasking app under Windows, see here. I had to convert each of the multi tasking routines to the equivalent Windows API in BB4W. |
Clive Semmens (2335) 3276 posts |
That’s the crunch. You can’t simply run the app without rewriting large chunks of it. You want the RISCOS WIMP… |
Steve Fryatt (216) 2101 posts |
I’m unclear why 64-bit means “no WIMP”, though? If you’re going to the trouble of porting the OS, you wouldn’t leave bits behind. |
Clive Semmens (2335) 3276 posts |
Sorry, perhaps I was a bit unclear what I was discussing: I was thinking about having BBC BASIC (and !Draw) but not the whole OS. The thing being that I can just about get my head around how BBC BASIC and !Draw could be reverse engineered*, but the whole OS is way beyond my imagination. Of course I’d love to have BBC BASIC, !Draw, !Zap and the whole OS! * Not, I hasten to add, that I could do it myself, since the only languages I’m really competent in are BBC BASIC and ARM Assembler – and a few ancient ones, now very rusty, like PDP8 assembler, 3790 assembler, COBOL & Fortran IV. |
Steve Pampling (1551) 8145 posts |
I suppose I really should have added “with a 26-bit add-on at the side” so that all the (current) legacy applications work for another 20 years or so. |
Rick Murray (539) 13790 posts |
I’ll believe it when I see it. Certainly, no such automatic translation is helping with Impression. It’s taking long time because it’s being done by hand.
Which is why it’s most likely that our future reality is likely to be a 32 bit emulation. Especially if the emulator stops trying to be something (like an A310 or a RiscPC) and concentrates on being a 32 bit world emulation and passing a lot of the other stuff up to the host (video, for example, can be “what the host has” rather than “a VIDC2”).
Everything. No, seriously. Registers aren’t Rx, there’s more of them (though we could ignore those in the beginning) and they’re 64 bit (obviously!), there’s no conditional execution as we’re used to it, and I think there is a lot less “stuff that sets processor flags” because of this. No STM/LDM, you can only load/store pairs of registers at most. PC is not directly accessible like it is in ARM32 – so your I saw it written somewhere: ARM64 is much more similar to ARM 32-bit than it is to x86. The ARM64 whitepaper gives this as an example: if (x == 0) y = y + 1; else y = y - 1; Which in the ARM we all know, is easily: CMP R0, #0 ADDEQ R1, R1, #1 SUBNE R1, R1, #1 In ARM64, it would be: CMP W0, #0 SUB W2, W1, #1 CSINC W1, W2, W1, NE On the topic of automatic conversion, note that such a simple thing now uses an additional register. AAPCS defines X0-X7 as parameters to functions, and X9-X15 being the corruptible ones. LR is X30. It’s not directly compatible with the ARM32 APCS. I’ve already mentioned PC isn’t directly accessible. Neither is SP. Luckily there’s a platform specific register (PR or X18) which could be used as an environment pointer for C (because, let’s face it, it’s likely that a rewrite to C is more viable than trying to convert assembly to assembly). I’ll leave somebody like Jeffrey (who knows what he’s talking about) to fill in blanks if he feels like it. I’m just reading forum posts and various ARM PDFs and thinking that converting an operating system isn’t going to be a case of search-and-replace register names, it’s going to be a ground-up rewrite.
An emulation of a quarter century old machine…?
Sort of like what CFront does to C++ in order that the compiler can build it? ;-)
English is amusing. There are several ways to interpret “niche computer fans”.
This. Losing what makes RISC OS special is losing RISC OS.
Is this because it’s 26 bit, or because the underlying system has changed?
This too. As the guy who wrote assembler tutorials, I’d advise NOT using assembler. Of course, in hindsight, one can also point out that a higher level language can be recompiled, while assembler is extremely sensitive to changes in ARM behaviour.
It’s not just BASIC (if I really wanted something that could run BASIC, there’s Brandy). It’s the behaviour as a whole. The way the filer works (I hate how Windows/Linux does it). The ease of draggy-droppy directly between apps. Pop-up menus rather than stupid menu bars. Consistent copy-or-move behaviour. A filing system that isn’t so ass-backwards that MyDoc.txt and mydoc.txt are two different files. And, to be honest, as much as it’s a pain in the ass dealing with RISC OS filetype metadata on other platforms, I view this as a limitation of the other platforms that are only capable of giving files “types” by suffixing stuff to the filename.
Let me ask you a zen question: does RISC OS have to be RISC OS if it behaves like RISC OS? If it starts up, enters a desktop that looks like the desktop, and has a friendly little command line when you press F12 (or ^F12 for a multitasking one), it could be written in Lua…. as long as it behaves the same way.
You speak COBOL and Fortran IV? Why aren’t you making megabucks keeping those ancient banking systems limping along on their crutches?
Honestly, for me it’s more a curiosity than something I depend upon. Adrian kindly made Aemulor available recently. I made the transition to the 32 bit world many years before that, so I just got used to having left some of the old things behind. I have an old ArtWorks that runs, and I’d like to have 1stWord+ but tha crashes Aemulor. That said, my version has been messed with a lot back in time (I don’t remember doing any of that) so I don’t know if that could be a factor. My important ones (OvationPro, Zap, and the crap I write) run natively. |
Steffen Huber (91) 1945 posts |
Yes, related to the basics of the ASM code, that’s clear. It operates completely different, philosophically and physically. What I was referring to is more the “basics” of a 64bit RISC OS. How does a typical memory map of a 64bit OS look like? How big would an application memory slot look like? Do we want to have something similar to an RMA? And modules? Will we still have something like SWIs? I read that Linux uses SWIs in a completely different way than RISC OS on AArch32. What does Linux use on AArch64? You see, I am completely clueless. As a Java person, I leave all such details to the JVM :-) |
Steffen Huber (91) 1945 posts |
Many users have their few indispensible apps that they need Aemulor for, but I guess in the grand scheme of things, it’s only Impression and Eureka. |
Paolo Fabio Zaino (28) 1821 posts |
@Rick
if (x == 0) y = y + 1; else y = y - 1; Sorry Rick… just my 0.5c, but my approach to that example in ARM64 would be: ldr w0, <source>; in case your Y was defined in C and as an int then replace <source> with something like [sp, 12] for example cmp w0, #0 bne .YCASE2 ; jump to YCASE2 if y != 0 add w0, w0, #1 ; y= y + 1 (or in C y++) str w0, <source>; <source> as defined at the top b .DONE .YCASE2 sub w0, w0, #1 ; Now this is the y-- and just because it would be executed if y != 0 (aka no jump) str w0, <source>; just store it back in whatever is your <source> .DONE ; whatever here... Anyway not wanting to start an ASM war, as you pointed out very well, we should stop using ASM on RISC OS, full stop. |
Clive Semmens (2335) 3276 posts |
This, doubled and redoubled in No Trumps. Mac is tolerable – just about. That other alleged system…the less said the better. Linux et al are too much trouble for my way of thought.
Because mental health matters more to me than mere megabucks. “Now very rusty” may also be relevant. I used to speak COBOL and Fortran IV, forty-odd years ago… |
Clive Semmens (2335) 3276 posts |
Dunno. Probably the former, but could be something to do with the move to USB keyboard. Worked on RiscPC, doesn’t work on Pi. I’ve never used Aemulor, dunno whether it works there. |
Jon Abbott (1421) 2641 posts |
You could actually consider this good news as it means we have a known base of CPU to support. One of ARM’s biggest flaws is the constantly moving instruction set and “implementation defined” instructions. Just look at all the modifications we’ve had to make across the Pi range due to the changing instruction set. Of course this does not mean 32bit is going to be unavailable, just that ARM themselves are deprecating the instruction set; in the same way you can still get 8bit CPU’s, 32bit CPU’s will still be around for many, many years to come. Although the ARM instruction started essentially as something targeted at programmers, the IT industry moved to high level languages long ago and ARM64 is targeted exclusively at compilers and the direction ARM need to focus on, so a sensible move. The downside obviously is where Pi foundation moves; if they move to a 64bit only CPU and drop all 32bit models, we no longer have cheap readily available SoC to run RISCOS on that can be purchased new. That said, there are millions of Pi’s out there, so I don’t think the eBay supply will run out within my lifetime. |
Clive Semmens (2335) 3276 posts |
But it’s so different from earlier ARMs that RISCOS would need to be completely rewritten for it; while you’re doing that why not rewrite it in C and compile it – then it doesn’t matter a hoot what CPU it runs on. If the Pi foundation gives us a cheap ARM, fine, but whatever we can get would be equally fine. I don’t underestimate the task of rewriting RISCOS in C – but I doubt it’s any worse than trying to rewrite it in 64-bit ARM assembler. |
Steve Pampling (1551) 8145 posts |
I seem to recall looking at IKHG just to see what it did (never having looked any time in previous years/decades) Hey Rick, I know you love the keyboard handling stuff. I wonder if a modernised re-write could be done. :) |
Steve Pampling (1551) 8145 posts |
As I said “generic 32 bit”
Oh, definitely. That’s why I like it. It also happens to be my native (and almost only) language.
I know, and I meant both the obvious fans of niche computers and especially the niche fans of computers or in this case niche fans of niche computers :) |
Theo Markettos (89) 919 posts |
Here’s a question… I wonder how many RISC OS folks care about it running bare-metal? Doing so brings a lot of driver and porting hassles, and I don’t see an enormous gain from it. It benefits from a certain amount of simplicity (RISC OS Pico), but not that simple because you still need to drag in big driver stacks for things like USB. So I might suggest slipping a lightweight virtualisation layer underneath. That would preserve most of the user-facing things people like about RISC OS, and most of the system-level things too. My roadmap for doing so would be to use QEMU/KVM, because it has quite good cross-architecture support. So it would need a port to a generic platform supported by QEMU – plenty to choose from so pick whatever’s simple, best-supported and with decent performance (eg VirtIO hardware rather than complicated emulated devices). That’s of a similar amount of work as the other ports (ie not insignificant, but not to the scale of rewriting everything in C). On aarch32 hardware you can run this on top of KVM so you get near-native performance. On aarch64 you have to use QEMU’s instruction set recompiling, which has an overhead but at least you can still run things. The advantage is you can then run RISC OS on any board that has a Linux kernel, so you don’t need to worry about porting details (documentation, etc). While you have a Linux kernel on the metal, you don’t necessarily need a userland Linux distro – it can be as slimmed down as you like. You can also run on x86 as well, of course. The difference compared with VRPC and RPCEmu is that you’re running a model of a modern machine, not one constrained by 1990s limits (256MiB RAM, etc), and one which somebody else maintains. So all the stuff like networking, storage, I/O, management GUIs, etc already works. Since the QEMU backend would be just another RISC OS port, other ports are free to run on suitable aarch32 metal as long as that exists. QEMU/KVM won’t keep us bare-metal hackers happy, but I suspect we’re in the minority… |
Michael Gerbracht (180) 104 posts |
Could FPGAs help us? Something like: https://hackaday.com/2018/10/02/free-arm-cores-for-xilinx-fpgas/ ? Or is the performance drop to large even if you are using a high end FPGA? |
Clive Semmens (2335) 3276 posts |
I seem to remember talk of FPGAs with early ARM cores on them…I wonder if anyone’s still doing them? I don’t think later ARM cores lend themselves to this application so well, perhaps there are even still 26-bit cores on production FPGAs? No, probably not 8~( |
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 ... 19