RISC OS Porting to the new ARM based Apple MacMini

Hmm, do we have practical examples of emulating a 32 bit environment on a 64 bit core? Something that’s a little better than Tango’s 15%? That actually seems kind of slow… just sayin’.

I already answered this. Tango poor performances are due to JIT BT (Just In Time Binary Translation, in other words it analyse a block of AArch32 code live during runtime and translate it into an AArch64 form paying attention to leave 32bit calling conventions and remapping memory addresses appropriately), you can improve perfs with BT at Installation time for example, and the proof of this is Apple Rosetta 2. Now if this is clear great otherwise amen :)

My original point was about Virtualization, not running a 64bit CPU in 32bit and use it as a 32bit CPU. For this I believe Jeffrey already made a great statement: if you have a 64bit CPU don’t you want to use it at the best possible with 64bit wide address etc? I mean I am perfectly happy to use RISC OS as an IoT OS, but many people here seems to want DESKTOP stuff which is getting more and more complex and powerful every new gen. So you do your maths.

Also, about running 32bit Apps in “semi-native” way on a 64bit OS: Linux has dropped that, Windows is dropping that… well I guess we want to adopt it when everything else is dropping it, what can I say.

Good luck with that type of approach on ARM or whatever you guys want to achieve.

if you have a 64bit CPU don’t you want to use it at the best possible with 64bit wide address etc?

Not always
1/ see size and speed problems with the new Linux 64bit for Pi
2/ I’m a RISC OS user, so for me it’s no :)

Just in case someone wants to attempt a port, the apple migration tools and developer kit is available. “The DTK, which must be returned to Apple at the end of the program, consists of a Mac mini with Apple’s A12Z Bionic SoC inside and desktop specs, including 16GB of memory, a 512GB SSD, and a variety of Mac I/O ports. Developers can apply to the program at developer.apple.com, and the total cost of the program is £479.”

@ Andrew,
Yes, it is, I made my request immediately after they published the link in the Apple Developers site, however it has to go through an approval process.

They are rightfully trying to avoid youtube reviewers and blog reviewers probably and/or other people just interested in studying their tech because ARM is actually coming back to the “desktop” market.

So the DTK offer is only for developers who actually really need to move their apps from Intel to Apple Silicon (aka Apple custom ARM).

Cool. It’s understandable that they are trying to keep a lid on things, although my news feed tells me that they’ve already lost that one.

Exciting times, fingers crossed you make it through the application process and get to keep the hardware. ;-)

@ Andrew

Exciting times, fingers crossed you make it through the application process and get to keep the hardware. ;-)

Exiting times indeed! :)

Thanks, we’ll see, I do have a bunch of Apps on macOS that needs porting from x86 to ARM, so I am technically eligible according to their rules. However I also know that the queue is long and also my apps are all network tools not available on the Apple Store (at the moment), so I am defo a secondary choice for them (I have a feeling that they tend to prefer developers who sell or distribute their software via Apple Store, but I could be wrong).

The ARMv8 Architecture Reference Manual states that AArch32 support is optional (section D1.20.2, “Support for Exception levels and Execution states”). ARM have even released CPUs of their own which are AArch64-only (Cortex-A34, Neoverse E1).

I noticed a new ARM Cortex announcement the other day, which prompted me to download ARM’s table of currently licensable Cortex-A’s. Counting up

• There are 5 ARMv7’s (only 2 of which are available to license afresh)
• There are 16 ARMv8’s (only 8 of which have AArch32 above EL0)

…so 47% of cores I could license can run RISC OS.

Probably still a few years left to panic as there’s lag between what’s being licensed today and what you can get as a SoC with useful documentation, but still it’s a sign that there will come a day when the last StrongARM AArch32 comes off the production line.

…so 47% of cores I could license can run RISC OS.

Currently the most capable core (DMIPS/MHz) that has RISC OS on (OK, nearly on) is the A72 in the Pi4. There are 2 more cores after that (A73 and A75) before you lose AArch32 mode.

RISC OS has definitely benefited from ARMs reasonably quick core updates over the last couple of decades in there ‘high end’ models (A8 – BeagleBoard, A9 – PandaBoard/ARMX6/IGEP5, A15 – Titanium, A72 – Pi 4), and there is scope for another couple of machines (A73/A75) before the “AArch64-only” derails the performance train.

But there is now clearly a roadmap to the end of the performance oriented ARM cores capable of running RISC OS. Deciding what, if anything, has to be done about this is left as an exercise for the readerROOL.

I suspect you’ll be able to get a low-end AArch32 core, e.g. an A32, for probably a decade or more, it just wouldn’t offer a performance increase over what you have today.

