@kolla

From our website:


The Apollo Project mission statement:

Provide Amiga users with products that will upgrade all classic Amiga computer models to the best performance possible and provide them the Amiga features that Commodore always planned to give Amiga including 3D acceleration.
Revive the Amiga platform using the most advanced and higher performance CPU model 68080 of the excellent and programmer friendly 68K family.
Preserve and push the classic Amiga platform forward using technical expertise, modern tools, and a clear roadmap. This long term plan will take years and is focused on results.
Give classic Amiga users reasonably priced choice. Empower users with the opportunity to upgrade classic systems with the rich feature of the Super-AGA Amiga chipset included in V4 accelerators.

Gunnar Quote:

The goal of the Apollo Project always was and is to revive Amiga and to make 68K Asics as some point. We have a long roadmap that are following for this. The polishing and verification of the chipset and CPU in the FPGA as an important part of this roadmap.

When will the AC68080 be verified and ASIC ready and what percentage is it ready now? What changes to the pipeline, caches, etc. are planned for an ASIC? What chip process and max clock frequency are targeted? What is the cost of making an ASIC using this process? How close financially is the ASIC goal? Are there any business partners involved? What markets are targeted? Are there plans to add floating point support to the SIMD unit? Will the SoC fully support USB? What are the plans for the integrated 3D GPU? Does the GPU have unified shader support for more modern 3D software?

Gunnar Quote:

Matthey to make this very clear: you know absolutely nothing about how to make a CPU, or chipset or an Asic.

Gunnar is the absolute expert at everything and everyone else knows absolutely nothing. Who created the N68050? Who created SAGA?

Gunnar Quote:

Your contribution in the Apollo Team was in a nutshell - just talking bullshit. Your arguing about topics of which you lacked know-how got on the nerves of everyone.

Gunnar = Apollo Team

Cult followers don't make their own decisions as they are brain washed into performing for their leader. I have mentioned my contributions and team involvement many times which have not been denied by anyone. I warned Gunnar about many things but a god can't be warned by a mere mortal. A god can only be worshiped by loyal followers.

Gunnar Quote:

And when it came clear that you even faked a statistic to back-up one of your opinions - all of the team unanimously voted you to go.

I don't fake statistics. What "statistic" did I supposedly fake and where? What fake "statistic" was so bad that it was necessary for Gunnar to lie to followers so they would attack me with his lies? Would the original Apollo Team have unanimously voted me to go or just the loyal cult replacements that were lied to?

When it comes to statistics, Gunnar was the one more likely to fudge them to benefit him. I warned about DMIPS optimizations that were not allowed by the compiler. I showed statistics from multiple papers that indicated it was practically not worthwhile to add more than 16 GP registers for CISC and warned that non-orthogonal banked registers would be difficult to support by compilers while Gunnar did not reveal where he was getting his statistics. More recently, Gunnar added back ColdFire instructions that I had pushed for limiting access to banked registers with no complaints that I could find. My ColdFire instruction estimates for code savings in the 68k ISA by finding instructions that could be optimized in disassembled code using ADis Stats, which I modified for the Apollo project, was very conservative even though I thought it was a good upgrade. What percentage code density increase did Gunnar get when he finally decided to adopt the ColdFire instructions after changing the ISA?

Quote:

matthey wrote: When I was pushing for an ASIC as part of the AC team, he acted like it was not financially feasible even as I was working on solutions.

Maybe he was right.

---

I don't think it would make sense to put an existing FPGA design into an ASIC, you must invest into some redesigns before and I believe Gunnar knows more about it, than most of us.

Instead of buying a 'New Amiga' the people go for the accelerator cards. I wouldn't be surprised if the mass of customers invest into a PiStorm instead of an V4SL, that's nothing you can base an investment on.

@kolla

Quote:

kolla wrote: If the goal always was to revive Amiga, then how come it took so many years for the word “Amiga� to even appear on apollo-core.com?

Don't play dump, this name costs money, if not Gunnar would sell the V4SL as Amiga 5000.

