@Oepabakkes

I don't know if that (using MorphOS's built in JIT engine) would really work. It would seem that to get e-uae to use the built in engine that e-uae would have to be 68k based itself... However, I seem to remember with Amithlon there was something that forced calls to the Paula chip to go through AHI.

To me, this indicates that if 100% emulation is desired, then an emulation layer is the prescription. Any OS can be considered layered, and the slick part of the classic Amiga was that there were shortcuts to the hardware throughout the OS (the younger generation can relate DirectX to the design of the original AmigaDOS). Thus, if we have an emulation "layer" sitting behind the Amiga calls, then we can intercept all of the hardware calls. That would get the 68k calls to MorphOS's JIT, Paula to AHI, and we'de need something to live between the gfx driver and UAE as well. I think if done this way, it would be doable, as this layer could be integrated to the OS in way similar to the way WinXP has the checkmarks for application compatability in the icon-properties tab. IE, run a program, if it doesn't work right natively then tick on the checkmark from "info" and activate the E-UAE layer....

With all of that said, I do have to bring back Neko's questioning of the ultimate purpose of such: what real benefit is there to be gained beyond access to 20-year-old games?

does there have to be another benefit ?

@Oepabakkes
Quote:
No


Technical: Trance is highly optimized and as such is not suitable for UAE. For example UAE needs address translation which just isn't available in Trance. There would also need to be a way to integrate the emulation to UAE, and such interface just isn't there. Finally, while technically compliant with the GPL license (the JIT being part of an Operating System itself), I'd still feel a bit icky about adding such interface just for UAE.

> to get e-uae to use the built in engine that e-uae would have to be
> 68k based itself...

I think you mix up the code E-UAE consists of with the code executed by E-UAE.

> with Amithlon there was something that forced calls to the Paula
> chip to go through AHI.

E-UAE already has Paula emulation and AHI output, so no need for something like NallePUH, even if Trance could be used within E-UAE.

> if we have an emulation "layer" sitting behind the Amiga calls,
> then we can intercept all of the hardware calls.

Yes, that layer would be E-UAE.

> That would get the 68k calls to MorphOS's JIT

How? I think it would rather get the m68k calls to the layer's (i.e. E-UAE's) m68k emulation.

> we'de need something to live between the gfx driver and UAE as well.

It's already there: CGX (or SDL on CGX).

> I think if done this way, it would be doable

It's already done "this way", and it doesn't seem doable to make use of Trance within E-UAE.

@piru

just trying to understand....

If I understand it well, trance running in MorphOS isn't useable because it's to much integrated in the OS. Now would converting Trance in a "module" or whatever it should be called for E-UAE be more difficult as writing a new one ?
And I have seen that the x86 E-uae apparently makes use of a 68k/x86 JIT now on AROS, can a 68k/PPC jit (if it would exist ) be integrated in E-UAE for MorhpOS/AROS/OS4/whatever-PPC just be replacing that X86 jit ? Or how does it probably work?

And is there any interest in doing this from your side ?

@Oepabakkes
Quote:
Not entirely. Mostly it's because Trance has been optimized to the maximum possible speed. There are no considerations for memory translation or custom chipset trapping. The emulation inside MorphOS (both static 68k emulation and Trance) were designed to ignore all chipset emulation from the start. But indeed Trance also interfaces to MorphOS in some fancy ways, there simply is no way to make the service available for any external applications for example.
Quote:
Yes. Or at least way too much work for anyone to volunteer. Not to mention Trance is very advanced and highly complex code and there aren't many in the MorphOS Team who even understand it well, let alone dare to touch it.
Quote:
Yes. It'd probably also need some OS dependant additional code, but mostly it should be pretty straight forward I believe. That being said, I haven't really looked into UAE x86 JIT closely.
Quote:
None.

@Oepabakkes

Look at Andreas Wolf's post in this thread, now you just need to find someone capable/willing to do the actual work.. if the offer is still open, good luck with that.

Well for now it was an interesting read, but I doubt someone actually wants to do it. And if there is, I suppose the only thing he has to do is to state that here and tell us how much he wants for the effort.

Lets see how those AGA games run in MacMini with UEA and then we can come back here and cry for the need of JIT :)

No need to wait - run an old ver of WinUEA on any 5 year old PC without JIT and then come back and cry :)

Quote:

+100

> the x86 E-uae apparently makes use of a 68k/x86 JIT now on AROS

Yes, if "now" means "for 4 years already" :-)

really ? didn't know that. I thought only WINuae had a jit.

@Oepabakkes

UAE's JIT was developed on linux.

well, guess I learned something today

Update:

> Bernd Meyer one year ago:
> "Both Umilator and the 68k-to-PPC JIT are somewhere on some hard disk,
> and it probably wouldn't take me more than a couple of hours to find them. [...]"

"Bernd destroyed all the source code for it including backups."
http://www.amiga.org/forums/showpost.php?p=772556

An email discussion I had with the WinUAE guys can be applied here. The concept was about replacing Winuae code with platform native libraries. For example: when the emulated Amiga call's jpeg.datatype, no local M68K code will be excuted, but the emulator will actually call for example the windows GDI jpg decode function and winuae would have to tranfer the Windows bitmap with a transform to the amiga format. The emulator itself would have to monitor the library call's the amiga system would have to be made. This could be applied for all datatypes.

I Suppose (don't know) thats how AHI also works, and I suppose MorphOs will probably also do that to run native M68K code.

That same thing could be done for FPU functions etc.

Cheers


[ Edited by Roland 25.09.2014 - 13:17 ]

@ Roland

What would be the use of this? Do you think it is faster to send data from OS3 to Win back to OS3 rather than emulating it? In some cases you will also have to convert the endianness.

> That same thing could be done for FPU functions

I think WinUAE already converts m68k FPU code to x86(-64) FPU code and has it executed in hardware by the host system's x86(-64) FPU.

Quote:

Why would you use PPC inside an emulated amiga? Speed or functionality? If its about speed,you can calculate the speed improvement (or not) per CPU function/library/etc :)

Luckily for us, not all operations require correction. I have build many interpreters for my job, I know the headache involved in emulating processors. Software emulationg is overhead.

I/O is usually a pain in the butt. How much time does a memory transfer take? Throwing the pointer to the amiga internal memory regions is faster. Since the amiga (emulator) is calling the library you don't always need to transfer blocks.

But if speed is important, you can also rebuild kickstart and map kickstart functions to platform native calls. If my HD is a directory on my workstation, then let kickstart call native fopen() etc.


The real issue is capacity and the size of the project. Rebuilding code that other people have made is a real nightmare and tweaking speed at different places requires different changes in code that break portability.




[ Edited by Roland 26.09.2014 - 10:36 ]

There's already a version of E-UAE with PPC JIT available for MorphOS (among other OSs):
E-UAE JIT blog

> There's already a version of E-UAE with PPC JIT available for MorphOS (among other OSs):
> E-UAE JIT blog

Indeed, and MorphZone has threads about that (even with better builds than the official ones):

https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=10174&forum=9
https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=10143&forum=9
https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=8762&forum=3

I thought I had to mention the existence of a E-UAE PPC JIT here since this thread seems obsolete to me now.