@matthey

RISC CISC doesn't matter.
68k is still too slow and cost too much. As in 1995.
GvB do his best but even vampire has integer performance about 75 MHz 060.

@Karlos

32 bit big endian cpu give integration with 68k software.
32 bit big endian cpu may easily share data with old 68k software.
I may use 68k dll in ppc code and ppc dll in 68k code.
Eveything is already avaible and Amiga ppc fill like my old 1200.

@ppcamiga1

I am glad you get to use this rare and exotic PPC hardware. Maybe you should work as a demonstrator in a computer museum? It's a shame no PPC Amiga machines are being marketed any more but the coupon and pre-order schemes continue! When it's done!

Last edited by BigD on 26-Apr-2022 at 07:49 AM.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@ppcamiga1

Emulation on x64 can do everything you've just listed. Except that you don't need to mix any PPC into it because JIT emulation on any current x64 destroys every physical 68K and PPC solution for running 68K applications by a country mile. The sole benefit of PPC is that it can run software written for PPC faster than QEMU can if it's forced to use the softfloat implementation. Petunia on my old G4 800MHz on OS4 was blazing fast by 68K standards, especially with native system calls, but make no mistake, my old PC running Amithlon absolutely crushed it. And that performance gap has only widened as the years have passed on.

So, every reason you've just listed is nonsense as to why a "big endian 32 bit" processor is even a requirement, let alone an advantage. There are even instructions for load/store big endian on x64 so the old Amithlon trick of emulating big endian memory model is theoretically well suited for x64 JIT.

I have absolutely no issue at all with people preferring a given architecture, whether or not it's real 68K, FPGA, PowerPC, AArch64, or whatever. All valid subjective preferences. I still have real 68K and PPC hardware. But your attempt to present PPC as objectively better is just the zenith of denial of reality.

_________________
Doing stupid things for fun...

@Hypex

Quote:

Hypex wrote: @kolla I tend to think it's funny that Apple ARM models are referred to as Apple Silicon. How is it Apple silicon? They didn't design the CPU.

Yes they did? As far as I know, Apple license rights to design and produce ARM chips, and all ARM in Apple products since iPhone have been made in-house. Before that, they used ARM chips from Intel, XScale etc.

Quote:

In that case why wasn't the PPC called Apple Silicon as well?

Because Apple didn’t design and produce the PowerPC chips, Motorola and IBM did.

Quote:

They forged it in the AIM alliance.

Not really, Apple wasn’t doing much chipdesign at the time, all though they provided input to Motorola in terms of needs and wishes, and could benefit from being primary customer.

Quote:

Perhaps the strangest thing is there are now two CPU types again with three common OS. When PPC had died off and only x86 was left. Now ARM comes in to really replace PPC for Apple. They've already gone down this road. They went to Intel and secured the future. But now they are backtracking and using another RISC again. It's just another PPC really. If PPC failed to compete with x86 how do they expect ARM to? Just my thoughts.

Forget architecture, RISC vs CISC and all that…
- Apple had commitments when it came to PowerPC, due to AIM, but also to their customers to whom they had been touting the superiority of PowerPC to. So the OS (NeXTStep) had to be ported to PowerPC. When this port was done, we had OSX. In 2006, there were no good reasons to stick with PPC, as Motorola was gone, Freescale and IBM weren’t so interested in “desktop class” PowerPC anymore (focusing rather on embedded and HPC), and so going back to IA32 was the obvious escape. However, with Intel, Apple was just yet another customer and had little to no influence over the architectural decisions. It was now clear for Apple that the best way forward was to rely on themselves for chips, but getting there was a long path. Apple licensed ARM (which they already had lots of experience with from previous products) and started doing their own CPU designs and SoCs. First product with the new internally designed CPU was the original iPhone.

So no, going to ARM is not “going back to the failure that is RISC”, it is going forward with in-house design and production, and being in control over their own supply lines. If anything, it was going to Intel for OSX in 2006 that was “going back” - OSX on PowerPC was just a short period of 6 years, before that, Rhapsody and NeXTStep had existed on x86 for equally long period already.

Last edited by kolla on 26-Apr-2022 at 09:41 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Well summarised.

@Hypex

Apple's vertical integration is the most commendable part of their business development IMHO. They have invested shrewdly with PA Semi etc and forged their own path. While their walled garden and over emphasis on style over substance is still an issue to me they have upped the game substantial on the chip fab/design level compared to C= and MOS which was small fry by comparison with no R&D ongoing! Fabless chip design is they way to do it and licensing ARM while adding value with PA Semi engineers is inspiring.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

ppcamiga1 Quote:

RISC CISC doesn't matter. 68k is still too slow and cost too much. As in 1995.