@ Sprow

but still it’s a sign that there will come a day when the last StrongARM AArch32 comes off the production line.

Yup, and with the speed of improvement of RISC OS that day may be for RISC OS 5.32/34? :D

Jokes apart, I actually got my Apple DTK and started to play with it, the case it’s a regular modern MacMini, however the board clearly remind me of an “RPi” (2 USB 2.0, 2 USB 3.0 type C, 1 NIC 1Gbps port and one HDMI port) kinda device, so nothing fancy there.

The promising thing is RAM 16GB and the NVMe disc (~512GB) and the available cores (8), which (together) in terms of ARM SoC represent a big step forward :D

The feeling using macOS at 1080DP is like using a slightly faster Linux compared to my own “optimised to the last drop” Linux PrometeOS for ARM. This means, to compare macOS with standard distros for ARM, that the feeling of using the system is like a slightly faster PineBook Pro (if I could give it a % of better speed it feels like 20 max 25% better perfs than a pinebook pro with standard majaro).

However, I have to agree with Apple, the real magic is the Binary Translation, guys it works… So I can download x86 apps from the Apple Store and install them as we would on a regular Mac, however the installation is notably wayyyy slower than on an x86, why? because that is when Rosetta 2 gets the x86 binary and converts it into ARM code.

Apart from that, when I run the apps they run well. Don’t get me wrong, is NOT the same effect most of us experienced back in the day when purchased the first Archimedes and BBC BASIC was running faster than executable code on an 8086/80286 lool, but I can clearly see that binary translation is the future and will ensure Apple to have freedom to move to ARM and, if NVidia mess things up, they can chose something else. It works guys.

And with the Universal Binaries (another way to call .NET type thingy??? lol) the installation process gets faster, so probably the future is compiling in UB and then on the specific mac (either x86 or ARM) get the final executable binaries built and ready to run.

@ Peter Howinks

I suspect you’ll be able to get a low-end AArch32 core, e.g. an A32, for probably a decade or more, it just wouldn’t offer a performance increase over what you have today.

AFAIK, sure there is going to be A32 for the M and R series still for a long time. But on the new X and the A series not so sure, also the problem is not that ARM is not keeping A32, the problem is that by being optional most CPU manufacturers and licensees may opt out from A32/T32 to keep costs down, so (and with this I do not want to sound just negative), but I don’t see such a long future for A32 on Application class ARM CPU available on the market.

And final note, all we know/seen on ARM evolution in the past 20 years may also get a big change of direction now with the new ownership, which is another variable to consider.

NVidia wants to expand on AI, automotive and cloud markets, we all know this (they also announced today a partnership with VMware for the cloud), while we do not know what are their plans for SoC systems and dev boards that are not AI oriented and we do not even know their plans on the Server market…

Just my 0.5c

and the available cores (8), which (together) in terms of ARM SoC represent a big step forward :D

Of which 8 cores RISC OS could potentially use 1! What’s the point of speculating whether the OS will run on some whizzy new ARM iteration when we can’t currently make full use of what it will run on?

What’s the point of speculating whether the OS will run on some whizzy new ARM iteration when we can’t currently make full use of what it will run on?

I personally see RISC OS as something to have fun with, not something that has to compete with macOS or Linux etc. because it simply can’t right now and maybe it never will.

But, to answer your question, there are different aspects than needs some consideration here:

1) Is not just the number of cores, but also the performance per core and performance per watt. RISC OS does indeed runs faster on newer ARM chips because they indeed have higher performance per single core too.

2) Cache and memory bandwidth, newer chips have bigger cache and higher memory bandwidth that again benefits RISC OS and the applications we can write on it. Higher performance means we can layer up more code which means we can build more libraries to be reused and stacked up to build applications which then means easy way to build bigger and more feature rich applications

3) Availability, newer hardware is obviously more available than older

4) Better storage, SSD and NVMe are definitely better storage media than an SD card as well as faster acces and better throughput

5) These are all SoC (Systems on a Chip) which means also GPU and newer chips generally have also faster GPUs and eventually access to HW acceleration which (when possible) means watching movies on RISC OS, playing music in the background when you are using it for whatever you like to use it for, possibility to create 3D Games etc…

6) fun, learn something, grow technically, improve skills, enjoy what we like

All of the above helps to have better MIDI applications that can have more tracks, better games, faster databases, more applications running at the same time (Messanger Pro with AcornSSL, Cube Chat, while compiling some big code!), Ray Pro rendering bigger scene in less time, faster file copying, faster network access, faster internet browsing and more.

