Continuing the discussion from here: https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=43330&forum=16&start=600&viewmode=flat&order=0#881001

@Hammer

Quote:

Hammer wrote: @ppcamiga1 Quote: ppcamiga1 wrote: if you using pistorm you are idiot because you may have the some for zero euro just use winuae on pc FYI, there are plans for PPC emulation with Emu68 since it has unused CPU cores.

You don't need an extra core only for it. Even with the PowerPC acceleration cards for Amigas, only a single CPU is used at the same time (the 68k was put on hold when the PowerPC was running).

Extra cores can be used for additional tasks (e.g.: offloading tasks to the host system, or optimizing code hot spots), but certainly not for emulating multiple CPUs in parallel (at least for the Emu68 scope / how it workds).
Quote:

AArch64's big-endian mode and 32 GPR programming model have less translation overhead when compared to little-endian/16 GPR X86-64's PPC emulation. AArch64 can match PPC on arithmetic operations and the discrete load-store RISC instruction model.

I doubt that the MOVBE instruction is used on (Win)UAE JIT, and here a good performance boost can come.

Besides that, x86-64 has other advantages compared to AArch64: load-op, op-store, rep instructions, and especially large immediates support. So, the CISC way -> it's easier to mimick the 68k code execution, and it's also more efficient (less pipeline stalls due to depending, less instructions executed).

@cdimauro

Well, since we're talking 68K emulation, I'll just leave this here: https://github.com/0xABADCAFE/68PHPhousand

_________________
Doing stupid things for fun...

@cdimauro

Quote:

You don't need an extra core only for it. Even with the PowerPC acceleration cards for Amigas, only a single CPU is used at the same time (the 68k was put on hold when the PowerPC was running).

Go argue with Emu68's author.

Using another CPU core has its own L1 cache and register storage. It's unwise to add extra workload on the 68K role CPU core's L1 cache and register storage.

Are you arguing for unloading 68K instructions from the primary CPU's L1 cache/registers with PPC instructions?

Emu68's speed is about single-tasking without being disturbed by other workloads from a hosted Linux OS. Context switching has a cost.

Current Emu68 is using two CPU cores i.e. one for 68K translation and one for I/O. Debug uses another CPU core.

Last edited by Hammer on 08-Sep-2025 at 06:45 PM.
Last edited by Hammer on 08-Sep-2025 at 06:42 PM.
Last edited by Hammer on 08-Sep-2025 at 06:39 PM.
Last edited by Hammer on 08-Sep-2025 at 06:36 PM.
Last edited by Hammer on 08-Sep-2025 at 06:32 PM.
Last edited by Hammer on 08-Sep-2025 at 06:25 PM.

_________________

@Hammer

could use a third core for chipset emulation too if he added that

_________________

Quote:

Mobileconnect wrote: could use a third core for chipset emulation too if he added that

That would be more than a 68k emulation.

But I like the idea of having a chipset emulation on a free CPU core, maybe someone can offload some GFX operations to a free core.

@cdimauro

Quote:

I doubt that the MOVBE instruction is used on (Win)UAE JIT, and here a good performance boost can come. Besides that, x86-64 has other advantages compared to AArch64: load-op, op-store, rep instructions, and especially large immediates support. So, the CISC way -> it's easier to mimick the 68k code execution, and it's also more efficient (less pipeline stalls due to depending, less instructions executed).

I already know about x86-64's fused memory + ALU operations advantage for 68K emulation, but my comment is about the PPC plan for AArch64-based Emu68.

I already have an AmigaOS 4.1 FE license.

_________________

forget about emu something
install linux and qemu on rpi