No More Guessing About BC With The Scorpio!!

I've noticed that about him, he posts pages and pages of convoluted technical jargon and just the way he lays it out as responses to simple things people say it seems like he's trying to brute force his way out of a discussion knowing most if not all people will have no way to contest his posts even if it's completely wrong.

@Heil68: I've always wondered, why save/keep your games but not the console?

I still have the console too. It the white starwars one with gold controller. I know they dont go for much these days, but its a cool console.

I thought this was a given...

What's wrong with my post?

The word "translation" is meaningless e.g. JIT re-complier is one of many fast software method for translating non-native app into the target machine's instruction set.

Modern X86 CPUs has hardware based translators/decoders with trace cache which works like JIT-complier cache i.e. cached translated instructions as zero level cache.

Transmeta CPU has firmware (software) level emulator and still considered to be slower than AMD or Intel's hardware solution. Transmeta CPU converts X86 into VLIW via software emulator stored inside the CPU's firmware. Transmeta CPU has another mini-CPU that runs the software emulator. AMD and Intel has similar feature with micro-code fallback hardware i.e. this is use for emulating/translating instructions when hardware has design bugs which minimizes Pentium III 1Ghz style product recalls.

GPUs usually has very thin translators/decoders pipeline stages when compared to modern out-of-order CPUs.

My point, MS should go into the CPU hardware business if they f**king beat Intel on translation/decoder technology.

Due to patent swap with Freescale, AMD is restricted from designing PowerPC compatible CPU.

I'll take on spitfire-six in a debate.

.

The problem with your post is that your not arguing against anyone, I did not say they dont use JIT Recompliation. I asked you specific question and instead of just saying something like "because the other methods dont make sense" so we could start a discussion about it you start putting everything you know about emulation into a single post before you knew what my position even was. That is the problem its like talking to a bot.

Translation layer will be part of the OS for the new console. Saying its meaning less is only to feed your need to talk about the implementation details of the durango emulator. Obviously Xb => Scorpio will use a different method that is NOT emulation of the same magnitude as PPC => x86.

My post's re-complier context is with PowerPC emulation. There's no need for X86 software emulation on higher grade X86 CPU i.e. AMD already provided the X86 hardware decoder with their CPUs. Use your brain.

“We’ve very specifically designed it [on Scorpio] so Xbox games just run,” he said, referring to both Xbox 360 and Xbox One titles. “It’s nothing like Xbox 360 backwards compatibility right now — there’s a lot of technical wizardry involved in that. We didn’t want to have to do that again.”

I am pretty sure you said this quoted below. Which is what lead to me questioning you in the first place. Your suggesting that they must do something to every legacy app for emulation. This is false. The intervention that happens is because the way you must package ERA's on the Xbox One to work with its other services. This emulation happens in two parts its is not a compilation of the original source for the game in order to work with the Xbox One. This was the crux of my problem with your statement. This is what I was trying to clarify with you however you have a problem understanding questions asked to you and you attempt to talk shit while throwing around the information you have. Its not just this post either there are several where you make statements that they must modify or do something to the original source. This could be what you actually believe or it could be your fucked up English.

Legacy applications will run on Scorpio but there will be work that needs to be done to ensure compatibility with the new hardware. So it does not just run by magic its not as much effort as the emulation of 360 games but its not trivial. Regards this is my last post to you.

Apple's Rosetta emulation method doesn't require Apple's intervention for each legacy app. Software emulation can be less complex with higher CPU power.

LOL, Did you know Just-In-Time(JIT) emulators involves re-compilation a block of code in memory? This is similar shit as Windows 10 Red Stone 3 ARM64's JIT X86 emulator.

From https://www.linkedin.com/in/paulhellyar

Principal engineer developing the backward compatibility technology bringing Xbox 360 games to the Xbox One. As the source area expert on Xbox 360, oversee all aspect of the emulator's runtime implementation. Specific areas directly implemented by myself include:

● virtual network device emulation to simulate Xbox 360 NIC device on Xbox One

● all emulator Xbox LIVE connectivity, authentication, and service communication

● virtual secure file-system, file formats, and packaging

● cryptographic services allowing user data to be transferred between real Xbox 360 console and emulated console

● real-time Xbox 360 console gaming system services

● downloadable content (DLC) support

● enable the transfer of digital right on the Xbox 360 to be transferred to the Xbox One

● on Xbox 360, implemented external USB storage support to allow upto 2TB drives to be connect to the console

CPU emulation is only one aspect for emulating Xbox 360 machine e.g. faking a NIC device for Xbox 360.

Xbox 360's PPE is big endian data format. From Ultimate Game Programming with DirectX By Allen Sherrod, Page 270. Early Xbox 360 Dev kits has used PowerPC 970 and this PowerPC CPU has nuked little endian execution mode feature.

Both X86 and GCN are little endian.

Xbox 360 emulator will need to preform a data block convertion from PowerPC's big-endian data format to X86's little endian data format e.g. mass of BSWAP instruction usage http://www.felixcloutier.com/x86/BSWAP.html

IPAdresss converters HostToNetworkOrder and NetworkToHostOrder APIs can be used for endian conversion.

Doing a BSWAP instruction prior to actual ALU instruction execution slows down the emulator (adding clock cycles to the targeted ALU instruction), hence just-in-time re-complier is needed to convert a block of data from PPC's big endian to X86's little endian before actual ALU instruction is executed. When ALU instruction is executed, the data is already in X86's little endian data format, hence minmise slow down.

This is not even factoring PowerPC instruction decoder stage i.e. encounter PowerPC OP code and emulator needs to figure out the X86 version. Simple method use a look up table i.e. For each PPC OP code, look up in X86 version. This is very slow method i.e. excuting ALU instruction with look up table adds clock cycles hence slowing down the emulator. A block of PowerPC instruction stream needs to be mass converted, hence, just-in-time re-complier is required.

I'm interested in a fast CPU emulator without Just-In-Time re-complier. I'm interested in speeding up WinUAE's PowerPC JIT emulator. 68K CPUs are also big-endian data formated CPU which is same issue as PowerPC.

For handling big-endian data conversions, Jaguar has BSWAP and BMOVE instructions.

https://forum.beyond3d.com/threads/xenon-info.14712/

Some additional notes:

Xenon is a big-endian system. Both the CPU and GPU process memory in big-endian mode. Games ported from little-endian systems such as the Xbox or PC need to account for this in their game asset pipeline.

When dealing with big endian data, it's better to mass convert to little endian during loading the data from disc. You can't avoid endian issues between X86 vs PPC.