eli5: What does people mean when they say that a computer system runs on different architecture from another computer? Like when somebody says that an emulator can run N64 games faster theoretically but because of different architecture in practicality it cant?

149 views
0

eli5: What does people mean when they say that a computer system runs on different architecture from another computer? Like when somebody says that an emulator can run N64 games faster theoretically but because of different architecture in practicality it cant?

In: Technology

Processors each have their own language. In technical terms it’s what’s called an “Instruction Set Architecture”. It defines the words that that a computer uses to do things. For instance one computer might have use “ADD 2 2” to compute 2+2. While another computer might use “SUM 2 2”. When someone writes a piece of software like a video game, it gets compiled for a specific instruction set architecture based on the platform it’s going to be used on. When a program is compiled, it gets turned from the programming language (C/C++ for instance) into the language of the processor. You might hear this called “machine language”. So code that’s been compiled for one processor type can’t run in a different processor because the machines use different languages.

Another way to think of it is you want to tell someone hello. You could chose to say it in either Russian or English. If you say it in Russian, the English speakers won’t understand it, but if you say it in English, the Russian speakers won’t understand it. Your choice of language is like compiling the software.

If you are emulating a cpu that has similar cpu instruction set and functionality as a modern computer then at worst you just map the game instruction to a modern cpu instruction. Some of the late 90s consoles had weird chips and weird ways of communicating between them. Just means you have times where too much happens at once to do all the processes necessary to simulate the state of the chips faithfully.

Jon burton that lead sonic the hedgehog game development at one point has some awesome videos explaining some of the weird hardware they had to support in the 90s.
https://youtube.com/c/GameHut

To really get down to five year old level: the actual hardware, the computer chips inside the game consoles, is different. It’s designed different, it uses different codes, and it behaves different. Some of those “cpu architecture” terminologies are ARM, x86, x64, PowerPC, MIPS, RISC, and more.

Less five-year-old stuff:

The same programmed source code may sometimes be capable of working on multiple architectures, but once it’s compiled for a certain one it’s quite hard to decompile or recompile it for another without having access to the source code (which is usually something companies keep closely guarded.) Also it often takes a lot of work to write code that runs well without bugs on different architectures: for example x86 is a “32 bit” architecture which means that 4,294,967,295 (about four billion) is the largest number that that architecture can easily handle without lots of ugly workarounds. (If you tell a 32-bit computer to do 4294967295+1 it’ll say the answer is 0, and if you tell it to do 0-1 it’ll say the answer is 4294967295… unless you have negative numbers turned on but I won’t go into that right now.) A 64-bit architecture like x64 however can handle numbers as big as 18,446,744,073,709,551,615 (18 quintillion or 18 million billions) so a lot more math and detail can be handled. In other words, architecture matters and newer architectures help games look good and be fast.

One other big reason 64 bit architecture is increasingly popular is because programmers like to store dates and times as the number of seconds before or since January 1, 1970 GMT. (It can be negative to easily talk about dates before then too.) But as of this writing, it’s been 1,613,808,415 seconds since 1970. Since it can also be negative, that cuts our available numbers in half, to 2,147,483,647. So we only have 533,675,232 seconds left until we run out, which is just under seventeen years from now. This is called the “year 2038 problem,” much like Y2K, so we’ve got until then to upgrade or patch every single digital device that cares about what year it is. Fortunately with 64 bits, we can count up seconds for the next 292 billion years, so we shouldn’t have to worry about that anymore.

I’ll expand on the language metaphor that others have used. An “architecture” determines how the hardware works at a very basic level. It’s the language that the computer thinks in.

When you emulate another kind of computer, there’s basically one level of indirection going on. The emulator is creating a digital version of a different computer, for example a nintendo 64, that has to have all the different hardware of that computer in digital form. The languages that the two computers think in might not have a 1-1 mapping for words though. If I translate english to spanish, I can’t just go word by word. I have to consider the different grammar and adjust accordingly. That translation process takes time. Similarly, the digital hardware being emulated has to actually be running on the physical hardware of your actual computer. So the instructions are essentially being interpreted twice. First, they are interpreted by the emulated computer, and then translated to your computers language after.