And after I have seen the success of "The A500" I would suggest selling the Vampire4SL in a beige case as "The A5000"

@matthey

Quote:

When it comes to statistics, Gunnar was the one more likely to fudge them to benefit him. I warned about DMIPS optimizations that were not allowed by the compiler. I showed statistics from multiple papers that indicated it was practically not worthwhile to add more than 16 GP registers for CISC and warned that non-orthogonal banked registers would be difficult to support by compilers while Gunnar did not reveal where he was getting his statistics.

The main reason for X86's quick GPR and FPR transfers is to maximize register storage on the CPU.

On x86, you can spill integer registers to XMM registers instead of RAM.

The programmer effectively gets 32 registers on x86-64 shared between integer and FP, but fewer programs use FP. A certain 3D game exploits this i.e. Doom 3 reveals PowerPC's design flaw.

X86-64v4 already has 32 YMM (AVX-512) registers.

--------------
Developing another "Cyrix 6x86" style DMIPS focus for 68K wasn't useful for 3D games of Quake variety.

On the Amiga, the high compute needs are usually on the FPU side e.g. Lightwave.

For example, Z3660's 68K emulation on ARM Cortex A9 @ 766 Mhz (2.5 IPC) has good SysSpeed MIPS performance with mediocre FPU performance. Quake performance in Cyrix 6x86 PR166(133 Mhz)'s 21 fps level which is below Pentium 90's 24 fps.

Register renaming is an indication that a larger register set is desirable.

Last edited by Hammer on 28-May-2024 at 03:39 AM.
Last edited by Hammer on 28-May-2024 at 02:21 AM.
Last edited by Hammer on 27-May-2024 at 03:40 AM.

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

@vox

Quote:

vox wrote: @pixie Its hard to guess but I assume cheap and fast ARM CPUs cost less then larger FPGAs and FPGA development. Thus PiStorm approach is effective and cheaper in essence, using PiS as base. As race for fastest Amiga in practice, Pi is great there, abeit using advanced emulation. However, best prospect of 080 development is possibility of FPGA to ASIC, one that currently Apollo Team fails to realise and shows less and less interest in. In theory, 1Ghz 080 could beat advanced emulation and enable sensible coding again (optimized one) while emulation is kind of limited approach of accelerating emulated, thus no real way forward. While I havent tested it, development of basic 3D core and hopefully Warp3D / OpenGL drivers for it is nice. It has everything AAA Amiga would be except mainboard execution and thus feels less like a real Amiga in hardware, but shows its good sides in software that can use it. Sadly, number of software that recognoises 080, is optimised for it is so small its rejected as separate Aminet category for time being. What will be in future, we ll see. Real Amiga for me would be All in One Natami like board with 800Mhz plus 080 and SAGA done in real chips and with connectors now provided as expansion as standard. Until then FPGA V4 and V2 systems seems like road to it, but not fully it,

WinUAE and Emu68 could be modified to support 68080's instruction set extensions, fulfilling the "second source".

The host CPUs for either WinUAE or Emu68 have wider vector extensions.

The pro-RISC-V argument can be used against the 68080's solo source.

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

@matthey


I find strange how much you talk about the Apollo project -
while at the same time you have so little experience in it.

The APOLLO project to revive Amiga in an ongoing project which we work on since much over 10 years.

I recall your whole participated to our project is "chatting" in our dev-IRC channel for a few weeks.
We generally appreciate brainstorming about 68K instruction set and sharing ideas is always welcome.
Brainstorming with 68K instruction ideas is fine also with just ideas being them good or bad.

I recall that you argued about register design - a chip design topic were you had no technical understanding off. Your insisting on clueless advice was not appreciated by any of the team.


If you want to talk to us about 68K instruction set ideas this is fine you can do this as any other user can.
But maybe it would make a lot sense for you to get a little experience and understanding of the CPU first?

I think you never coded the 68080 CPU, did you?
You did not participated in any of its developments nor in testing of it.
So I fear right now you not understand much of it.

