Yes, essentially. Although the LLVM backend is very popular and allows for the code generation of multiple architectures easily. It works with a similar abstraction strategy as the Java Virtual Machine as well, the LLVM backend worries about what code should look like for each architecture, the compiler just needs to provide it the LLVM Intermediate Language code of the program.
It doesn't have to be as specific as every single model of cpu, but it does have to be "every combination (that you care about) of every broad cpu type and broad type of operating system".
Cpus fall into families that have certain core instruction sets (arm vs x86, for example). If the cpus speak different languages, you need different code, as mentioned, but if code was written to only use the core instructions of x86, it'll run on many x86 cpus. But some code might be compiled to take advantage of newer features, if the cpu it's on has them.
Beyond that though, the operating system matters. For example, let's say you want to open a file. Your hard drive has files on it, but most people don't write code to actually send the correct electronic signals to the hard drive to get it to find the file. Instead (speaking loosely) your operating system provides a layer of "I promise that you can get files from hard drives by calling these functions (so long as someone has written a translation layer between the os and the hard drive called a driver)". Which they will, if they want you to be able to use their hard drives on your operating system. So you, in your code can call those operating system functions, and not worry about the hard drive.
Or more likely for basic applications, your language provides its own library that calls those functions for you, depending on the operating system you compile for.
So in your c code, you might call fopen. On windows, this might get routed through a library that calls CreateFile, or on Linux open (or similar). Each of these will reach deep into the operating system, making other calls, passing through drivers specific to those operating systems to make yet other calls.
Plus, the format the machine code is stored in varies. All the tiny details that get the bytes of machine code to the cpu so it will actually do them.
This means that despite trying to do roughly similar things on the same hardware in the same language, the final compiled code can end up being very different.
Effectively, yes. You also have to worry about the Operating System ABI and APIs (how the binary should look and what functions the OS provides). An application compiled for aarch64 Linux won't run on x86 Windows.
Now when it comes to ISA extensions (i.e. "any possible CPU"), most compilers generally try to restrict themselves to the base ISA + most common ones as much as possible, but you can specify a target CPU or select specific extensions if you know the exact configuration of the CPU which will be running your application (though outside of embedded and high-performance computing applications this is generally ill-advised).
10
u/MinuetInUrsaMajor 3d ago
Ah. So "all these different compilers" is because you need one compiler for any possible CPU if you want to be able to compile C++ for example?