What is a hardware compatible CPU? *spawn

[phoenix_chipset]

Two different CPUs for development sounds like a nightmare like Sega Saturn.

You have two options for BC - Better idea is to keep Jaguar but use it as the OS chip and leave the games to an 8 core 8 thread Zen.

Keeping multithreading out would let it clock higher, improve yields and reduce heat ; all ideal for a mass market console. I can't honestly see a dedicated gaming device needing 16 threads honestly.

That's if you want hardware based BC (understandable) but I think Xbox one's solution is brilliantly elegant and it has significant advantages. In the absense of Jaguar I could see use for a 16 thread Zen for the background stuff, and without needing to power two chips.

 

[Shifty Geezer]

Why are we thinking of 2 x64 CPUs? Why not just use Zen?

 

[Kaotik]

Why are we thinking of 2 x64 CPUs? Why not just use Zen?

If AMD is inside the next consoles, they will definitely use Zen-based architecture for the CPU, customized or not

 

[AlNom]

Why are we thinking of 2 x64 CPUs? Why not just use Zen?

Indeed. We somewhat went over this a little while back (I should know don't search "big.little")
https://forum.beyond3d.com/posts/2005899/

 

[phoenix_chipset]

Why are we thinking of 2 x64 CPUs? Why not just use Zen?

For *hardware* back compat.

 

[iroboto]

For *hardware* back compat.

they use the same instruction sets, what is amiss here for compatibility? If the ISA isn't changing, is this a large issue?

 

[Shifty Geezer]

For *hardware* back compat.

Hardware BC typically means able to run the same code. So Wii U had hardware BC with the GC CPU despite being a different CPU because it was the same ISA. Zen can run exactly the same code as Jaguar, only faster, so Jaguar isn't necessary. Certainly CPU differences in PC has never been a problem even between completely different implementations (AMD v Intel). I doubt devs are writing CPU specific assembler that'll crash out on a different implementation of the ISA.

That said, I remain open to possibility there'll be BC issues if someone can present a good technical reason why. Until then, it sounds unnecessary. One of the reasons for choosing x64 as a CPU arch is future-proofing compatibility.

 

[phoenix_chipset]

Hardware BC typically means able to run the same code. So Wii U had hardware BC with the GC CPU despite being a different CPU because it was the same ISA.

It was the same cpu. Just with 2 extra cores and higher clocks. Wii, GC and Wii U all share the same cpu.

I don't know how accurate this is, but cpuboss claims ryzen lacks avx and fma4 instructions. http://cpuboss.com/cpus/AMD-Ryzen-5-Ryzen™-5-1600-vs-AMD-Athlon-Athlon™-5350
In any case, Jaguar is obviously vastly different from Ryzen so I don't know why you would expect hardware bc from zen.

 

[Shifty Geezer]

It was the same cpu. Just with 2 extra cores and higher clocks. Wii, GC and Wii U all share the same cpu

Okay, probably. We don't massively kno.

I don't know how accurate this is, but cpuboss claims ryzen lacks avx and fma4 instructions. http://cpuboss.com/cpus/AMD-Ryzen-5-Ryzen™-5-1600-vs-AMD-Athlon-Athlon™-5350

Zen has AVX2, so it's only the FMA implementation that might be a problem.

In any case, Jaguar is obviously vastly different from Ryzen so I don't know why you would expect hardware bc from zen.

It doesn't have to be identical. It has to run the same code. x86 processors have been evolving for decades and still run the same code largely. Certainly any two processors in the past five years will run the same code. You can swap out your Intel CPU with an AMD in your PC and it'll run, despite being completely different architectures. The only time this will fail is if the processors are targeted at the machine level with specific instructions. If console devs are optimising to that level, yes, it could be a problem. If they aren't and the execution is handled in the compilers and CPU microcodes, it won't be. To my mind, devs are no longer hitting the CPUs that hard, but I may be wrong on that.

 

[Globalisateur]

Okay, probably. We don't massively kno.
Zen has AVX2, so it's only the FMA implementation that might be a problem.
It doesn't have to be identical. It has to run the same code. x86 processors have been evolving for decades and still run the same code largely. Certainly any two processors in the past five years will run the same code. You can swap out your Intel CPU with an AMD in your PC and it'll run, despite being completely different architectures. The only time this will fail is if the processors are targeted at the machine level with specific instructions. If console devs are optimising to that level, yes, it could be a problem. If they aren't and the execution is handled in the compilers and CPU microcodes, it won't be. To my mind, devs are no longer hitting the CPUs that hard, but I may be wrong on that.

 

[phoenix_chipset]

Uh, yeah we do know they all share the same CPU. At least I know. ;-) That's how a modded Wii u can play GameCube games. Because, if it was part emulation than Nintendo wouldnt have accounted for GameCube games and only Wii games would run.