And you never used AMMX, did you?
You never used any of the Super-AGA hardware features, like improved Copper, improved Blitter, like enhanced Sprites, or like Maggie 3D unit, or any other new features like Chunky Dual Playfield or the enhanced Audio channels.

I think before you can talk any of the topics it would make sense for you to understand a little bit of them.
Don't you agree?

cheers

@matthey

Quote:

Who created the N68050? Who created SAGA?

Not sure why you ask this.


But if you want to know this as basis for talking about SAGA or CPU I can tell you this.

SAGA
-DMA channels : Gunnar
-EnhancedCopper : Gunnar
-64bit Blitter : Gunnar
-3D Maggie Unit : Gunnar
-Enhanced Sprites: Gunnar
-Planes /EHB / HAM : Gunnar
-Chunky modes : Gunnar
-Dual playfield Chunky : Gunnar
-Picture in Picture : Gunnar
-16 Channel Audio : Arne and Gunnar
-Yamaha Chip sound : Gunnar
-FM Timers : Gunnar
-ATARI ST GFX modes : Gunnar
-SAGA Register logic : Gunnar
-USB controller : Chris and Gunnar
-Networkchip : Chris
-HDMI encoding : Chris, Claude and Gunnar

Apollo 68050/68080 CPU
-Instructions prefetch/ branch prediction : Gunnar
-Icache : Gunnar
-Instruction Decoders : Gunnar
-Super Scalar matchers / Instruction Fusing and Bonding : Gunnar
-Ea units : Gunnar
-Dcache : Gunnar
-Hazard unit : Gunnar
-Forwarding units : Gunnar
-Integer ALUs : Gunnar and Jens
-FPU : Chris and Gunnar
-AMMX Unit : Gunnar
-Store unit : Gunnar
-Chip/Bus/ Zorro : Chris and Gunnar
-Memory Controller : Chris and Gunnar

Above you see roughly what logic areas were written be whom.
It goes without saying that to develop a new chip a lot more is needed than writing the chip logic.

Most important are writing testcases and software using them
and here the whole Apollo Team with many member did participate
and without their feedback, their testing, their good ideas - the project could never have been done.

So let me say a very big
Thank you to the Apollo-Team for helping to revive Amiga.

OneTimer1 Quote:

Maybe he was right. --- I don't think it would make sense to put an existing FPGA design into an ASIC, you must invest into some redesigns before and I believe Gunnar knows more about it, than most of us.

I think I would assess financial resources and consider business opportunities rather than ignore them, especially with an eventual ASIC goal anyway.

OneTimer1 Quote:

Instead of buying a 'New Amiga' the people go for the accelerator cards. I wouldn't be surprised if the mass of customers invest into a PiStorm instead of an V4SL, that's nothing you can base an investment on.

An ASIC 68k SoC could be used in Amiga accelerators and could provide expansion similar to what the ARM SoCs of Amiga accelerators are providing today. The major difference is much better 68k performance without emulation. An ASIC 68k SoC would not be pin compatible with a 68040/68060 chip that some people would want but the value would be better.

Hammer Quote:

The main reason for X86's quick GPR and FPR transfers is to maximize register storage on the CPU. On x86, you can spill integer registers to XMM registers instead of to RAM.

The x86 ISA has 7 GP integer registers and zero GP FPU registers which reduces performance, even for a CISC ISA although the handicap was not enough to keep x86 from becoming one of the most powerful desktop ISAs. The 68k ISA has 16 GP integer registers and 8 GP FPU registers. The 68k FPU also allows integer register to FPU register transfers, FPU register to integer register transfers and direct use of integer registers by the FPU for most FPU instructions.

Hammer Quote:

The programmer effectively gets 32 registers on x86-64 shared between integer and FP, but fewer programs use FP. A certain 3D game exploits this i.e. Quake 3 which reveals PowerPC's design flaw. X86-64v4 already has 32 YMM (AVX-512) registers.

The x86-64 ISA has 16 GP integer registers which is the same as the 68k now. Code density was lost by adding them which also reduces performance and is the reason some programs still have better performance with smaller x86 code.

