I love to see this kind of report with technical details. And I am also really impressed by the work done! This is a real performance. Congratulations to the author!

That said, the board is cheap but ... I didn't find it anywhere. And even if it was available, there are numerous steps and hacks that make it too difficult to do for anyone.

So, this is an incredible proof of concept but not really a cheap DYI motherboard.

@Hans

Quote:

Hans wrote: @OneTimer1 That's pretty cool. I personally couldn't be bothered to try such a thing, but enjoy watching people push older tech. far beyond what it was designed for. One thing I picked out of the article, is that CLang/LLVM still has SPE support. Good news for the A1222. I've been using an older version of GCC for compiling SPE code. Hans

Well, compiling LLVM isn't that easy, eh!

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @pavlor It requires quite beefy PC to emulate PowerPC, because of endianness, A good PC’s do compensate for endianness issue by having faster memory controllers.

PCs already have the MOVBE instructions since several years, which make the endian conversion much faster (compared to the only BSWAP instruction).

Of course, it should be... used by the JIT compilers.

@NutsAboutAmiga

Quote:

i love it, can be perfect for AmigaOS4.x, just put it in a different box.

It only has 128Mb so it would be pretty limited.

@NutsAboutAmiga

Quote:

It requires quite beefy PC to emulate PowerPC, because of endianness, A good PC’s do compensate for endianness issue by having faster memory controllers.

Shouldn't be an issue. 20 years ago Amithlon dealt with this. Using bswap before and after memory access.

Now days x86/64 has had specific big endian supports for decades. If there is still any issue then it's the coders or compilers that need to be brought up to date. x86 has better reverse storage instructions than PPC, it can reverse both in register and at memory. PPC can only do it at memory, where it's relevant, but compiler built ins (GCC) make a wreckage on PPC because they are designed to swap variables.

It's a bit lame for people online to say network structures should be changed to little endian because their x86 is. Who cares? Mixed endian in data are fact of life. Its not just the most popular endian that matters. x86 had had the best compilers for any CPU I'm aware of. So if x86, which has better big endian support than your granny, still has trouble with big endian datatypes there is something wrong with the coding world!

@Rob

Quote:

Rob wrote: @NutsAboutAmiga Quote: i love it, can be perfect for AmigaOS4.x, just put it in a different box. It only has 128Mb so it would be pretty limited.

My WinUAE's CyberStorm PPC/AmigaOS 4.1 FE has more than 1 GB RAM i.e.

Avail
Installed: 1,208,991,712
Free: 1,125,761,568

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

How is the emulated PPC's floating point performance on this configuration?

_________________
Doing stupid things for fun...

@Hypex

Just to be clear I don't have a cyclopedic knowledge, I don't code professionally, I only write assembler when I feel a need to optimize something I can’t find on other options for, and I mostly been coding in 68000 assembly and PowerPC assembly

Emulation used to be slow, and that was the case, for many years. there probably a lot that has changed beside faster RAM. And smarter cache handling.

I did not bring up network packages, so why that came into the conversation, I wonder did you use ChatGPT? It adds a bunch of nonsense. It seems to lack the ability iterate on the information it finds, to determine its relevance.

You might be right that it has been in there for decades, But it takes time for code bases to catch up to the instruction set, the jit compilers the C compilers will use old ways of doing things unless they are changed to support the new instructions, An a general methods are used for and you're not even though there are better ways to implement. For example, the old C macros for endianness swapping.

On list of worst to best I state that C macros are worst.

Then SWAP instruction, as you need two instructions load + swap, swap + store.

then comes the MOVBE (x86), or reverse load / store instructions (PowerPC.)

Swap instruction is relevant, because it can replace horrible C macros, it’s a short way to success, and you might say PowerPC does not have it, well for 16bit it actually has, using the shift instructions.

Last edited by NutsAboutAmiga on 17-Mar-2024 at 11:31 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Hypex

