Idle speculation?

Informal forum to keep you all informed on development progress

Moderators: aemulor, admin

Post Reply
Site Admin
Posts: 381
Joined: Wed Oct 23, 2002 11:25 pm
Location: Cambridge, England

Idle speculation?

Post by admin » Sat Jun 19, 2004 9:02 pm

With Castle having publicly mooted the idea of RISC OS 5 on non-Iyonix such as the (Virtual)RPC, sooner or later someone's going to ask what happens about compatibility with old(er) apps which haven't been made 32-bit neutral.

Such an OS, running in 32-bit modes, would be highly likely to call all application code in 32-bit modes as well, which is much less of a problem now than it seemed 2 years ago because so many apps have been converted, but what about the others? Sibelius, Impression (at least until such time as the 32-bit version appears), Eureka, PipeDream, Fresco, Browse and the myriad other little utilities that are still used.

They'll break, if run in a 32-bit mode, just as they do natively on the Iyonix.

So, could we port Aemulor? Here are a few thoughts:

* there should be no need to actually emulate 26-bit CPU modes on a (V)RPC, because those modes are still available and it should still be possible to call RO5 SWIs from 26-bit modes, however...

* the API changes will still exist, ie. flags will not be preserved, some SWIs have their register usage altered etc.

* any code that the application tries to register with the OS (callback handlers, voice generators, environment handlers, filing systems...) will be called in 32-bit modes so these callbacks must be wrapped to switch into 26-bit mode.

* addressing changes will likely still apply, ie. the RMA will be at high addresses so 26-bit modules can't be loaded & executed directly.

So, most of the work that's gone into Aemulor already will still be needed for running this 26-bit code on (V)RPC, just not the instruction emulation (which is fortunate because it would can be rather slow emulating them without being able to use Aemulor's StrongARM engine; it relies upon hardware features of the XScale core).

Also, there'd be no need to emulate the low-colour screen modes, of course, because the hardware can already do them.

So what we end up with is an appreciably different beast to the Aemulor that exists now, but with a good degree of overlap - in effect a slightly stripped-down Aemulor, in that the StrongARM engine would be replaced by simpler code for catching the transitions between 26- and 32-bit code which can be performed with minimal overhead.

It'd be beneficial to leave the ARM610 and ARM3 engines in place for running software that doesn't work natively on the StrongARM engine and even with these a lot of software remains surprisingly quick as we discovered when first prototyping Aemulor on RISC OS 4 machines.

There's some overlap here with another suggested use of Aemulor too - that of running old games on a StrongARM RiscPC - so it's something that I'll probably consider further and/or prototype in the future.

All in all, I think a single 32-bit RISC OS for all our machines would be a very good idea, bringing new features to all users and a single programming API for all developers. Compatibility needn't be a problem. On a (V)RPC you could also have the fallback of softloading your old OS if
you can't run the old side-by-side with the new.

Post Reply