x86-64 AVX-512 uses 32x512b SIMD unit registers which can perform 16x32b floating point or integer SIMD operations per instruction while AMMX can perform 2x32b integer only SIMD operations per instruction.

Hammer Quote:

Developing another "Cyrix 6x86" style DMIPS focus for 68K wasn't useful for 3D games of Quake variety. On the Amiga, the high compute needs are usually on the FPU side e.g. Lightwave. For example, Z3660's 68K emulation on ARM Cortex A9 @ 766 Mhz (2.5 IPC) has good SysSpeed MIPS performance with mediocre FPU performance. Quake performance in Cyrix 6x86 PR166(133 Mhz)'s 21 fps level which is below Pentium 90's 24 fps.

It makes sense to prioritize CPU integer over FPU performance as it is used more and thus more important. Modern silicon allows both but FPU performance is still not a priority for many embedded systems.

Hammer Quote:

Register renaming is an indication that a larger register set is desirable.

More registers allows to avoid the same data dependencies as register renaming but requires more careful instruction scheduling. Register renaming improves the performance of existing code while adding registers does not. Register renaming for in-order CPUs is not required but they are more of a pleasure to program and higher performance. The 68060 and Cyrix 6x86 chose to use integer register renaming where the P5 Pentium did not. Register renaming is also very valuable for maximizing FPU performance but has a higher cost due to wider registers.

Gunnar Quote:

I find strange how much you talk about the Apollo project - while at the same time you have so little experience in it.

I have more experience with the cult of the Vampire than I want to.

Gunnar Quote:

The APOLLO project to revive Amiga in an ongoing project which we work on since much over 10 years. I recall your whole participated to our project is "chatting" in our dev-IRC channel for a few weeks. We generally appreciate brainstorming about 68K instruction set and sharing ideas is always welcome. Brainstorming with 68K instruction ideas is fine also with just ideas being them good or bad.

Gunnar likely invited me and others to the Apollo Team based on Natami forum "chatting". The original Apollo Team chatted via e-mails and then primarily on the Apollo core forum before evidence of our existence was wiped away. We were around for many months not weeks and the dev IRC came at the end of our era.

Gunnar Quote:

I recall that you argued about register design - a chip design topic were you had no technical understanding off. Your insisting on clueless advice was not appreciated by any of the team.

I recall Gunnar asking developers on the Natami forum about adding more GP integer registers and being incensed when the consensus was that more GP registers were not necessary, especially considering they weren't really GP registers due to much reduced orthogonality.

Gunnar Quote:

If you want to talk to us about 68K instruction set ideas this is fine you can do this as any other user can. But maybe it would make a lot sense for you to get a little experience and understanding of the CPU first? I think you never coded the 68080 CPU, did you? You did not participated in any of its developments nor in testing of it. So I fear right now you not understand much of it.

Secrecy, poor documentation and a moving ISA and hardware target makes development difficult to understand and discourages development. I participated in AC development. I participated in AC development in many ways from ISA development to pointing out a Gunnar mistake in VHDL for the superscalar dispatcher. Granted, I was often ignored and I was on a need to know basis limiting my contributions.

Gunnar Quote:

And you never used AMMX, did you? You never used any of the Super-AGA hardware features, like improved Copper, improved Blitter, like enhanced Sprites, or like Maggie 3D unit, or any other new features like Chunky Dual Playfield or the enhanced Audio channels.

Many of the SAGA features were not added yet. Only Thomas's fully functional SAGA from the Natami was available then. I had little to do with AMMX which I didn't have much to do with and suggested keeping experimental with a priority on FPU support instead. The AC CPU core was originally scalar and based on Jen's N68050 that was developed for the Natami project. There is not much mention of their major contributions for which the AC project would likely not exist without. Did they want to share their contributions beyond the secretive AC project that is one mans vision and do what it takes to cooperate to bring back the 68k Amiga?

Gunnar Quote:

