3

my question is: When I have something like this:

lea rax, rbp - 8

// Maybe that's an int on my stack, because I have a local "int"-variable in my code. How does the CPU know, where the data is, when I do this:

mov qword [rax], 14

I mean, it's just an address... What if I had reserved memory at 2^64 - x ?

Cant your allocated memory have this kind of address?

Or what if the stack grew until it has the same addresses as your allocated memory?

Does that happen?

The Assembler doesn't know what the number in rax is, so it can't be a MOVstack and a MOVheap, like with near and far JMPs.

trincot
  • 317,000
  • 35
  • 244
  • 286
Banyoghurt
  • 195
  • 11
  • 2
    stack and heap are concepts that are above the instruction set. the instruction set reads and writes memory addresses in the registers given, the addresses mean something to the program, but dont meany anything to the hardware. you can use the stack pointer to read heap and a gpr to read stack, hardware doesnt and wont care. – old_timer Nov 13 '12 at 20:28
  • 1
    Thank you, it's these silly things that hold you up all night... – Banyoghurt Nov 13 '12 at 21:12

1 Answers1

6

How does the CPU know, where the data is, when I do this mov qword [rax], 14

Why would the CPU need to know whether the data is on the stack or or heap ? both are in the same place, the RAM.

I mean, it's just an address... What if I had reserved memory at 2^64

You won't be able to reserve memory there if the address is bigger than your address space.

Or what if the stack grew until it has the same addresses as your allocated memory ? Does that happen?

Yes it happens, it's called a stackoverflow :) and will most likely result in a segmentation fault.

The Assembler doesn't know what the number in rax is, so it can't be a MOVstack and a MOVheap

As far as I know, there are no separate instructions for accessing the stack or the heap, like I said, the stack and heap both exist in the RAM. All the CPU cares about is the address to write to or read from, however, on some architectures, those that don't have a memory-mapped I/O there are special instructions for accessing I/O registers, most architectures see I/O as just another memory address.

You should read a book about computer architecture, I recommend this one Computer Organization and Design, 4th Ed by Patterson.

iabdalkader
  • 17,009
  • 4
  • 47
  • 74
  • The CPU doesn't directly access RAM, or does it? I thought it all went through the MTU, i was thinking about the virtual address space, but then again, i didn't say that in the question... But does that mean that the stack is limited in size? – Banyoghurt Nov 13 '12 at 21:12
  • @user1821933 it depends on the architecture, it could access ram directly or through cache it could use direct access or DMA. – iabdalkader Nov 13 '12 at 21:16
  • 2
    @user1821933 you probably mean the MMU, not every CPU has one, some don't even have caches or need external memory (MCUs), in this case the CPU can transfer from memory directly or through DMA, either way, the stack vs. heap thing is not relevant, and yes the stack size is limited, RAM is finite :) – iabdalkader Nov 13 '12 at 21:27
  • memory has layers, deep down in the processor there is a ram interface, then you get mmus and caches and memory controllers, peripherals, etc that spread the access of the processor out. at the instruction level (on this architecture) a memory access is a memory access. use the specified address and perform the read or write using the size specified and put or get the value where instructed. – old_timer Nov 13 '12 at 21:47
  • 1
    at the instruction level the ram address does not have to make sense, you can easily tell the processor to access an address that does not have a perhipheral or memory mapped the assembler should accept that address and properly encode the instruction, the processor should properly initiate the instruction, what happens from there whether the fault directly affects execution or happens after execution of that instruction is architecture dependent. – old_timer Nov 13 '12 at 21:49
  • 2
    it is important to separate things into their proper place. .data, .text, etc, stack vs heap, signed vs unsigned addition and subtraction, characters vs bytes, these are all programming concepts that do not directly relate to the hardware. there are stack pointers and stack pointer instructions, but that has nothing to do with the actual memory there or who has arbitrarily defined one byte to be in the stack another byte to be in the heap and another to be .text, etc. also separate the processor and its instruction set from its peripherals including mmu, etc. – old_timer Nov 13 '12 at 21:52