The only case of across the board BC without hardware compatibility are ps1 games on the ps3. But you only have that because of the massive difference in CPU power. Nintendo couldn't have possibly be using emulation with such similar CPU power and if they were, well that's pretty embarrassing for ms who has to release BC games piece by piece.

Lol of course some developers are using these console CPUs at a very low level unlike pc. It's how it's always been. But it doesn't matter if the majority of developers arent, with hardware BC you have to account for every possibility. If you don't want Jaguar in next gen, then what you would get is software emulation, or at least partial. And that means they'd have to release games individually like ms. Expecting otherwise is ignorant wishful thinking.

 

[Allandor]

Lol of course some developers are using these console CPUs at a very low level unlike pc. It's how it's always been. But it doesn't matter if the majority of developers arent, with hardware BC you have to account for every possibility. If you don't want Jaguar in next gen, then what you would get is software emulation, or at least partial. And that means they'd have to release games individually like ms. Expecting otherwise is ignorant wishful thinking.

That's not the case. x86 is x86 compatible (even with all the additional extensions like SSE, AVX, FMA, ...). It might get executed slower or faster in some cases, but the code is the same and will result in the same results. Also the WiiU had not exactly the same CPU like the Wii. Yes, the Wii was more or less a upclocked GC with a few more features, but the WiiU CPU at least was a multicore-cpu and was no longer a in-order CPU. And that's quite a change. But the old code was still compatible with the new CPU, because the instruction set was still compatible. The extensions like AVX are normally compatible (at least they should) and are just additional instruction sets.
So the only problem could occur because of the speed, which doesn't matter als long the new CPU is that much faster that it can easily outperform the old one. So any instruction that might be slower would be balanced by instructions that are faster.
GPU architectures on the other side are not that forgiving. But as long as it is not to brutally optimized (in case of the xbox you have "directX") you could work around that.

 

[Shifty Geezer]

Uh, yeah we do know they all share the same CPU.

What are you calling the same CPU? They are all PPC 750 based, but with changes in cache, registers, cores, etc., the end CPU is different.

At least I know. ;-) That's how a modded Wii u can play GameCube games. Because, if it was part emulation than Nintendo wouldnt have accounted for GameCube games and only Wii games would run.

Okay, you're working from speculation and not technical knowledge. Wii used the same CPU as GC, just shrunk and clocked higher. Wii U used a new custom processor based on teh same architecture and ISA. This can run the same PPC code used in GC.

The only case of across the board BC without hardware compatibility are ps1 games on the ps3.

Because every gen has used radically different CPUs. If PS4 had used Cell 2, it'd have been compatible with Cell. Is XB1 had used some custom PPC CPU, it'd have been compatible with XB360's CPU code.

Lol of course some developers are using these console CPUs at a very low level unlike pc. It's how it's always been.

Again, arguing from personal theories and no actual evidence.

If you don't want Jaguar in next gen, then what you would get is software emulation.

No. You really don't understand about CPUs and don't seem interested in learning, certainly if you're calling people making technical arguments 'wishful thinkers'. Present to me an argument factoring in the CPU microcode and how an x86 CPU may fail on some x86 compiled code and I'd start to listen. Otherwise you're just generating noise in this thread and the rest of us will be looking at compatible x64 CPUs in the next console with nonsense about needing a secondary Jaguar.

 

[phoenix_chipset]

That's not the case. x86 is x86 compatible (even with all the additional extensions like SSE, AVX, FMA, ...). It might get executed slower or faster in some cases, but the code is the same and will result in the same results. Also the WiiU had not exactly the same CPU like the Wii. Yes, the Wii was more or less a upclocked GC with a few more features, but the WiiU CPU at least was a multicore-cpu and was no longer a in-order CPU. And that's quite a change. But the old code was still compatible with the new CPU, because the instruction set was still compatible. The extensions like AVX are normally compatible (at least they should) and are just additional instruction sets.
So the only problem could occur because of the speed, which doesn't matter als long the new CPU is that much faster that it can easily outperform the old one. So any instruction that might be slower would be balanced by instructions that are faster.
GPU architectures on the other side are not that forgiving. But as long as it is not to brutally optimized (in case of the xbox you have "directX") you could work around that.