I think before you can talk any of the topics it would make sense for you to understand a little bit of them. Don't you agree?

I understand well enough.

Since we like benchmarks, here's one I found doing an admittedly simple benchmark, but it exposes why most of the time efficiency is key...especially when it costs less.

https://www.youtube.com/watch?v=2k_jP73Ly7A

Interesting that the SNES cpu benchmark is almost exactly 1/2 for the PCEngine...while clocked at 1/2 the speed. The Megadrive cpu at 7.6 Mhz lost to NEC's version of the 6502 despite being clock slightly higher and, you know, having them extra 'bits' and registers...and both the SNES and PC Engine were operating on RAM not an internal register.

68K's code was smaller...but who cares?

@matthey

Quote:

The x86 ISA has 7 GP integer registers and zero GP FPU registers which reduces performance,

That's old. DirectX6's geometry pipeline has 3DNow and SSE optimizations.

Intel Meteor Lake has a new very small CPU (LP-E) in the I/O chip with X86-64v3 ISA. Meteor Lake to be replaced by this year's Arrow Lake release.

Quote:

even for a CISC ISA although the handicap was not enough to keep x86 from becoming one of the most powerful desktop ISAs. The 68k ISA has 16 GP integer registers and 8 GP FPU registers. The 68k FPU also allows integer register to FPU register transfers, FPU register to integer register transfers and direct use of integer registers by the FPU for most FPU instructions.

1. https://barefeats.com/doom3.html
Mac Doom 3 performance issue revealed

Quote:

Glenda Adams, Director of Development at Aspyr Media: a. PowerPC architectural differences, including a much higher penalty for float to int conversion on the PPC. This is a penalty on all games ported to the Mac, and can't be easily fixed b. Add to this that the PowerPC has a higher overhead for functional calls, and not having as much inlining drops frame rates another few percentage points.

---------------------------------------
2.
Pentium III / DirectX6 era, IA-32 has 8 GPR, 8 X87/MMX, and 8 XMM registers.

X86-64v1 has 16 GPR, 8 X87/MMX, and 16 XMM registers.

X86-64v4 has 16 GPR, 8 X87/MMX, and 32 YMM registers.

AMD and Intel officially support Linux X86's X86-64 levels.

Modern X86 CPUs are optimized for integer and floating transfers to maximize on-chip data storage usage.

X87/MMX registers are still available in X86-64. SSE2/AVX IEEE FP64 doesn't replace X87's IEEE FP80.

Quote:

The x86-64 ISA has 16 GP integer registers which is the same as the 68k now. Code density was lost by adding them which also reduces performance and is the reason some programs still have better performance with smaller x86 code.

Fact: 68060 doesn't have a 64-bit instruction set.

What's important is the large out-of-order processing hardware for data locality.

Quote:

x86-64 AVX-512 uses 32x512b SIMD unit registers which can perform 16x32b floating point or integer SIMD operations per instruction while AMMX can perform 2x32b integer only SIMD operations per instruction.

I'm aware of AC68080's fixed point integer AMMX 64bit SIMD.

68K doesn't have AVX-512's GPU-style gather and scatter instructions. AVX2 only has a gather instruction. Thanks to Intel Larrabee R&D.

AVX's gather and scatter instructions enable mass fetch (read) or scatter(write) from a single instruction. AVX's gather instruction is important for populating 256-bit to 512-bit wide registers with multiple data.

68K version would be issuing multiple instructions for read/write.

SSE/AVX supports scalar, vector, integer, and floating-point. This is effectively attaching another almost CPU ISA onto the X86.

Windows 11 H2 is moving to a mandatory X86-64v2 equivalent i.e. Intel's 1st generation Core requirements. This is a hard minimum requirement.

Current generation AMD64-based game consoles have static CPU targets i.e. X86-64v3 (AVX2).

RPCS3 (PS3 emulator)'s LLVM has AVX-512 optimizations.


Quote:

The 68060 and Cyrix 6x86 chose to use integer register renaming where the P5 Pentium did not. Register renaming is also very valuable for maximizing FPU performance but has a higher cost due to wider registers.

