0

With the mov rax, [rsi] instruction, can the address of rsi point to the L1 cache? Or, when evaluating this instruction, is it possible for the L1 cache hit to fail and point back to the L2 cache?

initprism
  • 33
  • 3
  • 1
    Addresses don't refer to cache, but the cpu may transparently cache any address in a cacheable region. Sure, you may get a L1 miss and an L2 hit, that's why L2 is there after all. – Jester Jan 25 '23 at 19:55
  • An L1 cache *hit* is by definition not a failure, so that load won't need to access any outer levels of cache. Maybe you meant to say an L1 cache *access* might *not hit*, i.e. miss. See also [Why is the size of L1 cache smaller than that of the L2 cache in most of the processors?](https://stackoverflow.com/a/38549736) / [Why do L1 and L2 Cache waste space saving the same data?](https://stackoverflow.com/q/49785750) – Peter Cordes Jan 25 '23 at 22:03

1 Answers1

1

No because the address in the cache is the same as the address in the RAM. Memory is loaded from RAM into the cache, and the CPU loads the value from the cache. When you write to memory, you write it to the cache and then the RAM controller syncs the cache with the RAM. The cache works in the background without you having to know anything about it other than it speeds the CPU up.

When the CPU pushes registers onto the hardware-assisted stack, this memory goes into RAM as CPU words, which does end up in the stack frame, but there is no determinate cross-platform way that you can calculate exactly where it would be in memory.

Cale McCollough
  • 95
  • 1
  • 9
  • So, it's designed in a manner so that the code being executed functions the same whether the CPU supports caching or not, making it an "invisible" layer over the CPU. Right? – puppydrum64 Jan 26 '23 at 14:24
  • Yes, that is correct. The CPU works behind the scenes without you having to know anything about it other than it speeds everything up. – Cale McCollough Jan 26 '23 at 15:08
  • The first paragraph is the answer, that cache is transparent, it's not addressable on its own. The second paragraph about `push` seems totally off-topic. The stack is part of memory; `push rax` is like `sub rsp,8` / `mov [rsp], rax` but without affecting FLAGS. There's no magic, it's just a pointer in a register that's used implicitly. A function shouldn't assume anything about where RSP will be pointing on entry to the function, but either way this has *nothing* to do with cache. That paragraph is the main reason I didn't upvote this answer. – Peter Cordes Jan 26 '23 at 15:14