Bounty for JIT enabled E-UAE for AmigaOS4.1

[Troels_E]

E-UAE on AmigaOS4.1 (and MorphOS) supports  only interpretive emulation and is quite slow compared to f.ex. winUAE.
What's needed is JIT 68K code emulation to speed things up.
Especially AmigaOS4.1 users with slower machines will gain a lot from a JIT version of E-UAE.

As the JIT will automatically become open source, other PPC platforms will also be able to benefit from it.

As a minimum the project should be able to.
- Bring JIT 68k code emulation to the OS4 version of E-UAE.
- Work with a number of specified games and applications that runs
(slow) under the OS4 version of E-UAE.


Click the link below to visit the project page.
http://amigabounty.net/?function=viewproject&projectid=35

[Karlos]

Since OS4.x already has a JIT, is there any way in which Petunia could be employed for the purpose of emulating the 68K?

Of course it would have to remain external and UAE hook into it somehow. I don't suppose it would be good to get the closed source OS internals tangled up with an open source project like this.

[Piru]

Since OS4.x already has a JIT, is there any way in which Petunia could be employed for the purpose of emulating the 68K?

In practice no. Petunia (and Trance) try to be as fast as possible. Adding some address translation and trapping of specific addresses (custom, cia etc) to all memory accesses would generate ton of extra code. In any case it would require a lot of work on the actual JIT engine itself. This is unlikely to happen.

For any OS component to be usable for GPL application it first needs to be released as part of the OS. Also, releasing such update just to circumvent the GPL license would not be seen as very sportsmanlike I'd think.

[hooligan]

Just don't tell this to some of those in "real amiga vs winuae"-thread.. might shock them :-)

[Karlos]

In practice no. Petunia (and Trance) try to be as fast as possible. Adding some address translation and trapping of specific addresses (custom, cia etc) to all memory accesses would generate ton of extra code. In any case it would require a lot of work on the actual JIT engine itself. This is unlikely to happen.

To be honest I thought about that a bit more after I posted. However the guys that wrote Petunia and Trance would have a head start over the rest when it comes to attempting this one, methinks.

For any OS component to be usable for GPL application it first needs to be released as part of the OS. Also, releasing such update just to circumvent the GPL license would not be seen as very sportsmanlike I'd think.

I was thinking purely from a technical angle rather than a open v closed source political one.

You know, it's a bit of a pity that the respective operating systems don't provide API's into the JIT that let you build your own emulated 68K based "machine" applications around the OS provided JIT core. I realise there's no requirement for this from the OS point of view, it'd just be really cool to play with.

[Piru]

However the guys that wrote Petunia and Trance would have a head start over the rest when it comes to attempting this one, methinks.

Of course, but I think it is very unlikely you'll see anything from them.

I was thinking purely from a technical angle rather than a open v closed source political one.

Fair enough.

You know, it's a bit of a pity that the respective operating systems don't provide API's into the JIT that let you build your own emulated 68K based "machine" applications around the OS provided JIT core. I realise there's no requirement for this from the OS point of view, it'd just be really cool to play with.

As I was trying to explain it is not possible to add this to JIT and not have a huge performance hit. As such you'd pretty much end up with two completely separate engines; one for OS stuff and one for emulation. Just writing one JIT engine is hard enough.

[Trev]

You could implement a 68K to 68K compiler that treats Petunia as the target architecture, replacing all legacy hardware code with calls into the core E-UAE emulator. The performance hit still sounds atrocious, though. What types of applications would benefit from this that don't already benefit from Petunia?

Re: GPL, I don't see any conflicts. Petunia is an operating system service, just like file I/O and memory allocation.

[Piru]

You could implement a 68K to 68K compiler that treats Petunia as the target architecture, replacing all legacy hardware code with calls into the core E-UAE emulator. The performance hit still sounds atrocious, though.

As I understand your idea all memory accesses would result in calls to UAE. Only instructions without any memory accesses could be left as-is. I'd estimate it'd be slower than UAE itself, except for some very specific tight computational loops.

Re: GPL, I don't see any conflicts. Petunia is an operating system service, just like file I/O and memory allocation.

Petunia - as it is now - cannot be used in any sensible way (and neither Trance before someone asks).

[Trev]

As I understand your idea all memory accesses would result in calls to UAE.

Without a virtual address space, yes. Bummer.

[BooBoo1200]

From Project Petunia HomePage.
Do you plan any support for UAE?
I don't know yet. There is a possibility of reaching the emulation from the "outside", so theoretically UAE could make use of Petunia's engine, if somebody does a special version. I don't intend to do it, but I would help gladly help to anybody with this work.

[Trev]

If it's possible to host and use Petunia in a context separate from the operating system's, then it makes sense to do so. Why write your own service when the operating system already provides one?

[kolla]

The obvious question is... does old m68k shapeshifter run on OS4 or/and MorphOS using JIT?

[Karlos]

The obvious question is... does old m68k shapeshifter run on OS4 or/and MorphOS using JIT?

Interesting question. One I might try and find out an answer to tonight

[BooBoo1200]

What about e-uae 68k I was told this is faster than native e-uae.