I'd like to add PowerPC 603/604 to the list of assemblers I'm working with and write a Higgs compiler backend for it (thus bringing my entire codebase to PPC ecosystem), given I already wrote one for RISC DSP/GPU before.
While I am not going to put my engine and game work to halt because of it, that'll naturally come to an end in about 4 months once my part-time job becomes full-time (for about 6 months) again around June.

And this project is something that's doable on that kind of random schedule (unlike game coding) during July-December, as separate language commands are easily doable within half day here and there, whenever I am back home from travelling.

But I need Dev environment first, to learn the PPC ASM (ideally an interactive one, showing all registers and allowing stepping through the code).

I don't want to just try setting up first thing I google, as I have zero exposure to PPC and would thus miss implications of such decision and as there's many people who have been in this space for decades, I figured I could just ask here and get the conversation going.

So, I need:
1. PPC 603 Assembler (command-line, Windows executable)
2. Virtual Machine with whichever OS is used there
3. Ideally, if possible, this would work within WinUAE which I use for testing

I tried asking this question on RISC-V subreddit, but it got flagged as off-topic there and deleted

Heimdall Quote:

So, I need: 1. PPC 603 Assembler (command-line, Windows executable)

You mentioned you were already using Frank Wille's VASM assembler which is a cross assembler that supports PPC. The VBCC cross compiler, and VASM the assembler for it, not only support PPC but multiple Amiga targets (PPC MorphOS, PPC AmigaOS 4, PPC WarpOS and PPC PowerUP).

http://sun.hasenbraten.de/vbcc/

I do not know about a PPC simulator but "The PowerPC Compiler Writer’s Guide" is good documentation for a compiler backend and instruction scheduler that covers early PPC CPUs like the PPC 603(e) and 604(e) including optimized PPC assembly code.

The PowerPC Compiler Writer’s Guide
https://cr.yp.to/2005-590/powerpc-cwg.pdf

Do not expect help with PPC assembly, optimizations and debugging from Amiga Neverland. PPC assembly experts do not exist here or in most places as PPC assembly is more dead in use than 68k assembly at this point. Reading the VBCC and VASM docs and then e-mailing Frank Wille with remaining questions is your best bet for Amiga related PPC questions. He can program PPC assembly and has written some PPC optimizations/inlines but no games unlike his many 68k Amiga games he enjoys writing, as I linked in another thread. A-EonKit sabotage of the 68k Amiga has failed to result in games written in PPC assembly, PPC software optimizations anywhere near the the scale of x86-64 software optimizations or even PPC SMP working as well as AROS x86-64 SMP after more than a decade. Maybe it is no worse than Jaguar hardware bugs and bottlenecks though.

Last edited by matthey on 10-Feb-2025 at 06:40 PM.
Last edited by matthey on 10-Feb-2025 at 06:37 PM.

Quote:

matthey wrote: You mentioned you were already using Frank Wille's VASM assembler which is a cross assembler that supports PPC. The VBCC cross compiler, and VASM the assembler for it, not only support PPC but multiple Amiga targets (PPC MorphOS, PPC AmigaOS 4, PPC WarpOS and PPC PowerUP). http://sun.hasenbraten.de/vbcc/

Oh, wow - I am truly utterly unobservant Been using vasm for over half a decade, yet didn't notice it supports PowerPC targets ! I just checked the vasm.pdf, and - yep - there it is !!!

This is actually super important, because I won't have to write different handler for a different assembler into my compiler, as vasm support is already there, hence it'll make the very first compilation much easier!

Quote:

matthey wrote: I do not know about a PPC simulator but "The PowerPC Compiler Writer’s Guide" is good documentation for a compiler backend and instruction scheduler that covers early PPC CPUs like the PPC 603(e) and 604(e) including optimized PPC assembly code. The PowerPC Compiler Writer’s Guide https://cr.yp.to/2005-590/powerpc-cwg.pdf

