2

Machine code is the Processor Specific Binary Representation of the Instructions that a program is translated into; lowest level instructions from the processor architecture's instruction set.

The operating system is the agent responsible for passing the (((Binary))) instructions to the processor through the hardware architecture.

the most abstract translation made by translators is, therefore supposed to be the Binary instructions.

The assembler takes in the Assembly code that has instructions with one-to-one correspondence to the processor's architecture instructions ( that have binary representations ), and yields the Object Code.

The yield of the linker is nothing more linked Object Files, no translation happens at this stage. The load module is Object Code. I.e.: The loaded code by OS to RAM is the Object Code (which is not the binary representation of the instructions).

Question 1: Are the binary representations saved in the OS?

Question 2: What's the translator of the object code into binary representations? is it the OS (or the language runtime installed on it, if any)? Do all languages implementations have an installed runtime to do this if it's the runtime's job? Does an earlier agent than the OS do this job?

Question 3: Is the loaded code to the RAM really the object code not the binary representation? or does the loader translate the object code to its binary representation.

Maisara Abou-Rady
  • 43
  • 5
  • Why do you think object files don't contain the binary machine code? In other words, what is this "object code" and how do you think it's different from "binary instructions"? –  Jul 10 '14 at 16:10
  • what do you call "saved in the OS"? – Deleted User Jul 10 '14 at 16:23
  • As far as I understand, object code is not the binary representation, but an intermediate target language that the assembler translate to. – Maisara Abou-Rady Jul 10 '14 at 18:18
  • @Bushmills I mean the mapping of binary representations to object code equivalent encoding of instructions – Maisara Abou-Rady Jul 10 '14 at 18:20
  • sorry, this makes not much sense. I understand the words, but not what you mean. Anyway, understanding that as "saving in the OS" requires a lot of imagination. Say you store on a USB thumb drive - would that be saving in the OS or not? – Deleted User Jul 10 '14 at 18:28
  • 2
    This is not a programming question. – Raymond Chen Jul 10 '14 at 20:18

1 Answers1

4

You are misunderstanding object files. Start by taking a look at this question:

What does an object file contain?

Object files do contain binary machine language instructions for the target platform, so there is no "translator" of any kind between the binary code contained in them and what is executed on the target CPU.

I think your confusion stems from the fact that object files also contain other information, such as symbol tables and constants. It is the linker's job to collect all of this information and package it into an executable.

Side Note: This answer is assuming a C/C++ perspective. Languages like Java that execute on a virtual machine have other layers in between compiling and execution.

Community
  • 1
  • 1
skrrgwasme
  • 9,358
  • 11
  • 54
  • 84
  • Does the same thing hold for Bytecode? Are they analogous? (I understand the Bytecode is directly executed in a VM, not the CPU). Is the VM either an interpreter or a JIT compiler or it's just an interpreter? If it's an interpreter, why do they tend to use interpretation despite its numerous disadvantages, especially upon execution? Can I consider the bytecode and the object code as "Formatted Binary Representations", where the object code is readable by the CPU, while the Bytecode is readable by the VM? why do we need Binary Representation Byte code if we're going to execute over a VM? – Maisara Abou-Rady Jul 11 '14 at 01:25
  • Can't we just preserve the same advantages by creating a compatible VM to a more readable version, just like assembly for example? Thank you very very much and sorry for AAAAALL of this :) . – Maisara Abou-Rady Jul 11 '14 at 01:26
  • @MaisaraAbou-Rady - No, there is a huge difference between `Byte Code` and `Object Code`. To start off, Object Code is system specific, Byte Code is *not* system specific. The JVM is System / Platform dependent. Check this : http://stackoverflow.com/questions/2748910/how-is-java-platform-independent-when-it-needs-a-jvm-to-run – TheLostMind Jul 11 '14 at 07:19
  • @LostMind I get this difference. I'm talking from the perspective that both of them are the final yield of compliers (i.e.: should be binary representations of instructions), I understand that Bytecode is formatted for JVM to interpret, or use a JIT to compile it, and the object is formatted for the processor to execute. I believe that the JIT or the VM interpretter just translate the Bytecode from the formatted binary to the processor sspecific format. Am I right? – Maisara Abou-Rady Jul 11 '14 at 08:53
  • @MaisaraAbou-Rady You are correct in your most recent comment. As to your earlier question about why we would use the byte-code at all, there are two good reasons I can think of off the top of my head: 1) compiled code will (almost always) execute faster than interpreted code 2) Java byte-code can be distributed without exposing the source code, as opposed to distributing something like Python scripts as a platform-independent solution – skrrgwasme Jul 11 '14 at 15:48