Consider different architectures as different creatures. One (let say it is A-creature) with strong 6 legs and strong 2 arms, specialized to live in forests and climb trees, another one (B-creature) with 2 legs and 8 arms, specialized to live in flatlands. Consider a game is a dance. If a dance invented in B-creatures tribe and is performed heels over head, A-creature may perform this dance, but it will be slower and a bit clumsy, than if this dance will be performed by a B-creature.

Hmmm.

Architecture is basically how that computer runs at the most basic level.

All a computer is, is a bunch of really high tech light switches, on and off. Where it gets complicated is to figure out how they should be flipped and how to convert that into lets say a document, or a picture, or even a fully functioning video game.

So to do that we have to give the computer instructions. We would call that a program or a programming language. The catch is, it’s really freaking hard to actually tell the computer which switches to flip exactly when. What we do instead is tell it on a more human understandable level what we’d like it to do (do some addition here, print a message here.) When we write those instructions for the actual game, the computer then converts it into what is called machine language, which is basically telling it what switches to flip when.

Now here’s the catch. In the same way that every car and vacuum cleaner brand are different, so is every model of computer. And in the case of computers, it REALLY effects what order the switches will be flipped in.

In some cases, it can be a big enough difference that you can’t get old programs to run on new computers.

Now this is really a bigger problem with older programs running on newer things, because they were written for older computers which ran on older computer parts that used different machine language. So when we update them for new computers, even though the human readable part of the code works, when it gets translated to the machine code, the newer computer is essentially speaking a completely different language and can’t understand the program. So to get it to work we have to make significant and difficult changes to either the program that emulates the software or the software (game) itself. Most people, unless they are the original company who owned the game, don’t have access to the human readable code, because companies only sell the games in machine readable form to protect their product from pirates and other reasons. So when you’re emulating an old game and it’s not working because of the system architecture, it can be a really difficult problem to solve, because you don’t always know exactly what part of the program is causing the issue

There are two levels of architecture: The Set of instructions that a processor can understand, and the micro-architecture (the implementation of those instructions, how the circuit is wired)

The set of instructions, for a 32 bit processor, would be a list of binary numbers with 32 digits. Using the RISC-V as an example: The first 7 bits select the format of operation, and depending of the format, the other bits will select an operation (e.g. add, subtract, jump, branch, shift, etc), the memory address where are stored the operands, and where the result should be stored, etc. (That’s what is machine code)