Reminder, Pentium Pro (P6) was released in 1995. Cyrix 6x86 was also released in 1995. The P5 Pentium family is relegated into a "Celeron" product segmentation.

IDsoftware's Quake single-handedly wreaked Cyrix's 6x86 adventure.

John Carmack has a body count under his belt.

Last edited by Hammer on 28-May-2024 at 03:26 AM.
Last edited by Hammer on 28-May-2024 at 03:15 AM.
Last edited by Hammer on 28-May-2024 at 03:12 AM.
Last edited by Hammer on 28-May-2024 at 03:06 AM.

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

@Lou

Quote:

Lou wrote: Since we like benchmarks, here's one I found doing an admittedly simple benchmark, but it exposes why most of the time efficiency is key...especially when it costs less. https://www.youtube.com/watch?v=2k_jP73Ly7A Interesting that the SNES cpu benchmark is almost exactly 1/2 for the PCEngine...while clocked at 1/2 the speed. The Megadrive cpu at 7.6 Mhz lost to NEC's version of the 6502 despite being clock slightly higher and, you know, having them extra 'bits' and registers...and both the SNES and PC Engine were operating on RAM not an internal register. 68K's code was smaller...but who cares?

6502's processing has a "double pump" feature that operates on leading and failing edges. Commodore was sitting on a "double rate" processing CPU intellectual property gold mine.

For a similar-sized company in the 1980s, Commodore doesn't have AMD's leadership.

AMD hired the C65 CPU designer for the K7 Athlon project.

Last edited by Hammer on 28-May-2024 at 03:38 AM.
Last edited by Hammer on 28-May-2024 at 03:36 AM.

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

@matthey

Quote:

when the consensus was that more GP registers were not necessary,

The extra registers are not only extremely useful for coding
they also allow you to reach complete new level of performance with many routines, especially in the field of FPU and 3D operations.

I would suggest that you talk to some real programmers that actually use these features.
These people can tell you from their own experience how useful they find them.
Talk to some of the coders that programmed tuned routines for the OpenGL driver or for some 3D demos or of the RIVA video decoder or for some of the handtuned games or datatypes.

These coders will give you their experience and tell you what difference it makes.

For sure their experience can help you to better understand this -
how can you have a feeling for this as you never coded on the CPU?

@Gunnar

Heard of web archive’s wayback machine? What’s been on apollo-core.com over the years, anyone can see for themselves.

Clearly the original “mission statement� did not contain a word about any V4, as that came much later. The original “mission statement� regarding Amiga also mentioned something about “affordable�, why is that not longer there?

What’s your definition of “always�?

https://web.archive.org/web/20151022180123/http://www.apollo-core.com:80/

Last edited by kolla on 28-May-2024 at 07:22 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@matthey

Quote:

The AC CPU core was originally scalar and based on Jen's N68050 that was developed for the Natami project.

I see that you not understand the origin of the project.

The Natami 68050 CPU development was started by myself
and that development of it was done together with Jens and Chris.


Matthey maybe you should talk to some real people of the team like to Jens and Thomas - so that you learn a bit about the project history.

@kolla

Correct link seems to be https://web.archive.org/web/20151022180123/http://www.apollo-core.com/

Well, V2 was affordable and fast compared to competition and with V1 and V2 it was seemengly mostly Majstas goal to bring affordable accelerator, at least from his V500 launch speech. Then V4 like system was first mentioned, to my recall.

What is lacking compared to this description is reaching 233Mhz goal in enterprise FPGA (whatever that is)

Today everything is about V4 and even Vampire name was dropped due to taking Igor out of team as "un-licensed seller" an charging additional licenses.

Hope this is corrected by now as I see Majsta is active in Apollo team forum again.

V4 is significant improvement and kudos for all the good work. It has moved to a higher price point especially with port expanders which finally make V4 look more like Classic retro computer.

Its good its known who did what, hope that info will go public on Apollo website.

