3
$\begingroup$

I have two questions.

  1. After compilation of any C program result is assembly language code which should depend on processor. So my question is: how do different computers with different processor types, for example Intel i3,i5,i7 etc., are able to run the same software, for example, media-player, browser, etc.?
    (I guess strangely it depends on Operating System) and on that software site they do not ask for processor type.

  2. Do programs interact with any part of operating system for conversion of assembly code to machine code?

Improve this question
$\endgroup$
1
  • 2
    $\begingroup$ If you have two questions, why is there only one post? I recommend you split the two as they are barely related. $\endgroup$
    – Raphael
    Commented Jan 3, 2014 at 6:44

3 Answers 3

Reset to default
9
$\begingroup$

Regarding your first question, the Core i3, Core i5 and Core i7 share the same instruction set, apart for a few marginal instructions. In particular, there is backward compatibility, and so code that works for Core i3 would also work for Core i5 and Core i7 (unless it uses some undocumented behaviours, or specifically tests for the processor version). However, to get superior performance, optimizers need to know the exact target processor, and special instructions should be utilized. This can be handled in at least two ways: (1) crucial functions could have several versions, depending on the processor (either completely different versions or just different optimizing parameters), (2) libraries are used which implement the previous approach.

Regarding your second question, the operating system is usually relied on for handling files, so yes, even an assembler needs to interact with the operating system.

Improve this answer
$\endgroup$
4
  • 4
    $\begingroup$ To clarify, the actual conversion from assembler to machine code is done by the compiler. It doesn't ask the operating system, "How do I translate this piece of code"; it just uses the OS to the same extent that any generic application program would (e.g., for I/O). $\endgroup$
    – David Richerby
    Commented Jan 2, 2014 at 20:33
  • 1
    $\begingroup$ @DavidRicherby: Are you sure that that's true for all optimisations? E.g. OpenMP may try to find out architecture details from the OS to create better code. $\endgroup$
    – Raphael
    Commented Jan 3, 2014 at 6:44
  • 1
    $\begingroup$ @Raphael OK, but that still isn't asking the OS how to translate the code. $\endgroup$
    – David Richerby
    Commented Jan 3, 2014 at 9:31
  • $\begingroup$ @DavidRicherby True, just thought I'd mention it to avoid the impression that compilation was independent of the OS. (In fact, afaik it is usually not.) $\endgroup$
    – Raphael
    Commented Jan 3, 2014 at 9:48
3
$\begingroup$

A compiler and an assembler are both programs that (roughly stated) translate human readable source code (C or assembly language) to machine code (or some code not designed for human consumption). There really is not much of a difference, except for the source language. You might as well call both "compiler".

Compilers for higher level languages (like C) have to figure out what the code is supposed to do, and translate it into a very different language (e.g. machine language for your machine), there is a lot of leeway to do so. For low level languages, like assembly language (which is close to the machine language) there is very little wiggle room, if any.

The resulting machine code is binary representation of the instructions to be executed. This has to be packaged up for other tools to process this in several ways (e.g. to link several separately compiled pieces to create an executable program), and for this apart from the instructions themselves other information is added (addresses inside the code where a function starts, places where an external function is called to patch it's address in, ...). The resulting program file contains the instructions to be executed, but also information needed to control it's placing in memory, where it should start execution, and others. A file containing this is handled by the operating system to load instructions into memory and start running. There are several different such formats. Each operating system uses it's own format. Many such formats are defined so they work for different instruction sets/formats (they aren't intrinsecally machine-dependent), some operating systems (like Linux) are even able to handle several formats (to be able to run e.g. executables for other systems).

Improve this answer
$\endgroup$
1
1
$\begingroup$

1. Ok regarding the first question, nowadays we don't have a separate compiler and assembler they both are bind into one single unit. So we combinely call it as compiler and this compiler is divided into two parts front end and back end(assembler i.e platform dependent). Every machine has its own assembler i.e intel will have its own, motorola will have its own and so on. Now these assembler design depends on the instruction sets of the machines. For example intel may have opcode of "00FC10" for add but any other machine may have different opcode for add so to overcome this problem we have machine specific assembler. Regarding i3,i5 and i7, intel processors are backward compatible i.e anything that you generate for i3 that will definitely run on other high end intel processors. And moreover no organisation would make something which will harm their previous efforts.

2. Now coming to your second question, O.S may or may not be involved in this conversion it all depends on your code that is to be translated. Now if you have more system calls and more of relocation things than O.S will be needed very frequently.

Hope this will help.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.