That is a vey good PDF, sir !
It contains examples of the basic code flow and the many ways how to translate it into PPC ops. I wish I had it for Jaguar, for sure !

On the other hand, my experience with the first RISC compiler (for Jaguar's DSP and GPU) is still beneficial, because I can now actually design the PPC Backend in a way that will take scheduling into account from the very start.

Meaning, I'll design it so that each instruction has an added information about all of its pipeline stages, This way, the compiler, at any point, will contain the exact replica of the HW's pipeline stages and will be able to [eventually] make intelligent decisions about the best instructions to use, at that particular point.

More importantly, I already have a Cycle-Count Option for the Block, which prints out during compilation, detailed info on all cycles consumed (if the specific CPU target has that feature implemented).
This will be very useful for benchmarking of inner loops, as I can easily extend this to contain additional info on pipeline.

Quote:

matthey wrote: Do not expect help with PPC assembly, optimizations and debugging from Amiga Neverland. PPC assembly experts do not exist here or in most places as PPC assembly is more dead in use than 68k assembly at this point. Reading the VBCC and VASM docs and then e-mailing Frank Wille with remaining questions is your best bet for Amiga related PPC questions. He can program PPC assembly and has written some PPC optimizations/inlines but no games unlike his many 68k Amiga games he enjoys writing, as I linked in another thread. A-EonKit sabotage of the 68k Amiga has failed to result in games written in PPC assembly, PPC software optimizations anywhere near the the scale of x86-64 software optimizations or even PPC SMP working as well as AROS x86-64 SMP after more than a decade. Maybe it is no worse than Jaguar hardware bugs and bottlenecks though.

Well, but there's gotta be at least a dozen active PPC coders, or not even that many anymore ? They must hang out somewhere.
Frank's busy with his compiler suite, wouldn't want to bother him with newbie questions...

Maybe they're on reddit/discord...

@matthey

Quote:

matthey wrote: You mentioned you were already using Frank Wille's VASM assembler which is a cross assembler that supports PPC. The VBCC cross compiler, and VASM the assembler for it, not only support PPC but multiple Amiga targets (PPC MorphOS, PPC AmigaOS 4, PPC WarpOS and PPC PowerUP). http://sun.hasenbraten.de/vbcc/

I didn't know about this, but Frank has been creating windows executables since 1.8j with each release. Which means I don't have to build vasmppc_std.exe for Windows myself!
It's right there at his site!

I found a HelloWorld ASM code for MorphOS on Aminet and managed to build it directly on Windows. Now just to run it, somehow, without the HW...


I thought I saw something about PPC in WInUAE, so I'll go take a closer look. It'd be super ideal if I could run the PPC executable straight from within WinUAE !

EDIT: Indeed, WinUAE supports PPC, so I just need to figure out how to configure it and then my Dev Environment will be ready.

Last edited by Heimdall on 11-Feb-2025 at 02:41 PM.

Heimdall Quote:

I didn't know about this, but Frank has been creating windows executables since 1.8j with each release. Which means I don't have to build vasmppc_std.exe for Windows myself! It's right there at his site!

Frank is awesome and VBCC/VASM supports all the Amiga division and flavors despite the problems it has caused. This comes from Frank who programmed his PhxAss assembler and many games in 68k assembly.

Heimdall Quote:

I found a HelloWorld ASM code for MorphOS on Aminet and managed to build it directly on Windows. Now just to run it, somehow, without the HW... I thought I saw something about PPC in WInUAE, so I'll go take a closer look. It'd be super ideal if I could run the PPC executable straight from within WinUAE ! EDIT: Indeed, WinUAE supports PPC, so I just need to figure out how to configure it and then my Dev Environment will be ready.

Right. WinUAE supports PPC but you need a PPC OS and kickstart/ROMs. The software needed is more expensive than RPi hardware and more difficult to obtain than 68k versions. PPC hardware is ridiculously expensive considering the lack of performance. The best value for PPC hardware is old PPC Mac hardware which MorphOS runs on and old PPC consoles which no AmigaOS runs on. There was a leaked AmigaOS 4 release for the PS3 but it was missing too many drivers and Sony dropped support for 3rd party OSs. The PPC Cell CPU was very difficult to program anyway although you seem to like the challenge of hardware purgatory. The PPC Nintendo consoles used PPC G3 CPU cores with customized and upgraded SIMD units that were much easier to program and more desktop like. They would make easier and more practical homebrew systems but I have not seen AmigaOS support for them yet.

@matthey

Quote:

Right. WinUAE supports PPC but you need a PPC OS and kickstart/ROMs. The software needed is more expensive than RPi hardware and more difficult to obtain than 68k versions.

Yeah, but for me, RPi HW is an unobtainium, given I would first need to shell out $2,000 + for A1200 NTSC system with all the cards.
I just checked MorphOs, and the license is 79 EUR, which is not horrible. And, allegedly, it should run for 30 minutes for FREE at full speed, which might just be enough to test the build.
No idea yet, if that'll run under WinUAE - but it's worth a shot - I can justify spending one afternoon to see if I can have a PPC environment under WinUAE!


Quote:

PPC hardware is ridiculously expensive considering the lack of performance. The best value for PPC hardware is old PPC Mac hardware which MorphOS runs on and old PPC consoles which no AmigaOS runs on. There was a leaked AmigaOS 4 release for the PS3 but it was missing too many drivers and Sony dropped support for 3rd party OSs. The PPC Cell CPU was very difficult to program anyway although you seem to like the challenge of hardware purgatory. The PPC Nintendo consoles used PPC G3 CPU cores with customized and upgraded SIMD units that were much easier to program and more desktop like. They would make easier and more practical homebrew systems but I have not seen AmigaOS support for them yet.

I'm not entirely sure what the advantage of having Mac HW would really be.
It would only give me benchmarks that are valid only for that particular McIntosh model, not the Amiga PPC CPU. Unless the Mac would have an actual 603e CPU, which is probably unreasonable these days and will cost in the 4-digit USD range...

Maybe I am missing something here ? Is there some other advantage of having the Mac HW (for testing) compared to the emulator ?

Heimdall Quote:

Yeah, but for me, RPi HW is an unobtainium, given I would first need to shell out $2,000 + for A1200 NTSC system with all the cards.

With Amiga 1200s including expansion that expensive, it is surprising someone does not create a more modern 68k Amiga SoC ASIC and produce new Amigas in retro themed cases for less than the originals cost.

Heimdall Quote:

I just checked MorphOs, and the license is 79 EUR, which is not horrible. And, allegedly, it should run for 30 minutes for FREE at full speed, which might just be enough to test the build. No idea yet, if that'll run under WinUAE - but it's worth a shot - I can justify spending one afternoon to see if I can have a PPC environment under WinUAE!

The 30 minute demo version of MorphOS should be fine for testing. I'm not so sure it would work in WinUAE though. AmigaOS 4.1 FE is not officially supported in WinUAE but it works and is cheaper than MorphOS at $29.49 USD.

https://www.hyperion-entertainment.com/index.php/where-to-buy/direct-downloads/174-amigaos-41-final-edition-for-classic Quote:

Note: Please note that emulations like WinUAE or FS-UAE are not officially supported platforms for AmigaOS 4.1 Final Edition for Classic.

I am not promoting AmigaOS 4 as I would rather boycott Hyperion and A-EonKit products but that is what is available. AmigaOS 4 is more AmigaOS like than MorphOS but both have their strengths in different areas.

Heimdall Quote:

I'm not entirely sure what the advantage of having Mac HW would really be. It would only give me benchmarks that are valid only for that particular McIntosh model, not the Amiga PPC CPU. Unless the Mac would have an actual 603e CPU, which is probably unreasonable these days and will cost in the 4-digit USD range... Maybe I am missing something here ? Is there some other advantage of having the Mac HW (for testing) compared to the emulator ?

I am not sure MorphOS supports all the way down to a PPC603e Mac but most of those are in the trash with G3/G4 Mac replacements being relatively cheap and much more usable. The PPC G3 is an upgraded PPC603e with a 2nd integer unit which makes instruction scheduling much easier and is likely the most popular PPC processor in use by Amiga like OSs. Many newer hardware PPC CPU cores also have a 2nd integer unit and require similar instruction scheduling. It may be worth considering it as a PPC target.

Emulation is only cycle exact for simple cores like the 68000 and without JIT. Early 68000 hardware sometimes used timing loops which was common on 68k Atari hardware but less common on the Amiga due to the more common use of display timing. Newer and more modern CPUs have varying clock speeds and instruction latencies where cycle exact was no longer important. Newer emulators also do not try to maintain CPU accurate timing but rather try to execute code as fast as possible which depends on the underlying hardware and is inconsistent from system to system. There may be cycle accurate simulators out there for some of the more modern CPU cores but they would be very slow. Mac hardware and FPGA hardware can provide more accurate CPU timing but there are CPU variations and it is best to avoid dependency on optional hardware features without checking for their existence.

Last edited by matthey on 27-Feb-2025 at 07:37 PM.

@Heimdall

Quote:

Yeah, but for me, RPi HW is an unobtainium, given I would first need to shell out $2,000 + for A1200 NTSC system with all the cards.

Perhaps not, there are some FPGA based solutions, MiniMig. FPGA arcade.
some of FPGA solutions support AGA, some only support OCS/ECS, there is also UnAmiga FPGA. Some of this FPGA cards, have a socket for 680x0 CPU, that’s how you can attach the raspberry,

(I’m have been considering it, but I really do not have the time, for all the boxes.)

Last edited by NutsAboutAmiga on 27-Feb-2025 at 07:46 PM.
Last edited by NutsAboutAmiga on 27-Feb-2025 at 07:44 PM.
Last edited by NutsAboutAmiga on 27-Feb-2025 at 07:43 PM.

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

NutsAboutAmiga Quote:

Perhaps not, there are some FPGA based solutions, MiniMig. FPGA arcade. some of FPGA solutions support AGA, some only support OCS/ECS, there is also UnAmiga FPGA. Some of this FPGA cards, have a socket for 680x0 CPU, that’s how you can attach the raspberry,

The ACSA is likely the best performance but the MiSTer has a similar sized if not larger FPGA and can likely support a 68040 level of performance but maybe with 68030 level features. While the CPU performance is limited, parallel chipset performance in FPGA can simulate powerful chipsets, one of which is the X68000 chipset which was higher end and more powerful than the Amiga chipset. The following video shows some flat shaded 3D on the unfinished x68000 core.

MiSTer FPGA Sharp X68000 Core Update! Revisiting the Core of this Japanese God Tier Gaming PC
https://youtu.be/ifwTwNDl-RA?t=355

The x68000 was much more expensive than the Amiga and had many arcade quality game ports. There were x68000 CPU upgrades up to and including the 68060 but I do not know if games work as well on and take as much advantage from CPU upgrades as the Amiga. Even the Amiga CD32 console has 68060 accelerators for it today and most games work on it although some need WHDLoad patching. The x68000 OS was not as advanced as the AmigaOS.

The FPGA Arcade had a 68060 add-on board but it required pre-order and is likely not available anymore. A real 68k CPU with FPGA chipset is a potent combination although the FPGA Arcade did not try to enhance the Amiga chipset like SAGA for the Vamp/AC. It did have RTG and improved audio from the ARM SoC which could be accessed by various cores like the Amiga core though.

@matthey

Quote:

With Amiga 1200s including expansion that expensive, it is surprising someone does not create a more modern 68k Amiga SoC ASIC and produce new Amigas in retro themed cases for less than the originals cost.

Last month, I was watching an auction ón eBay which ended at $1,700 for NTSC A1200, 128 MB RAM, TF1260 + 50 MHz LC060
Thus, with PiStorm (don't recall exact price from top of my head), it's going to be close to $2,000.
Actually more, because once I have A1200, I will want to test on 040, and 030, so I will need those cards and CPUs too.

One alternative is to quit the part-time job (which is financing my life right now) and become SW engineer again (for a bit), but that'll grind any retro coding to a halt, as I'll keep my soul getting crushed in a corporate environment, so I'd rather not do that.



Quote:

The 30 minute demo version of MorphOS should be fine for testing. I'm not so sure it would work in WinUAE though. AmigaOS 4.1 FE is not officially supported in WinUAE but it works and is cheaper than MorphOS at $29.49 USD.

Good catch, wasn't aware of that. Maybe that's the reason for using QEMU, instead. I'll try and see.

@matthey

Quote:

I am not sure MorphOS supports all the way down to a PPC603e Mac

Do you mean that MorphOS doesn't have actual binaries for 603e ?
I kinda assumed that all basic PPC CPUs used for Amiga would be supported, no ?



Quote:

but most of those are in the trash with G3/G4 Mac replacements being relatively cheap and much more usable. The PPC G3 is an upgraded PPC603e with a 2nd integer unit which makes instruction scheduling much easier and is likely the most popular PPC processor in use by Amiga like OSs. Many newer hardware PPC CPU cores also have a 2nd integer unit and require similar instruction scheduling. It may be worth considering it as a PPC target.

Right, I forgot about the bubbles. I won't really have any idea about the actual performance of my RISC code under emulation.

I guess I could at least design all the inner loops of the 3D engine (especially scanline traversal / fill which takes majority of frame time) with the full RISC pipeline.

Wait, I just realized something. I could automate this easily within my Higgs compiler. I'd flag some code block with some new command, say PipelineBegin/PipelineEnd and the compiler would print out detailed output with all pipeline/bubble stages, instruction by instruction. And after the block, it'd count all the bubbles and wasted cycles.

That's something that should take, maybe 1-2 days to implement within the compiler.

This way, I could simply keep refactoring the code, till the inner loop gets under some bubble threshold.

I am remembering now that that's something I wanted to do for my Atari Jaguar RISC GPU pipeline backend, some years ago, but because the pipeline was very simple, it wasn't worth the effort back then. Mostly, because I'd have to rewrite it from scratch.

But I will be writing this RISC backend classes from scratch for sure, so that I can account for the full architecture of the CPU. Each instruction will be derived from the base class and inheriting behavior from a subcategory of instructions (e.g. load/store/branch/math) to avoid duplication of the effort.

@NutsAboutAmiga

Quote:

Perhaps not, there are some FPGA based solutions, MiniMig. FPGA arcade. some of FPGA solutions support AGA, some only support OCS/ECS, there is also UnAmiga FPGA. Some of this FPGA cards, have a socket for 680x0 CPU, that’s how you can attach the raspberry,

Thanks, I think I saw in some other thread somebody mention MiniMig being able to attach the expansion card. I'll be watching this space. Never heard of UnAmiga, before.

Any chance for PPC 603e FPGA ?

@matthey

Quote:

The ACSA is likely the best performance but the MiSTer has a similar sized if not larger FPGA and can likely support a 68040 level of performance but maybe with 68030 level features. While the CPU performance is limited, parallel chipset performance in FPGA can simulate powerful chipsets, one of which is the X68000 chipset which was higher end and more powerful than the Amiga chipset. The following video shows some flat shaded 3D on the unfinished x68000 core. MiSTer FPGA Sharp X68000 Core Update! Revisiting the Core of this Japanese God Tier Gaming PC https://youtu.be/ifwTwNDl-RA?t=355

If anything, the Sharp x68000 new core could push me to spend time on 030 optimizations
But that's a rabbit hole for another year
Plenty other rabbit holes in Amiga Land (PPC, Warp, A600GS, C2P support, ...) in the meantime...
Quote:

The x68000 was much more expensive than the Amiga and had many arcade quality game ports. There were x68000 CPU upgrades up to and including the 68060 but I do not know if games work as well on and take as much advantage from CPU upgrades as the Amiga. Even the Amiga CD32 console has 68060 accelerators for it today and most games work on it although some need WHDLoad patching. The x68000 OS was not as advanced as the AmigaOS.

Not the 2D games, for sure. But any 3D game that was written as fully frame-rate independent, would automatically improve performance.

But, I know first-hand, how much work it is, to make the entire engine+game fully frame-rate independent (physics, movement, in-game events, etc.). So, I won't judge if some games took shortcuts during development...

Heimdall Quote:

Do you mean that MorphOS doesn't have actual binaries for 603e ? I kinda assumed that all basic PPC CPUs used for Amiga would be supported, no ?

All older PPC CPUs that follow the same ISA and ABI can be supported with the same Elf binaries. PPC was mostly standardized but some PPC CPUs missed instructions and other support in hardware. The FPU was standard until newer PPC embedded standards made it optional and the A-Eon A1222+ hardware used it with all the problems it caused. The standard SystemV ABI defines floating point arguments as being passed in FPU registers but what happens when there are no FPU registers? The A-Eon A1222+ mistake is for AmigaOS 4 and not supported by MorphOS. MorphOS PPC Elf binaries on a PPC603e Mac may start but there may be missing drivers. I looked up the list of MorphOS hardware and it looks like it only lists Mac G4 and G5 models.

https://www.morphos-team.net/hardware

The bPlan Pegasos I and II offered a PPC G3 CPU option and the bPlan Efika SoC used a PPC603e CPU.

https://www.bplan-gmbh.de/specifications.html Quote:

Freescale MPC5200B PowerPC SoC 400MHz 32 Bit PowerPC including FPU 603e Prozzesor core ( e300 ) Dhrystone 2.1, 760 MIPS

The Efika SoC PPC 603e (e300 core) has a claimed 1.9 DMIPS/MHz which was good for low end hardware at the time, especially compared to ARM offerings. The e300 core may have enhancements over the original PPC 603e. This was cheap and small hardware that was the closest to allowing a PPC AmigaOS to break into the embedded market as Hyperion planned but then Hyperion failed to support it with AmigaOS. It only had 128MiB of memory and PPC does not have nearly the footprint of 68k hardware so RPi like hardware would have to wait until ARM Thumb-2 and 256MiB. Too bad as a 68k Amiga with 128MiB is very comfortable.

Heimdall Quote:

Right, I forgot about the bubbles. I won't really have any idea about the actual performance of my RISC code under emulation.

The PPC603e limited OoO increases performance despite only having one of each execution unit (1xALU, 1xload/store, 1xbranch, 1xFPU) and having tiny OoO queues. The PPC Compiler Writer's Guide recommends instruction scheduling as if there was no OoO which likely improves performance but the OoO no doubt can fill some bubbles. The PPC603e is a very simple superscalar OoO CPU but is still difficult to predict exactly what happens every cycle in code. The more sequential in-order 68060 is easier to predict at the cycle level, more tolerant of instruction scheduling and allows a deeper pipeline for more performance with similar area used. Even the PPC603e is easier to program than some minimalist in-order RISC cores but once finding an easy to program CPU core design, it is difficult to go back.

Last edited by matthey on 28-Feb-2025 at 04:21 PM.

@matthey
Quote:

All older PPC CPUs that follow the same ISA and ABI can be supported with the same Elf binaries. PPC was mostly standardized but some PPC CPUs missed instructions and other support in hardware. The FPU was standard until newer PPC embedded standards made it optional and the A-Eon A1222+ hardware used it with all the problems it caused. The standard SystemV ABI defines floating point arguments as being passed in FPU registers but what happens when there are no FPU registers?

In that case, I am really glad I do not use FP
It is kinda funny, that even in the year of 2025, we still have to consider the absence of the FP unit (another prime example being LC060), but it is what it is.



Quote:

The more sequential in-order 68060 is easier to predict at the cycle level, more tolerant of instruction scheduling and allows a deeper pipeline for more performance with similar area used. Even the PPC603e is easier to program than some minimalist in-order RISC cores but once finding an easy to program CPU core design, it is difficult to go back.

Well, as discussed in different thread, It became apparent that sub-Vampire optimizations are not needed for me this year, as 060 is -basically- in the same performance bucket as 030 from the coding effort standpoint (needing C2P, LOD, art assets, etc.), as the MIPS difference between 030 vs 060 is -basically- irrelevant.



Quote:

The PPC603e limited OoO increases performance despite only having one of each execution unit (1xALU, 1xload/store, 1xbranch, 1xFPU) and having tiny OoO queues. The PPC Compiler Writer's Guide recommends instruction scheduling as if there was no OoO which likely improves performance but the OoO no doubt can fill some bubbles. The PPC603e is a very simple superscalar OoO CPU but is still difficult to predict exactly what happens every cycle in code.

Estimating the pipeline manually - for sure! But this is why implementing PPC603e pipeline into my Higgs compiler is a no-brainer. I need to spend only about a week designing the following components within the CPU Pipeline Class:
- BPU, SRU, FPU1-3, IU, LSU1-2
- Instruction Fetch
- Instruction Queue 1-2
- Instruction Decode/Dispatch/Execute/Complete/Retire

Each RISC instruction will be a class with its own behavioral DB (I already have that in Higgs anyway) and it'll update the Pipeline class (its stages, cycles, stalls, etc.)


Of course, without having actual HW to test it on, undoubtedly there will be differences between what I implement and the actual HW, simply due to my misunderstandings of the whole pipeline (and I will likely take some shortcuts as the goal here isn't to have a cycle-exact PPC emulator, but rather a tool to assist with RISC optimizations).

But it'll certainly beat manually estimating inner loops each time I rearrange some instruction. I've done a lot of that on Jaguar's DSP/GPU. I had to benchmark it each and every time.

With Higgs, I can simply Wrap a performance-critical code block with a CPU_Pipeline Tag {} and upon compilation will get a benchmark summary of cycles and stalls.
Extremely worth a week of work, from my standpoint because instead of running benchmarks on a HW (that I don't even have ), I can do hundred optimizations in one day and see the difference within a second of making a change in the code.

Back then, I was wrong. I thought a week of work wouldn't be worth it for the Jaguar. I had no idea how much time was lost on constant benchmarking (which I can't even do here without the actual HW). I don't intend on repeating that mistake with PPC

Heimdall Quote:

In that case, I am really glad I do not use FP It is kinda funny, that even in the year of 2025, we still have to consider the absence of the FP unit (another prime example being LC060), but it is what it is.

Funny or sad that Amiga makes it possible to not have a standard FPU in 2025?

Heimdall Quote:

Well, as discussed in different thread, It became apparent that sub-Vampire optimizations are not needed for me this year, as 060 is -basically- in the same performance bucket as 030 from the coding effort standpoint (needing C2P, LOD, art assets, etc.), as the MIPS difference between 030 vs 060 is -basically- irrelevant.

Premature optimization is the root of all evil for programming. There is a high percentage of 68040+ RTG systems that support chunky modes and do not require C2P.

Heimdall Quote:

Estimating the pipeline manually - for sure! But this is why implementing PPC603e pipeline into my Higgs compiler is a no-brainer. I need to spend only about a week designing the following components within the CPU Pipeline Class: - BPU, SRU, FPU1-3, IU, LSU1-2 - Instruction Fetch - Instruction Queue 1-2 - Instruction Decode/Dispatch/Execute/Complete/Retire Each RISC instruction will be a class with its own behavioral DB (I already have that in Higgs anyway) and it'll update the Pipeline class (its stages, cycles, stalls, etc.) Of course, without having actual HW to test it on, undoubtedly there will be differences between what I implement and the actual HW, simply due to my misunderstandings of the whole pipeline (and I will likely take some shortcuts as the goal here isn't to have a cycle-exact PPC emulator, but rather a tool to assist with RISC optimizations). But it'll certainly beat manually estimating inner loops each time I rearrange some instruction. I've done a lot of that on Jaguar's DSP/GPU. I had to benchmark it each and every time. With Higgs, I can simply Wrap a performance-critical code block with a CPU_Pipeline Tag {} and upon compilation will get a benchmark summary of cycles and stalls. Extremely worth a week of work, from my standpoint because instead of running benchmarks on a HW (that I don't even have ), I can do hundred optimizations in one day and see the difference within a second of making a change in the code. Back then, I was wrong. I thought a week of work wouldn't be worth it for the Jaguar. I had no idea how much time was lost on constant benchmarking (which I can't even do here without the actual HW). I don't intend on repeating that mistake with PPC