The 68060 was high performance because of CISC only pipelining of single cycle instruction reg-mem accesses while avoiding load-to-use penalties/stalls and a deeper 8 stage pipeline allowing more work per cycle and a higher max clock while rejecting the minimal shallow pipeline design that was part of the RISC philosophy.

68060 - 8 stages
PPC 604 - 6 stages
Pentium P5 - 5 stages
PPC 601 & 603 - 4 stages
ARM 610/710 (Acorn RISC PC) - 3 stages

The 68060 lacked value when Motorola chose not to increase the clock ratings as a deeper pipeline uses more transistors increasing the cost of the chip. Still, the 68060 uses fewer transistors than the Pentium P5 and PPC 604. After PPC performance issues due to fat code were addressed with more caches, the 6 stage PPC 604e used more than twice as many transistors than the 68060 and the 4 stage 603e used slightly more transistors than the 68060. Apple was unhappy that PPC chips wouldn't clock up but was this because transistors were used for caches instead of increasing the pipeline depth? Did Motorola then sabotage the 68060 by not clocking it up to keep the 68060 from having higher clock rates than the "politically chosen" higher end PPC chips? Would Apple have moved back to the 68060 to get higher clocked and more cache efficient CPUs like they later did when they switched to x86?

ppcamiga1 Quote:

GvB do his best but even vampire has integer performance about 75 MHz 060.

The Apollo Core likely has integer performance equivalent to a 100-200MHz 68060. This is a moderate improvement of the DMIPS/MHz as the Apollo Core is clocked at less than 100MHz. Gunnar has not done his best because he failed to cooperate for the preparation and creation of an ASIC which could have more than 10 times the performance.

Last edited by matthey on 26-Apr-2022 at 03:58 PM.
Last edited by matthey on 26-Apr-2022 at 03:56 PM.

@Karlos

I have decent pc with good i9 cpu.
I have also mac G4 and G5.
What You wrote is pure bs.
Native ppc code on my G4 is still almost three times faster
than 68k code on latest WinUAE on my fast i9 pc.

@matthey

Pity the 68060 FPU pipelining wasn't better though.

_________________
Doing stupid things for fun...

@matthey

Yes We know.
That bad Motorola drop 68k.
How they could do this.
But it was thirty years ago.
Maybe You should at least accept that.

I'm not interested in false benchmarks of GvB.
I have vampire and real integer performance it has is about 75 MHz 060.
Yes it has fast memory and fast 2D.

@ppcamiga1

That isn't the comparison being made, you either can't read or you're just being obtuse. How fast is 68K code under emulation on your PPC compared to on your i9? That is the question. Nobody cares about PPC native performance for 68K applications. It's irrelevant. Your whole contention so far is that PPC is better than x64 because it's 32 bit and Big Endian, as if this really matters somehow for a completely emulated processor.

_________________
Doing stupid things for fun...

Karlos Quote:

Pity the 68060 FPU pipelining wasn't better though.

I believe it was a good decision at the time to save transistors in the FPU and use them for optimal integer pipelining. A later generation 68k CPU could have added a fully pipelined FPU for better FPU performance as the cost of transistors dropped. FPU instructions are pre-decoded with integer instructions and then partially processed in an integer pipeline so only the last stages of execution occur in the FPU which executes a FPU instruction in parallel to the integer units. This is efficient and provides good performance for the common case of mixed integer and FPU code. Also, the FPU ISA is good compared to the stack based x86 FPU ISA. The x86 FPU has significantly higher theoretical performance but in practice the 68060 likely comes close in FPU performance. This was demonstrated by vbcc compiled ByteMark results from Frank Wille.

https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=44391&forum=25#847418

The 68060@50MHz achieved "FLOATING POINT INDEX 0.52" where a Pentium@50MHz should have had FLOATING POINT INDEX 0.56. The 68060 only comes out to ~7% behind the Pentium FPU performance in this comprehensive FPU benchmark which is highly dependent on compiler code generation quality and the 68060 often lacked in compiler support. I don't even know of a compiler which has a 68k code scheduler which is important for performance of an advanced in order core like the 68060. Even without a code scheduler, the 68060 has shown up to 40% better integer performance than the P5 Pentium at the same clock speed. I consider the 68060 40% better integer performance with 7% less FPU performance coupled with the integer 8 stage pipeline vs 5 stage allowing for higher clock rates to make the 68060 a Pentium killer that wasn't exploited. The 68060 didn't just dominate a higher performance Pentium design with a more balanced design but also dominates in PPA. The 68060 uses significantly less power and has a much better performance/W which became more important later with embedded and portable devices.

ppcamiga1 Quote:

I'm not interested in false benchmarks of GvB. I have vampire and real integer performance it has is about 75 MHz 060. Yes it has fast memory and fast 2D.