Hope this can move to some more computer like board, it has been done with FPGA boards like FPGA Arcade or MEGA65.

Seems for now Amigas best option is FPGA and its great and versatile technology.
Sadly, comparing to any modern ASIC seems pointless.

Last edited by vox on 28-May-2024 at 03:34 PM.

_________________
Future Acube and MOS supporter, fi di good, nothing fi di unprofessionals. Learn it harder way!

Lou Quote:

Since we like benchmarks, here's one I found doing an admittedly simple benchmark, but it exposes why most of the time efficiency is key...especially when it costs less. https://www.youtube.com/watch?v=2k_jP73Ly7A Interesting that the SNES cpu benchmark is almost exactly 1/2 for the PCEngine...while clocked at 1/2 the speed. The Megadrive cpu at 7.6 Mhz lost to NEC's version of the 6502 despite being clock slightly higher and, you know, having them extra 'bits' and registers...and both the SNES and PC Engine were operating on RAM not an internal register. 68K's code was smaller...but who cares?

Did you read the assembly code? The 68000 did not use moveq or addq which is important as the 68000 uses fewer cycles to fetch smaller code. It is likely the 68000 wins the benchmark contest with these minor changes. Did you read the comments which suggest this?

Hammer Quote:

1. https://barefeats.com/doom3.html Mac Doom 3 performance issue revealed ... Glenda Adams Quote: a. PowerPC architectural differences, including a much higher penalty for float to int conversion on the PPC. This is a penalty on all games ported to the Mac, and can't be easily fixed

It is not that x86 CPUs were so well optimized for integer to floating point conversions but rather that PPC CPUs had a memory bottleneck. Transfers through cached memory are potentially not much worse than passing registers directly between units but most RISC CPUs have a bottleneck because of load-to-use stalls and up to 2 more instructions per transfer to execute compared to CISC with mem-reg and reg-mem operations. Worst case through memory is also much worse. PPC developers likely expected OoO to solve these problems but PPC limited OoO has limited ability to solve these problems. Even more aggressive OoO may have problems due to synchronization of shared resources between units. It may be possible to rewrite the algorithm to use more fp and less mixed fp and integer code if the FPU is high enough performance but that is not an easy fix. The 68060 FPU requires mixed fp and integer code for best performance so many early 3D algorithms for x86 shouldn't perform too bad with the minimalist 68060 FPU. The 68k FPU supports all register conversions and transfers too.

Gunnar Quote:

The extra registers are not only extremely useful for coding they also allow you to reach complete new level of performance with many routines, especially in the field of FPU and 3D operations. I would suggest that you talk to some real programmers that actually use these features. These people can tell you from their own experience how useful they find them. Talk to some of the coders that programmed tuned routines for the OpenGL driver or for some 3D demos or of the RIVA video decoder or for some of the handtuned games or datatypes. These coders will give you their experience and tell you what difference it makes. For sure their experience can help you to better understand this - how can you have a feeling for this as you never coded on the CPU?

Orthogonal GP registers are very useful but there are diminishing returns as the number of registers increase. Non-orthogonal registers have reduced value but the same cost in resources. CISC CPUs can efficiently use cached memory for data and variables reducing register requirements.

A good indicator of how well registers are being used would be to change the ISA removing non-orthogonal register banks and see how much software is broken. Gunnar did just this when ColdFire instructions were added with few complaints. Registers are not useful when they are not used.

I agree that some 3D algorithms benefit from many fp registers which allow more parallelism despite longer fp instruction latencies. I agreed with Gunnar that 8 FPU registers was low for some algorithms and that more could be added in an orthogonal way. When Gunnar asked me to create a FPU ISA enhancement, I increased the FPU registers to 16 with other improvements which I considered a good starting point for evaluation but Gunnar immediately rejected for only supporting 16 registers. I think 16 FPU registers is good with FPU register renaming. More may be useful without register renaming but it should still be adequate with a SIMD unit that supports fp. Compiled code for the 68k FPU makes surprisingly good use of just 8 FPU registers but existing code needs FPU register renaming for some parallel execution anyway.

