Printable View
Just a little question: How is the end of a program in memory signified? Or just the OS just keep tabs on where the program should start and end or something. I guess what I'm trying to ask is, is there an instruction that signifies the end of the program?
Just curious. In my VM i'm using 0xFFFF as OP_END, just wondering how "on the mark" this kind of method is.
The OS keeps track of this internally. There is no special byte which signifies the end of a program's memory block.
Most OS's have some kind of API call to the kernel which means "end process".
A program is loaded into primary storage (memory) from secondary storage (disk). Bear with me here, this is 100% compewta seance!
All files in secondary storage are well defined and thus have a beginning and an end.
This information can also be reused in primary storage.
And so endeth the lesson. :cool:
I'm currently using an emulator called CUSP to learn assembly. It's a very simple representation of a word-addressed processor, so it may not be accurate to modern computers in the slightest. The end of a "program" is not clearly defined really, only the end of a set of instructions, which is terminated with a HLT instruction (usually $FFFFFF in memory if your Instruction Register is 24 bits). In CUSP, there's a command that you give the assembler (.EQU @, $### where ### is the hexidecimal value of the address in memory at which your program's instructions begin) that tells it where to start executing instructions. After the instructions end, there is usually a set of variables (NOTE: there is no way to look at memory and tell what's a data value and what's an instruction). The OS probably keeps tabs on where to start the next program...
So, to answer your question directly, it seems to me that the OS tells the computer where to start executing instructions and the program itself tells the computer where to stop executing instructions.
Sorry if that was confusing.
Ok I understand. I'm going to stick with what I've already got - execution starts at the beginning of the allocated memory block and ends when 0xFFFF is hit.
DOS handled it like this: execution starts either at the address the executable was loaded to (for COM files; this was a fixed address), or at the program entry point (for EXE files), which is defined in the file header.
The program can do whatever it wants. At some point, it will use software interrupts to call back into the operating system. With the right parameters, this call would cause the system to not return back from the system call but instead load the command interpreter command.com back into memory to replace the finished program.
For Win32, the ExitProcess call has the same effect, except that process management works very differently.
Can we say "ret" instruction spesifies the end of the program?
No. It's just a special jump instruction, making the program continue at a different point.