Operational instructions on PC.

Hi,
there's something a lily confused me of how it's working when the PC getting an operation from an instruction, for instance and to be easy when I say to the compiler int y=z+x (assuming that z and x already defined ); my question is, the processor gets that operation and analogy say, well now I have the "y=z+x", I will put "breakpoint/note" to get back to "z+x", because now I'm going to where the data of x, after wards going to the data of z (or going opposite-doesn't matter) ; and then I will back to where I have put the breakpoint, i.e to y=z+x , now I can Add ! ; that's actually what I'm thinking that PC done, but is it really what he's doing? or am I missing something more significant?!


thanks for your cooperative

It's up to the compiler to generate instructions to perform the operation. There's a handful of different ways a processor can do a simple operation like add two variables and save the result in another variable (depending on where the variables are stored--on a stack frame, globally, or in registers, which also depends on compiler optimizations and so on), and different processors work differently, but let's look at one theoretical method:

1. Load variable "z" into register 1.
2. Add variable "x" to register 1.
3. Store register 1 into variable "y".

Another processor might have an "add" instruction that can do all three steps at once:

1. Add variable "z" and variable "x" and store the result in variable "y".

Yet another processor might have to load all variables into registers before it can add anything:

1. Load variable "z" into register 1.
2. Load variable "x" into register 2.
3. Add register 2 to register 1.
4. Store register 1 into variable "y".

Exactly what happens depends on many factors (as I mentioned above). You should be able to tell your compiler to generate assembly code as output that you can look at to see exactly what your compiler generates. Here's how to make gcc do it:

Code:

---

gcc -S source.c

---

That will generate assembly code in "source.s".

Here's an example source file:

Code:

---

int add(int x, int z) { int y = x + z; return y; }

---

If I compile that with "gcc -O -S source.c", I get the following assembly code on Arm:

Code:

---

add:
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 0, uses_anonymous_args = 0
        @ link register save eliminated.
        add    r0, r0, r1
        bx      lr

---

and on x86:

Code:

---

add:
.LFB0:
        .cfi_startproc
        movl    8(%esp), %eax
        addl    4(%esp), %eax
        ret
        .cfi_endproc
.LFE0:

---

Apparently, gcc for Arm passes function arguments in registers r0 and r1 and returns the result in register r0. It can add those registers directly.

On x86, gcc passes function arguments on the stack and returns the result in %eax. The function has to load the first argument from the stack into register %eax, add the second argument from the stack to the same register, and return the result in that same register.

This is only one example. Different contexts (and different compilers/processors) will give different results.

Quote:

---

Originally Posted by christop

Here's an example source file:

Code:

---

int add(int x, int z) { int y = x + z; return y; }

---

If I compile that with "gcc -O -S source.c", I get the following assembly code on Arm:

Code:

---

add:
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 0, uses_anonymous_args = 0
        @ link register save eliminated.
        add    r0, r0, r1
        bx      lr

---

and on x86:

Code:

---

add:
.LFB0:
        .cfi_startproc
        movl    8(%esp), %eax
        addl    4(%esp), %eax
        ret
        .cfi_endproc
.LFE0:

---

Apparently, gcc for Arm passes function arguments in registers r0 and r1 and returns the result in register r0. It can add those registers directly.

On x86, gcc passes function arguments on the stack and returns the result in %eax. The function has to load the first argument from the stack into register %eax, add the second argument from the stack to the same register, and return the result in that same register.

This is only one example. Different contexts (and different compilers/processors) will give different results.

---

Thanks alot; appreciate your cooperative