So yes it doesn’t use 8 cores and for that matter not even 2, but it still benefits from newer chips and boards, and, to be very precise, it’s not that you cannot use the other cores… just RISC OS doesn’t use them by itself yet, but you can still access them and write code that uses them.

Hope this answers your question.

but it still benefits from newer chips and boards

Indeed, as I have personally experienced in nearly 30 years of daily RO usage(!), and as your comprehensive answer makes clear. But as other posters above have noted, no-one can be sure how much longer AA32 chips will be available, or whether those that are will offer significant improvement over what we have now. In that case there’s a choice between 2 strategies: 1. Find some way (paravirtualisation? RO-on-Linux? Emulation?) of running RO on AA64 hardware; 2. Optimise performance of what the OS currently runs on. It was the latter aspect that I had in mind in referring to multi-core operation. I don’t underestimate the difficulty of both options, and I’m certainly not qualified to judge which is the better. But it looks to me as if, at some point (possibly soon), the choice* will have to be made.

EDIT: *I’m assuming programming resources would not be adequate to pursue both options in parallel.

There is another vaugely plausible and short lived option, for chips which still have AArch32 user mode, but not privilidged modes. Port the core of the OS over to AArch64, and come up with a strategy of running modules in user mode. The vast majority of RISC OS modules which not device drivers, don’t actually need to be in a privilidged mode, so with a bit of Aemulor style magic could still be run natively as AArch32 on such chips.

Would it be possible to make a ARM compiler to take in 32bit code and output 64bit code?

Yes, but that wouldn’t get you a new 64 bit RISC OS, but either a just in time, or an ahead of time emulator for 32 bit RISC OS.

Would it be possible to make a ARM compiler to take in 32bit code and output 64bit code?
Yes, but that wont get you a new 64 bit RISC OS, but either a just in time, or an ahead of time emulator for 32 bit RISC OS.

Why not – it’s what DEC did to port some of VMS from VAX (32-bit) to Alpha (64-bit). A one-off which produces a 64-bit binary, not a JIT compilation.

That’s in essence an ahead of time translator, which then coupled with a 32 bit to 64 bit OS API library allows the old code to run on the 64 bit OS. The question is will that 64 bit OS be a new version of RISC OS, an ARM Linux, or even given this topic; MAC OS on the M1?

From:
https://www.riscosopen.org/forum/forums/12/topics/15842?page=7#posts-128135

A month ago:

Linux ported to Apple Silicon (M1):

Linux on Apple Silicon:
https://asahilinux.org/

https://github.com/AsahiLinux/

08 October 2021, pcgamer.com: Developers finally get Linux running on an Apple M1-powered Mac
backup
Quote: “…
This massive feat was achieved by having a bunch of drivers merged (or in review) for Linux 5.16, which includes drivers for the PCIe, USB-C PD, ASC mailbox, etc. If you’re wondering if any of this is legal, don’t worry. So long as no code is taken from macOS to build Linux support, it’s legal to distribute.
…”

asahilinux.org: Progress Report: September 2021
Quote: “…
However, Apple is unique in putting emphasis in keeping hardware interfaces compatible across SoC generations – the UART hardware in the M1 dates back to the original iPhone! This means we are in a unique position to be able to try writing drivers that will not only work for the M1, but may work –unchanged– on future chips as well. This is a very exciting opportunity in the ARM64 world.
…
With these drivers, M1 Macs are actually usable as desktop Linux machines! While there is no GPU acceleration yet, the M1’s CPUs are so powerful that a software-rendered desktop is actually faster on them than on e.g. Rockchip ARM64 machines with hardware acceleration.
…”

-

Later? support for:

October 18, 2021, anandtech.com: Apple Announces M1 Pro & M1 Max: Giant New Arm SoCs with All-Out

Thanks to Acorn Computers for making ARM architecture and making it possible to innovate ARM architecture further.

-

Another port:

January 2021, corellium.com: How We Ported Linux to the M1
Quote: “…
So when Apple decided to allow installing custom kernels on the Macs with M1 processor, we were very happy to try building another Linux port to further our understanding of the hardware platform. As we were creating a model of the processor for our security research product, we were working on the Linux port in parallel.
…”

https://www.corellium.com/platform
Quote: “…
Corellium’s ARM2ARM feature offers transparent 32-bit translation for Android, so you can run apps with 32-bit libraries on hardware without 32-bit silicon without making any modifications to your code.
…”

The question is will that 64 bit OS be a new version of RISC OS, an ARM Linux, or even given this topic; MAC OS on the M1?

Which begs the question of “What IS RISC OS?”

For me, if it has ALL the RISC OS APIs and the desktop appearance and behaviour it is RISC OS. If that’s done with a layer on top of something else, e.g. Linux, would that be a bad thing? It could be a good route to a multi-processor 64-bit RISC OS.

