In article <20210820224126.GB31179@chiark.greenend.org.uk>,
Theo Markettos <theo@markettos.org.uk> wrote:
> 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.
Just the thoughts of a vaguely interested bystander with no technical
knowledge.
I can understand the usefulness of being able to emulate the RPC for
compatibility with old software but with Rapis so cheap I can see little
point of trying to model it. I, for example, recently purchased an
over-clocked Pi in a nice case with RO5 and a software bundle included,
for under 100 quid.
Incidentally, I find Iris, despite only being Beta, works quite well.
--
Stuart Winsor
Tools With A Mission
sending tools across the world
http://www.twam.co.uk/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Tuesday, 24 August 2021
Re: [Rpcemu] RPCEmu licence and other topics
In message <20210823203000.GE31179@chiark.greenend.org.uk> you wrote:
> 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.
There is even a name for this: paravirtualisation.
>> 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.
I think there are two ways to do this:
1/ Adapt RISC OS to QEMU. Problem: since QEMU is mainly a Linux beast and
that we already have RISC OS on Linux, it could be see as some duplicate
effort (at least on the ARM side). IMHO, it would be better to put the
effort on RISC OS on Linux, as it's a very good way to support any ARM
board.
2/ Make RPCEMu and RISC OS 5 going closer. Would it possible to have a new
hardware type (Pheobe II?) with more possibilities, virtual hardware more
easy to emulate and a RISC OS version for it? I would certainly invest
some money on this specific project as it would give me an alternative way
to distribute some of my software.
It would be nice too to finish the RISC OS port of RPCEmu. For now, the
keyboard does not work... but I suspect the patches made for macOS could
give some clues. a JIT would be needed too (and could be useful for the
Raspberry Pi OS version). I've already said I could fund part (if not all)
of this project.
David
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> 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.
There is even a name for this: paravirtualisation.
>> 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.
I think there are two ways to do this:
1/ Adapt RISC OS to QEMU. Problem: since QEMU is mainly a Linux beast and
that we already have RISC OS on Linux, it could be see as some duplicate
effort (at least on the ARM side). IMHO, it would be better to put the
effort on RISC OS on Linux, as it's a very good way to support any ARM
board.
2/ Make RPCEMu and RISC OS 5 going closer. Would it possible to have a new
hardware type (Pheobe II?) with more possibilities, virtual hardware more
easy to emulate and a RISC OS version for it? I would certainly invest
some money on this specific project as it would give me an alternative way
to distribute some of my software.
It would be nice too to finish the RISC OS port of RPCEmu. For now, the
keyboard does not work... but I suspect the patches made for macOS could
give some clues. a JIT would be needed too (and could be useful for the
Raspberry Pi OS version). I've already said I could fund part (if not all)
of this project.
David
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Monday, 23 August 2021
Re: [Rpcemu] RPCEmu licence and other topics
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
>
> 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
Saturday, 21 August 2021
Re: [Rpcemu] RPCEmu licence and other topics
On 20/08/2021 23:51, David Glover wrote:
> On Aug 20, 2021, at 8:57 AM, Peter Howkins <rpcemu.howkins at marutan.net> wrote:
>>
>> For the avoidance of any doubt RPCEmu (and any program that uses any code
>> from RPCEmu) will remain under the GNU General Public Licence Version 2 (or
>> later version of the GNU General Public licence).
>
> I have nothing significant to add but I would like to say that I fully approve > of RPCEmu remaining under the GPL,
I also completely agree with Peter's reply and that RPCEmu (and any
derivatives) should remain under the GPL.
The suggested renaming is also a bit silly. I'd imagine most of them
will also fall foul of trademarks, whether for RISC OS (I'm not certain
on the trademark status of RISC OS itself) or Windows/Mac trademarks.
"RPCEmu+" also seems like a thinly veiled attempt to make it look like
their version is in some way better than the original project, which (as
Peter rightly points out) would just serve to confuse users.
> and that I an extremely suspicious of the > "Cloverleaf" project, which hosted a borderline scam Kickstarter
promising> things that were impractical or impossible.>
> This now deleted Twitter thread from a few months ago was very concerning:
> https://david.gloveraoki.net/f/cloverleaf.png
For what it's worth, there's a screenshot of the deleted tweet that's
missing in that screenshot here, in which I was wished a happy troll day
by Cloverleaf (and yes, I'm still blocked):
https://twitter.com/acp/status/1390043478109917189
Cheers,
Andy.
--
Andrew Poole
Email: andrew@andrewpoole.org.uk
Web: https://www.andrewpoole.org.uk/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> On Aug 20, 2021, at 8:57 AM, Peter Howkins <rpcemu.howkins at marutan.net> wrote:
>>
>> For the avoidance of any doubt RPCEmu (and any program that uses any code
>> from RPCEmu) will remain under the GNU General Public Licence Version 2 (or
>> later version of the GNU General Public licence).
>
> I have nothing significant to add but I would like to say that I fully approve > of RPCEmu remaining under the GPL,
I also completely agree with Peter's reply and that RPCEmu (and any
derivatives) should remain under the GPL.
The suggested renaming is also a bit silly. I'd imagine most of them
will also fall foul of trademarks, whether for RISC OS (I'm not certain
on the trademark status of RISC OS itself) or Windows/Mac trademarks.
"RPCEmu+" also seems like a thinly veiled attempt to make it look like
their version is in some way better than the original project, which (as
Peter rightly points out) would just serve to confuse users.
> and that I an extremely suspicious of the > "Cloverleaf" project, which hosted a borderline scam Kickstarter
promising> things that were impractical or impossible.>
> This now deleted Twitter thread from a few months ago was very concerning:
> https://david.gloveraoki.net/f/cloverleaf.png
For what it's worth, there's a screenshot of the deleted tweet that's
missing in that screenshot here, in which I was wished a happy troll day
by Cloverleaf (and yes, I'm still blocked):
https://twitter.com/acp/status/1390043478109917189
Cheers,
Andy.
--
Andrew Poole
Email: andrew@andrewpoole.org.uk
Web: https://www.andrewpoole.org.uk/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Friday, 20 August 2021
Re: [Rpcemu] RPCEmu licence and other topics
On Aug 20, 2021, at 8:57 AM, Peter Howkins <rpcemu.howkins@marutan.net> wrote:
>
> For the avoidance of any doubt RPCEmu (and any program that uses any code
> from RPCEmu) will remain under the GNU General Public Licence Version 2 (or
> later version of the GNU General Public licence).
I have nothing significant to add but I would like to say that I fully approve of RPCEmu remaining under the GPL, and that I an extremely suspicious of the "Cloverleaf" project, which hosted a borderline scam Kickstarter promising things that were impractical or impossible.
This now deleted Twitter thread from a few months ago was very concerning:
https://david.gloveraoki.net/f/cloverleaf.png
David.
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
>
> For the avoidance of any doubt RPCEmu (and any program that uses any code
> from RPCEmu) will remain under the GNU General Public Licence Version 2 (or
> later version of the GNU General Public licence).
I have nothing significant to add but I would like to say that I fully approve of RPCEmu remaining under the GPL, and that I an extremely suspicious of the "Cloverleaf" project, which hosted a borderline scam Kickstarter promising things that were impractical or impossible.
This now deleted Twitter thread from a few months ago was very concerning:
https://david.gloveraoki.net/f/cloverleaf.png
David.
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu licence and other topics
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
> 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
Re: [Rpcemu] RPCEmu licence and other topics
Hello Peter,
I hope everything is good with you. I wanted to follow up your offer on
Twitter to provide us with an extended licence. What exactly did you have
in mind, and how can I help to make that happen?
Hello Stefan and Andrew,
I do not remember offering to change the licence of RPCEmu for you, it is
I do not remember offering to change the licence of RPCEmu for you, it is
not possible for me to do that;
1) Changing the licence would need the agreement of every person who has
contributed to RPCEmu. That is over 20 people.
2) Even if every other person agreed, I do not, so it will not be changed.
For the avoidance of any doubt RPCEmu (and any program that uses any code
from RPCEmu) will remain under the GNU General Public Licence Version 2 (or
later version of the GNU General Public licence).
1) Changing the licence would need the agreement of every person who has
contributed to RPCEmu. That is over 20 people.
2) Even if every other person agreed, I do not, so it will not be changed.
For the avoidance of any doubt RPCEmu (and any program that uses any code
from RPCEmu) will remain under the GNU General Public Licence Version 2 (or
later version of the GNU General Public licence).
What I'd like to do is the following:
I'd like to bundle RPCEmu with the Cloverleaf RISC OS distro for
convenience for people who want to use it for the first time,but don't have ARM hardware available.With my campaign I want to find new RISC OS users so some might be inetrested but not readyto buy new hardware to test RISC OS. So the RPCEmu is a door-opener for new users.
I am failing to see any advantage of this new product over the 'RPCEmu and
RISC OS Direct bundle' that's already available. Could you explain why you do
not support that effort?
RISC OS Direct bundle' that's already available. Could you explain why you do
not support that effort?
If we're charging, we *will* be including unique/commercial software to ensure peopleget good value for money. And all the money will make with it will be put intopromoting RISC OS and speed up it's development and provide more applications.
I'd like to feedback the changes we've made to the master copyof RPCemu so that nothing gets forked. So if you have also some wishesor suggestions for RPCEmu then let me know.
I do have some suggestions regarding your recent patch that I will send in a separate email.
I will put a link to your website in the product info, so it is
clear to everyone that RPCemu is free to use.
Ideally, I'd like to change the name for our product because new
users (esp overseas) will not know what an "RPC" is. Also for
better marketing!
Possibilities include:
a) WindowsRISC OS, macRISCOS, LinuxRISCOS
b) RISCOS4Windows, RISCOS4macOS, RISCOS4Linux (4 = for; not RISC OS 4)
b) RPCEmu+ (if you feel we should retain RPCemu brand)
I do not want to change the name of RPCEmu. It has a 16 year history, is
easily found via search engines and it has several thousand users that
I don't want to confuse.
easily found via search engines and it has several thousand users that
I don't want to confuse.
When you have time, it'd be good to discuss future directions for RPCemu,
and whether my programmers can assist. For example, it would be nice to
go further with RISC OS 5, and implement a virtual ARMv7 (for example)
platform.
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
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.
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.
The other question I had regards RAM. My programmer said that this is
implemented as 2 memory block of 128MB. I assume this is limited by the
emulation of RPC hardware?
With regards to RAM, yes there is only a 256MB space in the Risc PC physical
memory map for RAM. There is an addon card for the Risc PC (the Kinetic card)
that increases this to 512MB (but with some additional limitations). Again the
'work' versus 'benefit' isn't met for me as the only program that will
use that memory is a browser, and only a small number of RISC OS versions
memory map for RAM. There is an addon card for the Risc PC (the Kinetic card)
that increases this to 512MB (but with some additional limitations). Again the
'work' versus 'benefit' isn't met for me as the only program that will
use that memory is a browser, and only a small number of RISC OS versions
can use the Kinetic card.
Andrew notes arising:
In your original email you said two blocks of 128 KB. I *think*
this should be MB, since RiscPC could in theory do 2x 128MB.
Stability could be an issue with that on 26bit OSs because
programs often didn't react well to more than about 140MB.
However, I doubt that's an issue on RISC OS 5.
Comment on names. I tend to prefer the "RISCOS4Windows", BUT
this sounds like RISC OS 4, which is the obsolete 26bit OS. I
suppose we need RISCOS5Windows but that doesn't sound good.
Maybe winRISC, macRISC, linRISC?
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.
Peter Howkins
Co-signed by
Matthew Howkins
Sarah Walker
allow users to run obsolete software. Whether you consider RISC OS 3, 4, 5
or 6 is obsolete, is left as a personal choice.
Peter Howkins
Co-signed by
Matthew Howkins
Sarah Walker
A copy of this email has been sent to the RPCEmu mailing list, so that other
developers and users are aware.
Subscribe to:
Posts (Atom)