I can believe a Vampire version 1 and 2 may have that low of performance. The newer Vampire V4 hardware has a higher clocked and much bigger FPGA.

Last edited by matthey on 26-Apr-2022 at 05:45 PM.

@Karlos

Emulation of PS3 is perfect yet, not sure any straight face can say that better to use a emulator.

https://www.youtube.com/watch?v=ljJ8DKEy69c

Last edited by NutsAboutAmiga on 26-Apr-2022 at 05:51 PM.

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

@NutsAboutAmiga

Better experience is subjective and I'm ok with that. The conversation about emulation of 68K on x64 versus emulation of 68K on PowerPC, which is not subjective. The argument has been that PPC big endian 32-bit is somehow an objective advantage when in truth it simply isn't. If you want the best performing, most compatible 68K code performance and aren't chained to a big endian 32-bit ball of your own insistence, a decent JIT for x64 is a no brainer. Amithlon and UAE have shown this categorically. If I run 68K binaries under Petunia on a G4 and under JIT emulation on my equally old PC, the performance difference is big. Both completely destroy my real 68040, but to find a PowerPC that will run 68K code under Petunia (or Trance) as well as my old Core 2 Quad runs it on UAE involves a lot of money. To rival it in any remotely modern i7 ... Forget it. Selling my firstborn on the dark web to buy some mythical PPC machine that will manage that is not the kind of great UX I have in mind.

I don't have an axe to grind about this. Subjective choices are fine. I like PowerPC and I like ARM. I like x64. Just don't make claims that one is inherently better than another for 68K emulation because it shares some architectural similarities. The whole point of emulation, especially JIT emulation, is that architectural similarity between the emulated machine and emulation platform are irrelevant. It isn't the 68K code that's running anymore, it's native code compiled from it. Is there a desktop class PowerPC that can hold a candle to the latest x64 iterations for native performance? Of course not. There hasn't been a desktop PowerPC since the G5.

Last edited by Karlos on 26-Apr-2022 at 07:03 PM.
Last edited by Karlos on 26-Apr-2022 at 07:03 PM.

_________________
Doing stupid things for fun...

Karlos Quote:

Better experience is subjective and I'm ok with that. The conversation about emulation of 68K on x64 versus emulation of 68K on PowerPC, which is not subjective. The argument has been that PPC big endian 32-bit is somehow an objective advantage when in truth it simply isn't. If you want the best performing, most compatible 68K code performance and aren't chained to a big endian 32-bit ball of your own insistence, a decent JIT for x64 is a no brainer. Amithlon and UAE have shown this categorically. If I run 68K binaries under Petunia on a G4 and under JIT emulation on my equally old PC, the performance difference is big. Both completely destroy my real 68040, but to find a PowerPC that will run 68K code under Petunia (or Trance) as well as my old Core 2 Quad runs it on UAE involves a lot of money. To rival it in any remotely modern i7 ... Forget it. Selling my firstborn on the dark web to buy some mythical PPC machine that will manage that is not the kind of great UX I have in mind.

The 32 bit 68k advantage came from ppcamiga1 so I wouldn't bother mentioning it. The Apollo Core is a 64 bit core demonstrating that it is possible to have good compatibility using a 64 bit 68k core. I feel like the decision to add 64 bit support to the existing 68020 ISA was to save transistors in a limited FPGA and misses the advantage of using a separate 64 bit mode where the encoding space can be cleanup up and instruction sizes using 2 bits for byte, word, longword, quadword is compelling like your 64 bit mc68k ISA uses, not that it would ever be used for real hardware due to other inefficiencies. ARM, x86-64 and PPC have 32 bit modes on 64 bit cores though not all allow 32 bit code and 64 bit code to execute at the same time. A separate mode is a good way to maintain maximum 32 bit compatibility on a 64 bit core.

Karlos Quote:

I don't have an axe to grind about this. Subjective choices are fine. I like PowerPC and I like ARM. I like x64. Just don't make claims that one is inherently better than another for 68K emulation because it shares some architectural similarities. The whole point of emulation, especially JIT emulation, is that architectural similarity between the emulated machine and emulation platform are irrelevant. It isn't the 68K code that's running anymore, it's native code compiled from it. Is there a desktop class PowerPC that can hold a candle to the latest x64 iterations for native performance? Of course not. There hasn't been a desktop PowerPC since the G5.

Some architectures are better at emulating other architectures but overall emulation performance is much more dependent on the core design and performance.

@Karlos

Quote:

Both completely destroy my real 68040, but to find a PowerPC that will run 68K code under Petunia (or Trance) as well as my old Core 2 Quad runs it on UAE involves

That’s like comparing orange and peaches.

UAE requires a lot resources does good job mimic the real thing and but has to be fine-tuned sometimes, it takes resources available, there is not lot left.