Which begs the question of “What IS RISC OS?”

Good point.

So, IMHO, RISC OS is a bare-bone³ ARM based Operating System where the concept of modularity has been pushed to the limit¹ and the separation between traditional operating system layers² is extremely thin, if existing at all.

For me, if it has ALL the RISC OS APIs and the desktop appearance and behaviour it is RISC OS. If that’s done with a layer on top of something else, e.g. Linux, would that be a bad thing? It could be a good route to a multi-processor 64-bit RISC OS.

Well, if my “definition” of what is RISC OS is correct (or accepted by the majority of people), then implementing RISC OS on Linux would certainly break that definition, hence it would not be “that” RISC OS.

¹ Where a user can replace a lot of the Operating System itself, without even having privileges to do so. Where if something can not be replaced with a new Module then can be intercepted with OS Vector interception and can be altered or replaced transparently.

² Where a User-Space process is not allowed to access the Kernel-Space in any “unmanaged” way. Where unmanaged means “not under the complete control of the kernel itself”. Traditional Operating Systems present 2 or more layers of separation between what is called user-land and the kernel and information can be exchanged between each layer only in a managed fashion.

³ bare-bone in the case of RISC OS means the minimal possible amount of code to have an operating system capable of running a graphical desktop and a multi-application (note multi-application, not necessarily pure multi-tasking as preemptive or multi-core based) environment. In other words a shrunk down OS to have the minimal support for such an environment and run applications that do not have huge resources demand. Which indeed sounds like the definition of an Embedded OS these days.

It could be a good route to a multi-processor 64-bit RISC OS.

I agree: the key thing IMHO is the perception of the OS by the user. I’m typing this using NetSurf on RPCEmu 0.9.4/5.27 Recompiler¹ on a middling (2.53GHz i3 M380) Win7 laptop, it feels pretty much like a Pi2 running RO natively, and ROmark bears this out. In full screen mode I have no way of telling what the underlying hardware is. My Pi4 runs RISC OS about 3 times as fast, but I don’t doubt RPCEmu could close the gap significantly on a faster, more hi-spec PC, or under Linux on the M1….

¹ Seriously impressed with the latest RPCEmu iteration by the way: the developers seem to have /doubled/ the emulator’s clock speed compared to 0.9.3, at least in Recompiler mode.

Which begs the question of “What IS RISC OS?”

For me, if it has ALL the RISC OS APIs and the desktop appearance and behaviour it is RISC OS. If that’s done with a layer on top of something else, e.g. Linux, would that be a bad thing? It could be a good route to a multi-processor 64-bit RISC OS.

You could do that, provide all the APIs and the desktop appearance and behaviour, but running on ARMv8 so zero binary compatibility – is that still RISC OS?

It’s enviable we will have to retain 32 bit binary compatibility via emulation for existing applications. Then choices you have are:-

1. Full emulation of applications and the OS – i.e. RPCemu, running on top of another OS, and not necessarily on ARM
2. Emulation of apps, but with the OS as either
   1. A native set of routines running on top of another OS, again not necessarily on ARM
   2. A 32 to 64 bit translation layer on top of a full native RISC OS on 64 bit ARM

The advantage of 2.2 being you could have fully native 64 bit applications (freed of a lot of the limitations of existing RISC OS), but do we have enough developers to make this happen?

From:
https://www.riscosopen.org/forum/forums/12/topics/15842?page=5#posts-129275

16 Dec 2021, theregister.com: What does 2022 have in store for Asahi Linux on Apple chips? Drivers aplenty, but that GPU still needs tackling.
Handily, the team spotted a bug in Linux’s ARM SMMU support too
Quote: "…
“Amusingly,” Martin wrote, "while implementing support for this in Linux, we ran into a bug in Linux’s ARM SMMU support that had been there ever since 52-bit address support was introduced.
…
“This was breaking systems with more than 256 TiB of RAM – I wonder why nobody noticed? Either way, Linux now correctly supports standard ARM systems with up to 4 PiB of RAM.”
…
There is still plenty of work to be done, not least in the audio department. The next area of focus, according to Martin, is Wi-Fi. Besides a number of other bits of coding (including RTC support), there is also that pesky GPU kernel driver to be tackled (although Martin reported that the userspace is in “good shape”).
At the current rate of development, it seems entirely possible that Asahi Linux could be booting on a Mac near you in 2022.
…"

Posting from Asahi Linux on a M1 Apple machine, take a look at the RISC OS on QEMU posts.
Perhaps someone can try to build under OSX and see if it can be made to work. It definitely would not surprise me.