PPC OoO CPU cores are not rocket science so maybe you can get close at simulating them. Units, instruction fetch, decoding, instruction dispatch/issue, pipelines, unit instruction buffers (reservation stations), reorder buffers, instruction windows, completion buffers, load buffers, store buffers etc. are mostly understandable but there are often internal details that are not described well like stalls, data prefetching, instruction reordering, memory alignment handling, memory access reordering, etc. Nothing like modern very high performance microop OoO cores though.

The case can be made for relatively simple in-order cores with less speculation and reduced likely hood of side channel attacks, more sequential easier to understand operation and memory access and less breaking down of instructions only to put them back together wasting power. The 68060 has good performance with more performance potential, is very easy to program and understand and is more serial in operation including for memory accesses.

https://www.nxp.com/docs/en/data-sheet/MC68060UM.pdf Quote:

The MC68060 integer unit generates access requests to the instruction and data memory units to support integer and floating-point operations. Both the fetch and write-back stages of the integer unit pipeline perform accesses to the data memory unit. All read and write accesses are performed in strict program order. Compared with the MC68040, the MC68060 is always “serialized’. This feature makes it possible for automatic bus synchronization without requiring NOPs between instructions to guarantee serialization of reads and writes to I/O devices.

RISC propagandists who have criticized CISC complexity only to support micro-oped OoO CPU cores that break down instructions into simple "microops" only to use vast complexity to put everything back together again with weak memory consistency models that reorder memory accesses are hypocrites. Following the RISC philosophy would give instructions that are as simple as microops already but that was not competitive. Cesare Di Mauro, who is a user on this forum, made a strong case for simpler in-order CISC CPU cores in the following article.

https://www.appuntidigitali.it/21790/nex64t-9-conclusions/

He is a fan of the 68k and his NEx64T ISA is a reencoding of the x86-64 8-bit variable length encoding into a more efficient 16-bit variable length encoding like the 68k with the downside that he has to maintain compatibility with all the x86(-64) baggage. The 68k baggage is minor in comparison as it started with a 32-bit ISA even for the 16-bit 68000 allowing for a large flat address space from inception.

Last edited by matthey on 03-Mar-2025 at 08:20 PM.
Last edited by matthey on 03-Mar-2025 at 08:18 PM.
Last edited by matthey on 03-Mar-2025 at 08:16 PM.
Last edited by matthey on 03-Mar-2025 at 07:47 PM.
Last edited by matthey on 03-Mar-2025 at 07:45 PM.