What do you mean by "Execution Context" here? Do you mean where the result from the operation will go after the instruction?
Black
Similar confusion about Execution Context. Does this refers to the registers set, such as eax, esp, eip? Or it refers to stack, heap of a running process?
maxdecmeridius
After looking online, I found that Execution Context may refer to:
Execution context (or state)
of the program, e.g.,
- Contents of data
registers
- Program counter, stack
pointer
- Memory allocation
- Open file (pointers)
I think the execution context constitutes the register set or memory from where you'll either fetch the operands and/or store the result of the instruction
memebryant
@maxdecmeridius, that's a view from the OS perspective, but this is all going on at the hardware level. I believe @violet has the right idea here.
karima
@maxdecmeridius
Execution context here refers to several processor registers such as: the program counter, stack pointer, general purpose registers, processor status word, and memory management registers. These registers hold the state information that the processor needs to run a given instruction stream.
The results from operations performed by the ALU typically go into the general purpose registers.
But we need more than just a place to put the results of arithmetic operations in order to run an instruction stream. For example, we need a program counter, stack pointer, etc. All these things are stored in registers in the execution context.
@Black
From the processor's perspective, when it writes to and reads from the stack and the heap, it's just writing to and reading from locations in memory. If it wants to read from locations on the stack, it has the stack pointer stored in it's hardware execution context. If it previously stored some data in memory, it has the address of that data either in a register inside its hardware execution context or at some offset from the address stored in its stack pointer. So all the processor needs to know in order to continue running a program is what's stored in it's hardware execution context.
Now when an OS does context switching between processes, it takes all of the state stored in the hardware execution context and stores it somewhere else, like the kernel stack, which is somewhere in memory. This frees up the registers in the hardware execution context to be used by some other process.
vincom2
also, remember that modern processors are fancy and do things like only expose 16 registers at the instruction set level, whereas underneath they may have hundreds of registers and play tricks like register renaming.
skylake
While karima's answer clarifies it awesomely, Professor also mentioned that execution context refers to the entire state needed for a thread to run independent of another thread. Thus the points mentioned by @karima would also apply to threads. In fact, each thread is an independent "instruction stream" and thus most kernels treat a thread as a execution stream and maintain execution state pertaining to each specific thread.
stride16
This is an excellent slide to summarize all that a processor essentially does. First of, it loads the binary instruction from memory and subsequently decodes it. This is represented by the red "Fetch (Decode)" box. Secondly, the ALU or the execution unit executed the decoded instruction (say add, subtract, etc). Subsequently the result of this execution, updates a certain state of the processor, which over here is represented by the Execution context, or the context in which these instructions are executing. More accurately, how @violet points out, it constitutes the register set or memory from where you'll either fetch the operands and/or store the result of the instruction.
cmusam
Summary of what a processor does (thanks @stride16):
fetch/decode: loads/decode instruction from memory
Processor registers include (thanks @karima): program counter (PC), stack pointer, general purpose registers (GPRs), processor status word (PSW), memory management registers.
Allerrors
Execution context is related to context switch in operating system. If there is only one process can be executed from start to end, then there is no need to have execution context. However, if we want to a multi-thread working environment, then operating system needs to record states of every process, which as @karima says. By having these records, OS can easily switch between different process.
What do you mean by "Execution Context" here? Do you mean where the result from the operation will go after the instruction?
Similar confusion about Execution Context. Does this refers to the registers set, such as eax, esp, eip? Or it refers to stack, heap of a running process?
After looking online, I found that Execution Context may refer to:
Execution context (or state) of the program, e.g., - Contents of data registers - Program counter, stack pointer - Memory allocation - Open file (pointers)
from slide 5 of http://www.eecg.toronto.edu/~jacobsen/os/2007s/process.pdf
Can anyone confirm?
I think the execution context constitutes the register set or memory from where you'll either fetch the operands and/or store the result of the instruction
@maxdecmeridius, that's a view from the OS perspective, but this is all going on at the hardware level. I believe @violet has the right idea here.
@maxdecmeridius Execution context here refers to several processor registers such as: the program counter, stack pointer, general purpose registers, processor status word, and memory management registers. These registers hold the state information that the processor needs to run a given instruction stream.
The results from operations performed by the ALU typically go into the general purpose registers. But we need more than just a place to put the results of arithmetic operations in order to run an instruction stream. For example, we need a program counter, stack pointer, etc. All these things are stored in registers in the execution context.
@Black
From the processor's perspective, when it writes to and reads from the stack and the heap, it's just writing to and reading from locations in memory. If it wants to read from locations on the stack, it has the stack pointer stored in it's hardware execution context. If it previously stored some data in memory, it has the address of that data either in a register inside its hardware execution context or at some offset from the address stored in its stack pointer. So all the processor needs to know in order to continue running a program is what's stored in it's hardware execution context.
Now when an OS does context switching between processes, it takes all of the state stored in the hardware execution context and stores it somewhere else, like the kernel stack, which is somewhere in memory. This frees up the registers in the hardware execution context to be used by some other process.
also, remember that modern processors are fancy and do things like only expose 16 registers at the instruction set level, whereas underneath they may have hundreds of registers and play tricks like register renaming.
While karima's answer clarifies it awesomely, Professor also mentioned that execution context refers to the entire state needed for a thread to run independent of another thread. Thus the points mentioned by @karima would also apply to threads. In fact, each thread is an independent "instruction stream" and thus most kernels treat a thread as a execution stream and maintain execution state pertaining to each specific thread.
This is an excellent slide to summarize all that a processor essentially does. First of, it loads the binary instruction from memory and subsequently decodes it. This is represented by the red "Fetch (Decode)" box. Secondly, the ALU or the execution unit executed the decoded instruction (say add, subtract, etc). Subsequently the result of this execution, updates a certain state of the processor, which over here is represented by the Execution context, or the context in which these instructions are executing. More accurately, how @violet points out, it constitutes the register set or memory from where you'll either fetch the operands and/or store the result of the instruction.
Summary of what a processor does (thanks @stride16):
fetch/decode: loads/decode instruction from memory
ALU/execute: execute instruction
execution context: update context (processor registers)
Processor registers include (thanks @karima): program counter (PC), stack pointer, general purpose registers (GPRs), processor status word (PSW), memory management registers.
Execution context is related to context switch in operating system. If there is only one process can be executed from start to end, then there is no need to have execution context. However, if we want to a multi-thread working environment, then operating system needs to record states of every process, which as @karima says. By having these records, OS can easily switch between different process.