Gunnar Quote:

I see that you not understand the origin of the project. The Natami 68050 CPU development was started by myself and that development of it was done together with Jens and Chris. Matthey maybe you should talk to some real people of the team like to Jens and Thomas - so that you learn a bit about the project history.

Looking through the N68050 source code, I see copyrights from Jens and someone else but not Gunnar or Chris. The source code is very neat with many comments which I believe is a trait of Jens. Gunnar is a fast and sloppy coder in my experience. Jens wanted to open source the N68050 source code but Gunnar convinced him not to even though it seemed to me like he didn't have a leg to stand on. I suspect Thomas requested that SAGA be open sourced as part of the deal to let Gunnar use it for the AC project resulting in the announcement that it would be open sourced years ago. Indeed, I would talk to reliable people like Jens and Thomas if wanting to use their work.

@matthey

Quote:

CISC CPUs can efficiently use cached memory for data and variables reducing register requirements.

Reading from memory/cache/stack is a very limited resource that can only very difficultly be scaled up.
On the other hand reading several register per cycle is easy and in comparison very cost effective to scale up.

Therefore a good design will always favor to put values in register instead cache/stack.

@matthey

Quote:

Compiled code for the 68k FPU makes surprisingly good use of just 8 FPU registers

Yes the old FPU code could work OK withj 8 regs.
But we all know that the old 68K FPU is not pipelined.
A pipelined FPU needs unrolled code to make full use of it.
To unroll code you need several times the number of registers.
This is very simple logic.

Most today pipelined FPU (power/intel/etc) have often a latency of 6 clocks.
This means you want to unroll your work loops generally 4-6 times to be able to eat the latency.
For doing this you need 4 to 6 times the number of register.


We all know that IBM did increase the FPU register to 64 since a few years for POWER?
Why did IBM do this - because its very useful for increasing performance.
And yes IBM also has register renaming in addition to this!


Having 32 FPU register plus being CISC gives the 68080 FPU a huge advantage over the "old 8 Register".



Matt

If you want to learn more then I highly suggest you to talk to the people which actually code.
Talk to coders writing real FPU code.
And talk to coders which wrote performance coder for the 68080.
You can learn a lot.


If you never code real software, and your "knowledge" is based on Wikipedia ...
yes you can then also contribute to brainstorming and post here in this Forum - "as a Wikipedia Quarterback "


Do for real serious development more knowledge will be useful.

Last edited by Gunnar on 28-May-2024 at 08:49 PM.
Last edited by Gunnar on 28-May-2024 at 08:30 PM.

@matthey

You have a good fantasy - we can see this.


Super-AGA is completely differently in design to Thomas NATAMI AGA - and is a complete unrelated development.


Super-AGA is based on a concept of internal DMA buffers and decoupled prefetcher
with the ability to run exact to pixel timing and also unrelated to pixel timing.
This is somewhat an extension to what Haynie already planned in AAA
the reason for this internal design is to fully optimized Super-AGA to be able
to make perfect usage of modern memory technology.

Besides this fundamental design difference.
Thomas Hirsch uses AHD as coding language which we don't use.
We simulate all our code in Modelsim - And Modelsim is not compatible to AHDL.
All our code is 100% written in VHDL - which is a complete different language.



Matthey,

if we chat and talk about a options and ideas and role some idea back and forth in chat.
Than you then think "you were tasked to design an architecture"?
This is a very interesting point.


Whatever CPU code you believe to have...

if its the N68050 than majority of the VHDL code was written by me.
And literally every line in some of its units e.g. every line in the cpu decoder was written by me.
Wherever you got the file from - it is an illegal copy -
even if my copyright name was removed from some files.

Whoever gave you the file did not had the right to do this.
Delete this illegal copy.
And if you share our core then you do copyright violation and you are breaking the law.

Last edited by Gunnar on 28-May-2024 at 09:11 PM.
Last edited by Gunnar on 28-May-2024 at 08:57 PM.