Thread: Programming Approach

Hi gentlemen, I'm learning my programming language bymuself (solo) and once I'm writing a code, I really concern alot on the hardware and how the compiler convert my code to the PC, for example i'M STRUGGLING like this problem, once we do IN c programming int x=526; so how that value which is like "intact" value enter into my x/assign to my x?! how is really intact values entered into variable "x" , in real life it's reasonable, but how PC doing that taking intact values like human's thinking and assigns it into x ?! like this problem I'm struggling alot!


So, to sum up, should I as a programmer concern about hardware? or just take things/language code as something implicitly concept? I mean with implicitly concept, it's implicitly working as this ... and as programmer need to just understand the concept.



Am I right?

I think to be concerned about how things work behind the scenes is always a healthy approach to learning...

First, you can ask yourself "what is a variable"? When you declare int x; in C you are telling the compiler to reserve space (usually, in memory, but not always!) to accommodate an signed 32 bits integer value and label this reserved memory as 'x'. Depending where your declaration is (global or local) this reservation can be done in the "heap" (data section of your binary code) or in the stack. There is a third option, but I'll leave this for later.

When you do int x = 526;, there is 2 things done here: You are declaring this reserved space to be called 'x' and initializing with the literal value 526. In assembly (x86) this could be expressed as:

Code:

mov dword [x],526

Where 'x' is the label of the reserved memory:

Code:

section .data
x:  dd  ?

Your linker will assign the appropriate memory address to this label 'x'.

This seems to be very easy, but it is interesting to know if you are dealing with pointers, for exemple:

Code:

int *p;

In this case, the reserved space has length equal to the processor's address space (32 bits for i386, 64 for x86-64, for exemple). The label is 'p' (not '*p'!):

Code:

section .data
p:  dq  ?   ; quadword for x86-64

If you do:

Code:

p = &x;

Then you'll end up with instructions like:

Code:

lea rax,[x]  ; Load Effective Address of x into rax
mov [p],rax  ; Write RAX to memory linked to p

Since 'p' was declared as a pointer, it holds an address. When using the indirection operator *, as in:

Code:

*p = 1;

The compiler probably will create:

Code:

mov rbx,[p]  ; get the address inside p.
mov dword [rbx],1 ; write 1 to this address.

My point: knowing how your processor works and how your compiler will, probably, create code, helps when you are creating your routines in C.

Well... that's my opinion anyways...

That would have been a good answer - 4 years ago.

It takes a lot of concentration to keep up with billions of instructions executing per second