The micro-architecture is how everything is wired so that if you send that if you input the instructions of a certain architecture, the output will be correct (think of it like a calculator. If you type in any calculator “2 + 2 = “, the output will be 4, but how the calculator is wired changes between calculators.

So, when people say that a computer runs on a different architecture, it generally means the machine code that a processor A understands is different from processor B. But in the case of the N64 emulation the rabbit hole goes furher. The issue isn’t with the instruction set (actually, the MIPS is quite light to emulate), but with the separate chip that deals with graphics and audio (RSP). Some games had a microcode that changed the configuration of that chip, to optimize the graphic rendering (and those are the games that people have more headache to emulate). Also, for a long time, the development of n64 emulation was really messy.

It’s like building a car out of Duplo blocks or Lego blocks. They are both cars made from similar blocks but are entirely incompatible.

Also extremely simply put, N64 for example was speaking japanese, your current intel PC is speaking american english, AMD is speaking british english, most android phone chips are speaking scottish, apple chips are speaking a specific dialect of irish, etc.

To run a program that was built for the N64 on an intel PC, you need something (emulator) to interpret from japanese to american english on the fly. It is not very efficient, but it can be done.
Same if you make a phone app that you want to run on a PC. You need something to emulate a phone environment for the app to be able to run.

There are also other factors. For example the N64 was like an old japanese man, speaking slowly, and the games were based on that speed.
New PCs are speaking like super fast on crack english, and they can translate japanese to english very fast, but the game isn’t built to be read and show that fast, so it basically slows things down on the emulator in order to time things as they were on the N64. And with that, it also slows down the translation.

You can in theory translate the game and then show it on the time it needs to, but it makes emulators much harder and difficult to make, so they are rarely being made like that.

Computers are like houses and software is like the people living in them. Different houses have different layouts and architecture. There is not one right architecture for a house so there can be many choices and personal preferences. The people are like the software and depending on the people’s lifestyle some architecture may be better for them than others — some people may not do well with stairs, and you would not be happy living in a house with stair – you would not be able to move around the house very fast. However if you are a family with lot of kids you would like the upstairs where you can send the kids so you cannot hear them and get some quiet time to yourself downstairs. Different people like different architecture. Software and Hardware the same – and if you hardware have lots of stairs, narrow hallways or no windows, your software may not be able to live there very well, even if theoretically it should be fine

Computers process instructions, which means they receive instructions from us, then memorise and execute them (or vice-versa). The term “architecture” refers to unique method in which the computer receives, remembers and executes these instructions.

If you think of the architecture like an assembly line in a factory, the instructions are the binary signals (1s and 0s) that pass through the assembly line, the configuration of 1s and 0s will also specify what part of the assembly line these instructions need to go to in order for the system to trigger the correct output, thus fulfilling the instruction.

Some assembly lines/architectures are more efficient than others, maybe their paths are shorter, maybe they need fewer 1s and 0s to relay the same instructions, maybe their instructions use values between 1 and 0 thus allowing them to expand the amount of instructions given per cluster of 1s and 0s.

ELI5 here:

Imagine that one system is built with rails, so, this system can only support trains, you can try to run a car or a bike on it but it won’t be good, the trip I’ll be full of bumps, crashes and you might need to stop before the destination.

We have another system that’s built with asphalt, it is a bit more versatile, can run cars, trucks and bikes, but you can’t run trains on it.

We have also another system, built with water, but this can run only boats, ships and submarines, it just can’t run trains or cars.

It’s pretty much the same with computers (and video games) they are built to calculate stuff in one specific way, whatever you want to run on it, you need it to be compatible.

When you were a kid you probably played with some “construction” toys, such as Lego, K’nex or Meccano. The idea of the toys is that you have some basic parts that you can combine to build something, like a small vehicle. You can make whatever you like, so long as you can build it with the parts you have and some kind of blueprint to follow.

Now, let’s say you have a blueprint for a Lego model helicopter, but you and your friends only have K’nex. The Lego blueprint is mostly worthless, but you *could* design something that looks very similar and has the same functioning spinning blade. In order to do this, you need to know how lego works and probably be pretty good with K’nex too, there’s no simple way to convert the blueprint. The result might be pretty good, but sometimes, some parts just won’t be the same because it’s physically not possible. You also need to design and print the new blueprints and instructions for your friends, which takes a lot of time.

This would be called “porting” the blueprint, it’s tedious and you need to do it once per blueprint you want to play with. Hopefully, at the end of the day, you can throw the old Lego blueprint away and everyone can use the new K’nex blueprint to this helicopter without needing the Lego.

However, when I said there was no simple way, I lied. What you could also do instead is to figure out how to *build Lego bricks out of K’nex*.

Think about it, if you came up with a K’nex blueprint for all of the basic Lego bricks, then you’d be able to build *any* Lego blueprint without needing to port it. Genius! You just need to build the bricks you need from K’nex and then fit them together according to the Lego blueprint directly.

However, there’s a huge drawback, you need a *lot* more K’nex than you needed lego and therefore it takes a *lot* longer to build. The same would also be true if you were to try the process in reverse: converting K’nex blueprints to Lego by building K’nex pieces out of Lego bricks. This is an unavoidable problem with the method: emulating one “architecture” in another by simulating the smallest parts is a very easy way to accurately cover all blueprints, but it is also very inefficient. You may be able to take shortcuts that let you use a lot fewer pieces, sacrificing the ability to accurately build some models, but it’s still not anywhere near as fast.

For the sake of this analogy though, you need to assume that kids are now thousands of times faster at building stuff than they were before but that the process of porting blueprints manually is *very* difficult.

Glossary:

* Kids with their K’nex/Lego: gamers with computers.
* Blueprints: games.
* Building a blueprint: running a game.
* K’nex/Lego: architecture.
* Blueprints for Lego blocks in K’nex: emulator.

A lot of good responses on what people mean by architecture on a general level.

But a more specific level, why N64 emulation is so hard is down to simple hardware. The N64 had a special GPU, the “[Reality Coprocessor](https://en.wikipedia.org/wiki/Nintendo_64_technical_specifications#Reality_coprocessor)” which was like a dual core processor for graphics. No one makes a dual core GPU, it’s not necessary for anything other than the N64 specific architecture. It being basically a two core meant that it could do 2 tasks at once and send the results of both at the same time for the console to display it in game, whereas a single core GPU like in a Retropie or your PC can only do one task at a time, sure it can do each task 10 times faster, but it still can not spit out the two tasks simultaneously, which means there’s a delay in the result. That’s why emulated N64 games come out all choppy.

Think of it like this…

The engine drives your car, but each manufacturer has their own engine design.

So you can take a Dodge Viper engine and put it in a PT Cruiser because they’re the same manufacturer:

https://www.carscoops.com/2011/06/viper-v10-powered-chrysler-pt-10/

While it’s technically possible to put a Ford engine in a Chevrolet, it’s a lot harder and requires re-routing and re-engineering.

So computer code designed to run on a particular kind of chip may require extensive re-working to work on a different class of chip.

This is why PS4 games can run on the PS5, they have chips of a similar class, but PS3 games cannot, the Cell processor is too different from the later machines.

Saying architecture is a different language is oversimplifying things. This analogy is better suited for explaining why programming languages like pascal and c++ are different.

Computer architecture is *physically* different from one computer to the next.

In order emulate one architecture to the next you have to redo how information is managed.

It’s called *architecture* for a reason. So a more accurate analogy would be like this:

Say you live in a small house from the 1940’s. In order to function and live in that house you know where everything is and how everything works: the bedroom to sleep, the bathroom for hygiene, the kitchen to eat, etc. And all of the equipment in those rooms you know how to use.

Now time travel to a mansion in the distant future. You have no idea where the bathroom, kitchen, etc is. All the equipment is totally different – everything is touch screen and people sleep in hyperbaric chambers!

You are totally lost and cannot function. Someone needs to explain to you where everything is and how everything works, because the *architecture* is different.

You could theoretically make sushi in a McDonald’s kitchen, but you wouldn’t be doing it very effiencely, you also couldn’t use most of that kitchen for the task it hand. It is ill suited to the task at hand. The kitchen is the processor and the cook is going to be attempting to be an adapter between the kitchen and the unusual request for it. Your sushi might not be quite what you hoped but it’ll probably work out. If you improve the cook a bit your results will be better and better but it’ll always smell faintly of fries and probably bleed some rice into the burgers now and then. Its not a good way to run, but it’ll probably be the best you can get if McDonald’s is all you’ve got.

The PC is speaking english. The N64 was written in spanish. The PC has more brain power of the N64 but it has to waste a bunch of time translating from spanish to english so it’s slower. (Languages are for example, they’re not actually in English or spanish)

Like you are five: different computer chips have different architectures, which are like different languages. At the most basic level, a x64 architecture might look like English, but an ARM architecture might look like Spanish, and a SPARC might look like Russian. The alphabets might be similar, but they have different meaning. One word in one architecture would be a completely different meaning on another (“gris” is Spanish is gray, but “gris” is Swedish is pig). In order to make a program for one architecture work on another, you have to run it through a translation first (an emulator) to make sure that not only to individual words (operarions) translate properly, but entire sentences or novels (applications).

If the host computer looks enough like the client being emulated, it theoretically could be faster (for example, x64 is a descendant of x86, and can run x86 programs natively, but an ARM cannot run x86 without a translation layer).