On Mon, Aug 23, 2021 at 02:07:29PM +0100, A Rawnsley wrote:
>
> I just wanted to post a "thankyou" to Theo for such an excellent and
> researched email. Really appreciated.
Hi Andrew,
Some further thoughts below...
> Personally I always felt that the evolution of a virtual system (be it
> VRPC, RPCemu or something else) into a system where you could control both
> sides of the emulation equation (the virtual hardware presented *and* the
> open source OS/HAL) offered perhaps the most interesting future direction
> for such products, but perhaps independent of their current incarnations.
I agree, there are plenty of interesting things involving putting layers
underneath RISC OS.
However there is an advantage being able to run things 'stock' - ie boot an
image in a hypervisor/emulator/whatever without modifying the emulation
environment. That means you don't have to worry about maintaining and
distributing that platform, you just tell people 'download <whatever>', and
it's probably already in their store/package manager.
There is no reason why RISC OS can't boot in a mainstream ARM emulation
environment, it's just that RISC OS has a habit of doing things its own way
that have historically been tailored to the specific platforms it runs on.
Which is why RPCEmu has to emulate a Risc PC, including all the limitations
of that platform, and not a generic ARM system with parts taken from a
standard bin. It's why we can't just swap out the CPU emulation in RPCEmu
to ARMv7 and expect RISC OS to work.
Other ARM platforms have largely coalesced around Device Tree, which is a
way to specify what hardware a system has and so the OS can configure itself
appropriately, which means you don't need to compile the OS for every single
variation of the hardware. This is not something RISC OS supports - many
decisions are baked in at compile time.
> In thinking about this, my intention is not to belittle VRPC or RPCemu
> (which both excellently fulfill the role of emulation of my favourite
> Acorn machines) but rather to see how emulation could take us forwards in
> interesting directions with suitable HALs etc, perhaps exposing new
> technologies without the need to fully implement hardware drivers on the
> RISC OS end. Particularly in light of ARM's move to 64bit exclusivity,
> and RISC OS' lack of readiness for such a move.
I think this could be a two-stage process: put an emulation/hypervisor layer
underneath so RISC OS isn't so wedded to the physical hardware any more, and
then think about what RISC OS could run on top of inside the emulator - for
example that could be some kind of microkernel. This is easier to do when
the microkernel doesn't need drivers for umpteen hardware platforms out
there, and it avoids such a tight tie to the underlying architecture.
> I must admit, I've never spent much time with qemu (beyond knowing of its
> existance and purpose) because I didn't think it offered enough of a
> system emulation to allow RISC OS to run, but this is probably my
> ignorance, and I think perhaps the "RISC OS for Linux" guys offer
> interesting approaches there.
>
> I was also under the impression that Qemu was a less efficient form of ARM
> emulation compared to the JIT approach of RPCemu/VRPC. Is this an
> incorrect assumption? (From Theo's email, it does sound like it).
QEMU is a full system emulator - it emulates the CPU, memory and a huge
range of peripherals across many architectures. We are using it as a system
emulator to bring up OSes on new ARM silicon before it comes out of the fab,
for example.
The main difference in instruction emulation is that RPCEmu has a hand-coded
JIT for 32- and 64-bit Intel CPUs. QEMU uses the compiler to generate
fragments of code for whatever CPU it's compiled for (which is many
platforms), and then stitches them together. It's difficult to compare them
(would need to boot Linux on RPCEmu and run some benchmarks[1]), but
elsewhere I've run QEMU emulating a 64-bit MIPS CPU and got ~500 MIPS on a
~2013 server. So I would expect emulation performance to be broadly
comparable.
A useful feature of QEMU is that it hooks into native KVM hypervisor support on
64-bit ARM on Linux which, assuming your CPU supports 32-bit instructions,
gets you native performance. If you don't have 32-bit instructions, or are
on a non-ARM platform, it has to emulate them (sadly Apple's ARM cores don't
support 32 bit).
([1] If anyone has a recent-ish Linux distro available on RPCEmu I could
probably run some benchmarks on various hardware to compare RPCEmu and QEMU.
Russell King, the Linux/arm maintainer and original porter of Linux to the
A5000, still maintains the RPC support in mainline Linux so in theory it
still works, but distros supporting ARMv4 (not ARMv4T) are trickier.)
The main thing you don't get with QEMU is the RISC OS integration with
things like HostFS, networking and shared clipboards. Or rather, QEMU has
its own implementations of those, so no work needs to be done host-side, but
the RISC OS modules for HostFS/etc would need adaptation to use them rather
than the RPCEmu way of doing things. For things like networking, QEMU
already provides models of existing ethernet cards and it's possible that
it could be less work to hook up RISC OS' existing drivers to those,
although better performance would be achieved by using emulation-friendly
interfaces like VirtIO.
> Incidentally, if anyone wanted to propose a bill-of-work for any of the
> challenges Theo raises, ROD would give serious consideration to funding
> them. I do not see why complex work needs to be necessarily done for
> free. No promises, though - I am answerable to the rest of the board on
> financial commitments, and we're a democracy.
This is hard to judge because you don't know what the next issue is going to
be until you fix the previous one. But addressing the timer issue is
a step that's useful across the many platforms on which RISC OS runs.
This is Jeffrey's current state of play, where he's asking for help:
https://www.riscosopen.org/forum/forums/3/topics/11109?page=3#posts-123553
It could be worth looking for someone to pick up that work.
Alternatively QEMU could be hacked up to bypass the issue in the short
term, at least to see what other problems lie beyond. How much it's worth
maintaining a fork of QEMU, or trying to merge changes into mainline, is up
for discussion.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
No comments:
Post a Comment