What is the difference between object code and intermediate code?

Question

In this question a user answered that the object code is different from intermediate code.

Since most courses say that the object code is in the middle of the process, then we could not call it intermediate code? So what’s the difference?

Answer 1

Intermediate code can have several forms, including a source, while object code is usually machine code. It’s not that the object can’t be a source, but it’s not usually.

Intermediate code is an easier way for the compiler to work. The source code follows the rules of the language, which may not be easy for the compiler to handle, so he compiles the source of the language for a language of his, which is intermediate because it is not the final code that is the machine code. Most complex compilers, who intend to do optimization or create certain Features has it, otherwise the result will be inferior or it will be very difficult to work with it internally.

The subject is a little complicated because it depends a little on the context.

Two-stage compilation

For example, the intermediate code that the C# compiler generates is the CIL (plus) and ends up in a binary format and is sent as part of the executable. In a way that’s an intermediate code and it’s in a code that’s a little bit of an object, but it’s encapsulated in an executable. So it is difficult to define these things well. What is certain is that this CIL is not the executable machine code, it will only occur after you have a Jitting (in most CLR implementations).

Something similar occurs with other languages java-like and others of script that people say it’s interpreted, but it was compiled before. In general all these languages generate an intermediate code called bytecode (didn’t find link from here to post #ficaadica). That bytecode, is not the source of the language and is not the machine code. In general it is not a text, it is a binary, it is a form of Assembly that is written as machine code on a virtual platform, unlike the actual machine code that is for a processor that will actually run.

Some of these bytecodes will be Jittados and others will be "interpreted". I will not go into detail here.

Internal use of compilers

But it’s very common for compilers to use an intermediate code that’s not even exposed outside of it, it’s just for his use, so he doesn’t even (sometimes can) record it somewhere.

For example Rust says it improved compiler speed when it came to adopting intermediate code instead of doing everything in the original code. I don’t know if it’s true, it’s still very slow. It has two intermediate code because the backend is the LLVM.

This may be more useful because you separate the compiler into two parts. A frontend which takes the source of the program to be compiled and creates an intermediate code. And a backend that takes this intermediate code and generates the machine code for the target platform. Without this it would have to do everything together and gets complicated.

There’s software that’s just backends then the only way to use them is through an IR, as is the case of the LLVM.

GCC has some Irs of its own and may generate from third parties such as the LLVM.

The GO is the intermediate representation of a code, which is a generic term to talk about what the intermediate code will be.

Completion

I don’t think object code is intermediate, it’s different contexts, and object code being machine code is definitely not intermediate.

You cannot confuse the term code in these two cases. The intermediate code is a language, the object code is a final product. But in fact it is the kind of thing that gives room for interpretation. They are different functions.

Most of these things are only useful to those who are dealing with compilers and tools connected or do much more advanced things. I think everyone should learn these things to be better, but not fundamental. A pilot does not need to understand mechanics, but he will be better if he understands.