Amithlon speed came a lot from removing chipset emulation, doing less useless stuff. And providing direct access to hardware, so that programs did not write to frame buffers, but instead access graphic cards directly. The UAE implementation will actually add up number of cycles it uses per instruction, to be used in the emulation of sound and other places, there lots of counters, are being maintained. While AGA screen is not being displayed the Copper can actually used for other things like audio, as it has direct access to the chipset. The copper provided exact timing at low cost.

As people have noticed on X5000 in particular messing around with GFX in EUAE has resulted in speed up does to reduce amount data being send to the graphic card, emulation is memory bound, its CPU bound, and depends on your hardware.

Amithlon is not a good example of maintain backwards compatibility, and if are looking for something like that perhaps QEMU running AmigaOS4.1 is better idea. More programs wherever written for AmigaOS4.1 then it was ever written for Amithlon.

2en bottleneck after endianness is emulating the MMU, but that’s the case for any CPU that require emulation of soft MMU.

Last edited by NutsAboutAmiga on 17-Mar-2024 at 11:30 AM.
Last edited by NutsAboutAmiga on 17-Mar-2024 at 11:26 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Hypex Just to be clear I don't have a cyclopedic knowledge, I don't code professionally, I only write assembler when I feel a need to optimize something I can’t find on other options for, and I mostly been coding in 68000 assembly and PowerPC assembly Emulation used to be slow, and that was the case, for many years. there probably a lot that has changed beside faster RAM. And smarter cache handling.

It used to be slow because they were first implementations.

Things evolved, processors added new features, and I can assure you that it's definitely possible to have much better emulators nowadays compared to the past. Especially if you have some original ideas that could be applied (also, in general, to virtual machines like the ones used in Java, Python, etc.).

Besides that, usually emulation is slow because you emulate an entire system (e.g.: hardware included) which doesn't allow to fully exploit the achievable performances.
Projects like Emu68 show at which level you can arrive when you do NOT have to (fully) emulate the hardware. This is the way to go for OS-friendly applications.
Quote:

You might be right that it has been in there for decades, But it takes time for code bases to catch up to the instruction set, the jit compilers the C compilers will use old ways of doing things unless they are changed to support the new instructions,

The problem here is that for old/retro platforms you often are stuck using old compilers that cannot optimize the code in better ways (with some exception: some old 68k compilers generate better code than modern ones).
Quote:

An a general methods are used for and you're not even though there are better ways to implement. For example, the old C macros for endianness swapping. On list of worst to best I state that C macros are worst. Then SWAP instruction, as you need two instructions load + swap, swap + store. then comes the MOVBE (x86), or reverse load / store instructions (PowerPC.) Swap instruction is relevant, because it can replace horrible C macros, it’s a short way to success, and you might say PowerPC does not have it, well for 16bit it actually has, using the shift instructions.

In those case you should NOT directly use any instruction for a specific processor, because the compiler should be able to catch those code patterns and automatically generate the proper instruction(s) for a specific processor.
@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Hypex Amithlon speed came a lot from removing chipset emulation, doing less useless stuff.

Exactly. That's how it should go for OS-friendly applications, in order to get the best performance.
Quote:

And providing direct access to hardware, so that programs did not write to frame buffers, but instead access graphic cards directly.

Not relevant anymore, with the powerful hardware which we can use since several years. There's little gain of following Amithlon approach with a lot of effort (maintaining this infrastructure).
Quote:

The UAE implementation will actually add up number of cycles it uses per instruction, to be used in the emulation of sound and other places, there lots of counters, are being maintained.

That's why UAE is NOT the way to go.

Albeit many things could be perfectly emulated by using an hardware thread which can run completely in parallel with the main thread which is executing the 68k (or any other non-host processor) code.
Quote:

While AGA screen is not being displayed the Copper can actually used for other things like audio, as it has direct access to the chipset. The copper provided exact timing at low cost.