GameCube and Wii had out of order CPUs as well. Not in the way current processors are OoO but more so than ps3/360 which are in order.

It's just hard to believe a 20ghz pentium 3 could run any code from today (assuming the program doesn't need multiple cores)
----

Shifty, I've never heard anything about additional registers in any of the gekko based CPUs. Certainly not from GC to Wii. Because they're not documented beyond gekko. Now who's arguing from personal theory?

There isn't any logical reason for Nintendo to take away functionality the previous chips had when the Wii u chip is from the same architectural family. You just lack the ability to piece this together.

For example, there's no extension sandy bridge has that kaby lake doesn't.

 

[Shifty Geezer]

It's just hard to believe a 20ghz pentium 3 could run any code from today (assuming the program doesn't need multiple cores)

That's forwards compatibility. We're talking about backwards. How many x86 programs that ran on a P3 cannot be run (on the same OS) on a modern Intel or AMD x64 processor? These processors are backwards compatibles. AVX2 is BC with AVX.

Shifty, I've never heard anything about additional registers in any of the gekko based CPUs.

I was pointing out that if they had changes, they'd be different CPUs. We don't know. I already made that point. Although we do know Espresso has three cores and more cache, so it's certainly a new CPU by any ordinary definition.

There isn't any logical reason for Nintendo to take away functionality the previous chips had when the Wii u chip is from the same architectural family. You just lack the ability to piece this together.

You're being insulting and it's getting annoying. You haven't even made a point here relating to the discussion of Zen running Jaguar code, or x86 running on different CPUs. Who said Wii U would take away functionality? And by the same logic, what makes you think AMD would make a CPU that can't run x64 code? How are you getting from "For example, there's no extension sandy bridge has that kaby lake doesn't." to "AMD's Zen CPU superseding Jaguar will not be able to run code that runs on Jaguar."?

 

[Allandor]

It's just hard to believe a 20ghz pentium 3 could run any code from today (assuming the program doesn't need multiple cores)

As long as the code is x86 code (and none of the todays extensions like AVX were used) 1TH Pentium 3 could still execute the code if you could hit the frequency. The CPU has an instruction set. What it does internally with those instructions is another case, but it is defined how the instruction is called and what its result is.
The only problem with some instruction sets occur because of bugs in the hardware (or sometimes in the firmware). You can even run DOS on todays computers, as long as DOS doesn't have any problems with the amount of memory or something else (like drivers). In case of software compatibility the OS of the new console would only restrict e.g. the memory of the game (if even this is needed). But as I wrote before, the GPU could be a problem, if there is no software abstraction between the game and the gpu.

And that point with the WiiU cpu, might be my mistake, I always thought it was in order in the wii because Nintendo did bring out that it is an ooO architecture in the WiiU. I never thought they would compare that against the CPUs in the xb360/ps3.

 

[phoenix_chipset]

I was pointing out that if they had changes, they'd be different CPUs. We don't know. I already made that point. Although we do know Espresso has three cores and more cache, so it's certainly a new CPU by any ordinary definition.

Semantics then. Because as I said before, they are from the same architectural family so for all intents and purposes, Wii U has 100% architectural Backwards compatibility. This is different from talking about Zen running jag code.

That's forwards compatibility. We're talking about backwards. How many x86 programs that ran on a P3 cannot be run (on the same OS) on a modern Intel or AMD x64 processor? These processors are backwards compatibles. AVX2 is BC with AVX.

Actually here's a much more modern example ; fairly recently I had trouble running crysis on my new computer because it was coded for 32 bit OS's. That's on PC, let alone whatever wonky workarounds developers are able to use on console. I'm going to assume there are more programs that have issues. I know both jag and zen are 64 bit though.

