How come the CPU register values shown in Visual Studio Debugger don't change when I use another program (eg. Windows Calculator)

0
votes

I'm learning assembly and some low-level computing stuff as a fun learning exercise. If VS Studio is showing me all my CPU's available registers in Debug > Registers, then how come when I do calculations on my computer, outside of the program I'm debugging in VS Studio, then the data shown in the registers doesn't change? Am I correct in assuming that registers are needed for any sort of calculation or operation done by the computer? Is VS Studio then only emulating my CPU's registers, and if not, then what's really going on?

1
visual-studioassemblyhardwarecpu-registershardware-programming
When the process is suspended, its CPU state is flushed to memory, and the CPU core is released to do something else. VS is actually showing you the values of those memory locations, where the CPU state was saved. Upon resuming the process, e.g. for single stepping, it will reload the CPU state from memory and resume execution until the next breakpoint, which suspends it again. – Erik Eidt
VS will let you change the register values for the suspended process. When you do that, it actually changes those memory locations, from where the CPU will reload the registers from. – Erik Eidt
Turns out we can't actually see the CPU registers, without sophisticated hardware debuggers and/or simulators. On suspension, the CPU flushes its own registers to memory (and restores them from memory on resumption), and that's how we can see them and edit them. – Erik Eidt
Thank you, really good to know – eyeseaevan

1 Answers

2
votes

You only see the registers for the current thread. When Windows changes context to another thread or process, or handles an interrupt, the current registers are saved, and the registers of the thread being switched to are restored. So the registers in your thread are not affected by running other programs (with exceptions of debugger type programs).

In addition each process has it's on virtual address space. It is possible for a multi-process program to setup a shared physical memory space between the processes, but each process may be using a different virtual address for the same shared physical memory.

Certain types of I/O controllers need to use physical memory for transfers. The virtual memory is locked, then translated into a list of physical addresses and lengths, corresponding to the 4096 byte pages used for virtual memory. Once the I/O is completed, the virtual memory is unlocked.

https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/using-mdls