Petunia on other hand only covers the CPU does not require lots of resources, sure some memory but that’s all, Putunia does have Paula/Denice/etc emulation instead depends on program or game to interact with OS in hopeful meaningful way.

Petunia is great for migrating code from 680x0 and or mixing PowerPC and 680x0 code, a 680x0 program can use optimized PowerPC library, or PowerPC program can technically use 680x0 library if there is none native. A PowerPC program can execute some 680x0 code, these tricky things useful and meaningful, things if you’re into AmigaOS and programs & tools.

64bit is not meaning full as no 32bit program runs on 64bit, on AmigaOS, but sure if did implement some 32bit API to 64bit API abstraction layer that be great.

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

@NutsAboutAmiga

That's only relevant if you are emulating the chipset. As an Amiga user, I stopped depending on the chipset the day I got a graphics card, which was without a doubt the most transformative upgrade I ever installed. Then again, we are just talking about CPU emulation here anyway. Even with the overhead or running and entire machine emulation, UAE ran ant compute bound 68K code faster. And then there's Amithlon. With the latter you could run fully native code from the emulation too, which is the same basic advantage you are claiming for PPC systems. The idea isn't somehow unique to PPC.

If all you want to do is play games written for the original hardware, any of the poll selections work. If you want to use 68K productivity software, more CPU power is always a good thing. And right now, fastest 68K platform is JIT emulation on x64. It's just the way technology panned out.

Last edited by Karlos on 26-Apr-2022 at 10:01 PM.
Last edited by Karlos on 26-Apr-2022 at 09:59 PM.

_________________
Doing stupid things for fun...

@Karlos

Amithlon was modified UAE, so essentially it did not have update exec.library it did have a old dos.library, the graphic.library is outdated, and has no support or 3D, most of OS was emulated. And Amithlon is almost fully abandoned.

Who know what might become if it was continued, but that never happened.
its just one of many what if scenarios.

Last edited by NutsAboutAmiga on 26-Apr-2022 at 11:33 PM.
Last edited by NutsAboutAmiga on 26-Apr-2022 at 10:52 PM.

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

NutsAboutAmiga Quote:

Amithlon was modified UAE, so essentially it did not have update exec.library it old dos.library, the graphic.library is outdated, and has no support or 3D, most of OS was emulated. And Amithlon is almost fully abandoned.

That's because the Amiga elites set up road blocks for Amithlon like they did for the 68k. It was PPC or the highway despite the curse of PPC.

o Apple nearly went bankrupt in 1997 after transitioning from popular 68040 Macs to PPC and finally turned around after transitioning to x86 in 2006.

o Motorola went all in on PPC discarding the 68k in the process, lost the embedded market and now the once mighty Motorola is a Chinese company.

o Supercomputer POWER designer IBM tried to create a high performance G5 PPC but it was a major disappointment in performance and power thus killing off PPC on the desktop.

o Apple purchased P.A. Semi who designed one of the more promising PPC cores and promptly cancelled PPC designs and the developers moved to ARM development. Apple had completed PPC core designs available to them and chose ARM.

o All the consoles have transitioned away from PPC for the current generation of hardware to get better performance/price in the case of x86-64 Playstation and Xbox or better performance/W and a lower price in the case of the Switch. The PPC PS3 had disappointing sales compared to other Playstations and was difficult to develop for.

o Hyperion nearly went bankrupt selling AmigaOS 4 for the PPC because not enough AmigaNOne units were sold to spread out development costs while the 68k AmigaOS was profitable and saved them.

Last edited by matthey on 26-Apr-2022 at 11:42 PM.

@NutsAboutAmiga

Well if the conversation is about what would have been a good continuation of 68K... Amithlon was hands down the fastest 68K Amiga I've ever used and I like to time things very carefully. It absolutely screamed. Faster than UAE on the same hardware. Faster than 68K on OS4 or MorphOS on any contemporary era PPC. Amithlon wasn't abandoned, it was cancelled.

You mention emulation of the operating system as if it's a bad thing. It isn't. It's a good thing. Have native for interfacing to hardware and to accelerate common tasks like block memory operations, but JIT everything else (maybe interrupts are better interpreted for latency sake). In an alternative universe, one that didn't spend two decades sucking to be an Amiga user in, we'd all be using 68K or a functional subset derivative as a compiled common language runtime for whatever hardware we prefer to have, not stuck in fractured niches dominated by obsolete / expensive kit.

I get that people are attached to PPC, for sentimental reasons. And I still have OS4 and can still run it on my bonafide A1200/BlizzPPC while my A1 died the death most others seemed to. It's nice there are some new hardware available, but PowerPC is dead. Just as dead as 68K.

_________________
Doing stupid things for fun...