That's what I've done on my games (USA Racing, specifically): I've used the Copper for playing the music (in my special format: it took half the space of a regular .MOD and it's much faster to decode / executed) and sfx.

All in all, it took around one raster line for it: a negligible cost.
Quote:

As people have noticed on X5000 in particular messing around with GFX in EUAE has resulted in speed up does to reduce amount data being send to the graphic card, emulation is memory bound, its CPU bound, and depends on your hardware.

Maybe because that isn't offloaded to another core / hardware thread, like it's happening in WinUAE.
Quote:

Amithlon is not a good example of maintain backwards compatibility,

Why? You don't need full hardware compatibility, unless you need to play games or some special application.
Quote:

and if are looking for something like that perhaps QEMU running AmigaOS4.1 is better idea. More programs wherever written for AmigaOS4.1 then it was ever written for Amithlon.

QEMU is slow...
Quote:

2en bottleneck after endianness is emulating the MMU, but that’s the case for any CPU that require emulation of soft MMU.

There can tricks for it to speed the emulation.

@cdimauro

Quote:

in those case you should NOT directly use any instruction for a specific processor, because the compiler should be able to catch those code patterns and automatically generate the proper instruction(s) for a specific processor.

beside the late addition __builtin_bswap32(), __builtin_bswap16(), there really is no support for in-language syntax in the C++ / C language.

I guess idea suggest by C++ developers was everything can be classes. That way you have your setters and getters do the swapping. That of course dumps all the work on the developers, and result is probably going to be suboptimal. So, there is not a Int64le or Int64be type in the language itself, int64 is just a native format of the CPU.

Technical some CPU’s don’t have native format anymore, like Power CPU can run LE or BE versions of Linux, so up to the compiler what it produces.

Last edited by NutsAboutAmiga on 17-Mar-2024 at 02:23 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro Quote: in those case you should NOT directly use any instruction for a specific processor, because the compiler should be able to catch those code patterns and automatically generate the proper instruction(s) for a specific processor. beside the late addition __builtin_bswap32(), __builtin_bswap16(), there really is no support for in-language syntax in the C++ / C language. I guess idea suggest by C++ developers was everything can be classes. That way you have your setters and getters do the swapping. That of course dumps all the work on the developers, and result is probably going to be suboptimal. So, there is not a Int64le or Int64be type in the language itself, int64 is just a native format of the CPU. Technical some CPU’s don’t have native format anymore, like Power CPU can run LE or BE versions of Linux, so up to the compiler what it produces.

You haven't got me. I was referring to a complete different thing. Here you can find more clarifications with real-world examples using modern compilers to detect some code patterns and emitting proper instructions:

https://stackoverflow.com/questions/36497605/how-to-make-gcc-generate-bswap-instruction-for-big-endian-store-without-builtins

As you can see, you do NOT need use architectural/compiler specific builtins to have the compiler generating the expected instructions: you write the code in a certain way (mimicking what a BE conversion is doing) and the compiler will recognize it and generate the instruction (BSWAP for old architectures. MOVBE for newer architectures; which for Intel means starting from Haswell, which is anyway quite old).

Of course, if you're writing a JIT compiler all of this doesn't make sense at all, because you need to manually generate binaries on the fly for the proper architecture.

@cdimauro

MOVBE existed back in 2015 but it seems people were compiling with -mno-movbe, perhaps It was not widely available.

2018 MOVBE was introduced for coding patterns as you talked about.

https://stackoverflow.com/questions/36497605/how-to-make-gcc-generate-bswap-instruction-for-big-endian-store-without-builtins

MOVBE was introduced as late at 2019 in Dot.net JIT compiler.

https://github.com/dotnet/runtime/issues/953

So MOVBE became a popular only 5 to 6 years ago, before then there was not huge support for it.

MOVBE is x64 instruction not a x68 instruction.

