On Fri, Aug 20, 2021 at 04:57:22PM +0100, Peter Howkins wrote:
> RPCEmu doesn't support ARMv7 and is not likely to in the future for several
> technical and practical reasons.
>
> 1) Going from ARMv4 to ARMv7 does not offer any speed benefits when being
> emulated. The more complex instructions in v7 would need roughly the same
> number of host-cpu cycles to emulate as multiple simpler ARMv4
> instructions
>
> 2) The number of new instructions in ARMv7 vs ARMv4 is more than 500.
> It is roughly 6 times the number we currently emulate (This number
> includes Thumb instructions, but does not include NEON or VFP).
> This is a massive job to complete.
>
> 3) There is no Operating System for this. There is no RISC OS available that
> targets an ARMv7 CPU on top of IOMD (Risc PC) hardware. As such you'd
> have
> to compile up custom OSes for this hardware *or* emulate the rest of the
> system of an existing platform such as the Beagleboard or the Raspberry
> Pi
> (this is an even larger job than updating the CPU emulation).
>
> 4) There is hardly any RISC OS software that actually uses ARMv7, the most
> important of which is a web Browser. On an emulated system people will
> use the browser on windows/linux/mac as it will run considerably faster.
>
> The balance of 'work' versus 'benefit' will not be reached for me. However
> as
> this is an open project, anyone is welcome to work on any feature that they
> want to.
FWIW I agree with most of what Peter says here. The moment you change
RPCEmu to not model the Risc PC hardware you now need a fork of the OS. The
more you graft in, the less it's a Risc PC - essentially all you are sharing
is the GUI.
No.4 is a bit of chicken and egg: VFP hardware floating point is worth
having and supported in GCC 10, but it's not available because of the need
to support ARMv3/4 (RPCEmu), v5 (Iyonix) and v6 (RPi 1 and Zero - only older
VFP). It would not be infeasible to build ARMv3 and ARMv7 packages to
satisfy both audiences.
> RPCEmu is an emulation of a 27 year old computer, its main purpose is to
> allow users to run obsolete software. Whether you consider RISC OS 3, 4, 5
> or 6 is obsolete, is left as a personal choice.
+1
I did have a go at running RISC OS 5 on QEMU's raspi2 emulation and I
immediately ran into some problems. QEMU provides a gdb interface which
makes it relatively rapid to drill down into where things are going wrong
(the main annoyance is that it can't understand RISC OS' debug symbols)
A trivial problem was this one:
https://www.riscosopen.org/forum/forums/3/topics/16552
- the Pi uses an undocumented power control interface that isn't implemented
in QEMU and causes RISC OS to hang waiting for an answer that never comes -
it's straightforward to switch to the documented interface.
but more troubling is this one:
https://www.riscosopen.org/forum/forums/3/topics/11109
- the RISC OS timer code uses a Pi-specific timer, which is not supported in
QEMU. The Cortex cores have their own timer internally, that it would be
better for RISC OS to use across all its platforms, but that requires
substantial refactoring of the timer subsystem. That's a task that will
have to be done sooner or later and would benefit RISC OS as a whole. It
would be less work to modify QEMU, but that makes host side things much more
painful (need a custom build, can't use a stock download, needs to be signed on
Mac, etc etc).
I think a more fruitful avenue for someone with more time than me would be
to sort out some of these issues in porting RISC OS to ARMv7 QEMU, which
would then make use of all the good stuff QEMU has (fast recompilers, native
hypervisor support, GUIs, etc).
I respect Peter et al's opinions on the direction of RPCEmu, so perhaps
Stefan might think about this as an alternative direction.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
No comments:
Post a Comment