You're being insulting and it's getting annoying. You haven't even made a point here relating to the discussion of Zen running Jaguar code, or x86 running on different CPUs. Who said Wii U would take away functionality? And by the same logic, what makes you think AMD would make a CPU that can't run x64 code? How are you getting from "For example, there's no extension sandy bridge has that kaby lake doesn't." to "AMD's Zen CPU superseding Jaguar will not be able to run code that runs on Jaguar."?

You started it. Don't say I don't want to learn something new and i'm nothing but noise and expect niceties in return.

You said "So Wii U had hardware BC with the GC CPU despite being a different CPU because it was the same ISA." Implying that Wii U didn't have all previous extensions and architecture, just the same coding language.

Because Zen does not have all the extensions that Jaguar does. Meanwhile, a cpu in the same family would have all previous extensions. To be absolutely certain hardware is 100% compatible with older software without additional software workarounds, you have to have the same architectural design. It's not that complicated. You said it yourself that you're not certain there would be no issues from one arch to the next, and here's your quote - "That said, I remain open to possibility there'll be BC issues if someone can present a good technical reason why. Until then, it sounds unnecessary." That's not a statement of certainty, or from someone who knows everything on the subject. I'm in the same boat, just don't shoot me down because I have different uncertainties.

 

[phoenix_chipset]

As long as the code is x86 code (and none of the todays extensions like AVX were used) 1TH Pentium 3 could still execute the code if you could hit the frequency. The CPU has an instruction set. What it does internally with those instructions is another case, but it is defined how the instruction is called and what its result is.
The only problem with some instruction sets occur because of bugs in the hardware (or sometimes in the firmware). You can even run DOS on todays computers, as long as DOS doesn't have any problems with the amount of memory or something else (like drivers). In case of software compatibility the OS of the new console would only restrict e.g. the memory of the game (if even this is needed). But as I wrote before, the GPU could be a problem, if there is no software abstraction between the game and the gpu.

And that point with the WiiU cpu, might be my mistake, I always thought it was in order in the wii because Nintendo did bring out that it is an ooO architecture in the WiiU. I never thought they would compare that against the CPUs in the xb360/ps3.

Well that's what i'm alluding to. The speed to brute force the code could be there, but who knows if the code was written in a way which would present issues? At what point does additional software need to be made to run the old programs?

But yeah, I get that gpu is the bigger issue.

 

[Shifty Geezer]

Semantics then.

Very important semantics. What constitutes a new CPU? And what constitutes BC? Most of us are considering a CPU as hardware BC when it can run the same code.

Actually here's a much more modern example ; fairly recently I had trouble running crysis on my new computer because it was coded for 32 bit OS's.

That's a middleware software issue, not a CPU issue. I can find only one reference to Jag code not running on Zen and that's a highly optimised benchmark. https://www.techpowerup.com/231536/amd-ryzen-machine-crashes-to-a-sequence-of-fma3-instructions

How many programs that ran on Jaguar based APUs fail to run on Zen PCs?

That's on PC, let alone whatever wonky workarounds developers are able to use on console. I'm going to assume there are more programs that have issues.

You're assuming a lot, which makes for a poor technical discussion, hence me moving this to its own thread. Why are you assuming devs are using to-the-metal CPU code? Is there any evidence supporting that, or are you guessing? Most code is written with high-level development languages. There's very little reason to use low-level CPU code, especially for anything multiplatform. I won't say it's impossible - Naughty Dog might well be using Intrinsics as they are platform exclusive - but it's far from a certainty unless you have reason to think that's the case beyond, "that's how it used to be and things never change so that must be how it is now."

You started it. Don't say I don't want to learn something new and i'm nothing but noise and expect niceties in return.

I'm politely requesting you stop posting that discussion in the technical thread because it's a non-techncial argument. That's my job as a moderator. I've moved the discussion to a new thread so you may continue.

You said "So Wii U had hardware BC with the GC CPU despite being a different CPU because it was the same ISA." Implying that Wii U didn't have all previous extensions and architecture

How is that implied? Why would a new iteration of a processor family not have the previous extensions and features?

Because Zen does not have all the extensions that Jaguar does.

What is it missing? It has a superset of AVX. The difference, the only compatibility issue, is the way FMA is implemented AFAIK, which shouldn't be a problem because the CPU microcode will handle mapping of instructions. For the past ten years, Intel and AMD CPUs have been swapping implementation of FMA...