Last edited by NutsAboutAmiga on 18-Mar-2024 at 04:24 PM.
Last edited by NutsAboutAmiga on 18-Mar-2024 at 04:22 PM.
Last edited by NutsAboutAmiga on 18-Mar-2024 at 04:22 PM.
Last edited by NutsAboutAmiga on 18-Mar-2024 at 04:21 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro MOVBE existed back in 2015 but it seems people were compiling with -mno-movbe, perhaps It was not widely available. 2018 MOVBE was introduced for coding patterns as you talked about. https://stackoverflow.com/questions/36497605/how-to-make-gcc-generate-bswap-instruction-for-big-endian-store-without-builtins MOVBE was introduced as late at 2019 in Dot.net JIT compiler. https://github.com/dotnet/runtime/issues/953 So MOVBE became a popular only 5 to 6 years ago, before then there was not huge support for it.

Which can give an idea why emulation can improve a lot by finally start using it on JIT compilers.
Quote:

MOVBE is x64 instruction not a x68 instruction.

It's a x86 and x64 instruction: it can run both in 32 or 64 bit mode.

Or where you referring to 68k with x68? In this case, yes: the instruction is missing from the ISA.

@Karlos

Quote:

Karlos wrote: @Hammer How is the emulated PPC's floating point performance on this configuration?

Are you asking for a Quake PPC benchmark? What's the fastest Quake PPC port?

Perhaps, nBench? http://amigadev.free.fr/powerpc/nbench.html

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 797.57 : 20.45 : 6.72
STRING SORT : 33.432 : 14.94 : 2.31
BITFIELD : 5.0672e+08 : 86.92 : 18.16
FP EMULATION : 99.225 : 47.61 : 10.99
FOURIER : 2340.2 : 2.66 : 1.49
ASSIGNMENT : 23.453 : 89.24 : 23.15
IDEA : 4600.5 : 70.36 : 20.89
HUFFMAN : 1856 : 51.47 : 16.44
NEURAL NET : 2.7211 : 4.37 : 1.84
LU DECOMPOSITION : 91.89 : 4.76 : 3.44
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 45.579
FLOATING-POINT INDEX: 3.812
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU :
L2 Cache :
OS : uname: Unknown command
C compiler : gcc version 4.0.2 (AmigaOS build 20051012)
libc :
MEMORY INDEX : 9.905
INTEGER INDEX : 12.617
FLOATING-POINT INDEX: 2.114
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.


----
PS: AmigaOS 4.1 FE's screensaver was active after HUFFMAN.


https://youtu.be/4IpYDj6qnWc
Wipeout 2097 on AmigaOS 4.1 FE, emulated PowerPC 604e/GREX PCI/Voodoo 3, WinUAE 5 with Ryzen 5 7600X.

Last edited by Hammer on 19-Mar-2024 at 06:57 AM.
Last edited by Hammer on 19-Mar-2024 at 06:42 AM.
Last edited by Hammer on 19-Mar-2024 at 06:40 AM.
Last edited by Hammer on 19-Mar-2024 at 05:59 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@cdimauro

Quote:

Projects like Emu68 show at which level you can arrive when you do NOT have to (fully) emulate the hardware. This is the way to go for OS-friendly applications.

PiStorm-Emu68 has turtle options for improved WHDLoad game compatibility and it's pretty good on A500's PiStorm-RPi3A-Emu68 combo.

I'm using the latest CaffeineOS's R272x's Emu68 update.

A hybrid solution such as an emulated CPU and real hardware platform is good for some low-end/low-cost ARM Cortex 53-class CPUs.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

Not asking for a quake test, I just want a reasonable estimate of MFLOPS that can be tested against a real CSPPC. My experience of UAE for PPC emulation is that the floating point performance is much lower than actual silicon. Or at least, lower than my actual silicon. However, that's tested on older x64 hardware and UAE itself may have improved since. The issue seemed to be related to software based FPU emulation in the QEMU library.

_________________
Doing stupid things for fun...