The incompatibility between Intel's FMA3 and AMD's FMA4 is due to both companies changing plans without coordinating coding details with each other. AMD changed their plans from FMA3 to FMA4 while Intel changed their plans from FMA4 to FMA3 almost at the same time. The history can be summarized as follows:

• August 2007: AMD announces the SSE5 instruction set, which includes 3-operand FMA instructions. A new coding scheme (DREX) is introduced for allowing instructions to have three operands.[6]
• April 2008: Intel announces their AVX and FMA instruction sets, including 4-operand FMA instructions. The coding of these instructions uses the new VEX coding scheme,[7] which is more flexible than AMD's DREX scheme.
• December 2008: Intel changes the specification for their FMA instructions from 4-operand to 3-operand instructions. The VEX coding scheme is still used.[8]
• May 2009: AMD changes the specification of their FMA instructions from the 3-operand DREX form to the 4-operand VEX form, compatible with the April 2008 Intel specification rather than the December 2008 Intel specification.[9]
• October 2011: AMD Bulldozer processor supports FMA4.[10]
• January 2012: AMD announces FMA3 support in future processors codenamed Trinity and Vishera; they are based on the Piledriver architecture.[11]
• May 2012: AMD Piledriver processor supports both FMA3 and FMA4.[10]
• June 2013: Intel Haswell processor supports FMA3.[12]
• February 2017 AMD Ryzen processor officially supports FMA3, but not FMA4 according to the CPUID instruction.[13] There has been confusion regarding whether FMA4 was implemented or not on this processor due to errata in the initial patch to the GNU Binutils package that has since been rectified.[14][15] While the FMA4 instructions seem to work according to some tests, they can also give wrong results.[16] Additionally, the initial Ryzen CPUs could be crashed by a particular sequence of FMA3 instructions. It has since been resolved by an updated CPU microcode.[17]

Every one of these processor families has been functioning correctly with the same x64 code on PC despite mixed FMA3 and FMA4 implementations.

To be absolutely certain hardware is 100% compatible with older software without additional software workarounds, you have to have the same architectural design. It's not that complicated.

No, you don't. You need a CPU that can run the same code with the same timings for perfect compatibility. For perfectly functioning compatibility, you need a CPU that can run the same code without producing errors or different outcomes.

I'm in the same boat, just don't shoot me down because I have different uncertainties.

Where in the past page of discussion did you suggest you weren't right and weren't sure and might be wrong? When did you not state categorically as if your point was right? You opened with an assertion hardware BC (backwards compatibility in hardware) would require Jaguar cores to be present and then made ponits as if it was obvious to anyone who knew anything. It was polite up until this point:

Uh, yeah we do know they all share the same CPU. At least I know. ;-) That's how a modded Wii u can play GameCube games. Because, if it was part emulation than Nintendo wouldnt have accounted for GameCube games and only Wii games would run.

Arrogant assertion that you know the CPU in Espresso, although with a smiley.

Lol of course some developers are using these console CPUs at a very low level unlike pc. It's how it's always been.

Uncorroborated theory preceded with a mocking LOL, as if it's laughably stupid to suggest that devs have moved on from low-level, per CPU optimisations that were essential on limited hardware, to using higher-level coding because it's a lot easier and there's enough CPU flexibility nowadays to make the gains not worth the costs.

But it doesn't matter if the majority of developers arent, with hardware BC you have to account for every possibility. If you don't want Jaguar in next gen, then what you would get is software emulation, or at least partial. And that means they'd have to release games individually like ms. Expecting otherwise is ignorant wishful thinking.

Arrogant assertion that thinking software emulation isn't necessary is "ignorant wishful thinking." That is, and people believing in Zen being able to run the current CPU code for games are ignorant and dreamers. An assertion made without any technical explanation, just some assumptions that devs are hitting the CPUs hard with super-low-level optimisations and Zen can't run the same code. Also some questionable arguments linking to a reference to Zen lacking AVX when it features AVX2, a superset that includes all AVX functionality (which is also compatible with old SSE instructions as I understand it).

Prior to that post, twice I had acknowledged the limits of my knowledge and been open to technical corrections. Your response was derogatory and unintelligent. Hence my lack of patience with continuing the discussion with you in a serious thread that needs arguments to be supported with facts, and contributors to be civil and respectful.

 

[Scott_Arm]

It's almost as if standardized instruction sets like x86 were invented so new CPUs could run old code without recompiling.