I have looked around and found a ton of info about the inner workings of the microprocessor and its' different registers. However, I haven't found much discussion concerning how to best control feeding instruction code to the instruction register. And more importantly, a module controlling that flow. Is it that we are stuck with the simple feed-the-stack method? Or are there other approaches worth talking about? Any suggestions? Or if anyone knows where this type of discussion can be found, I would greatly appreciate being pointed in the right direction.

Instructions are not fed to the instruction register.Rather, this register contains the address of the next instruction to be executed.After executing an instruction, the cpu automatically increments the instruction register to point to the next instruction.

You are correct. The instruction register contains the address to the next instruction. By saying the CPU automatically increments to point to the next address, I assume you mean the program counter is incremented. My question still is where does that next address come from and how does the OS know when the CPU is ready for the next instruction and can "feed" the next instruction address? My question probably indicates my novice-level experience in this area, but in my attempt to gain more control over what happens on my machine I am trying to understand how the OS handles this.

I have no idea on how you may gain control over that. If you want it to go elsewhere just make a jump or a call. As far as i know theres only one other thing to do with it. It concerns the trap flag, which when set if im not wrong causes the process to pause before executin g the next instruction. But, hey im not so sure of what im saying but you should look into it. Look processor manuals at intel.com and amd etc. Bye.

OK. So maybe I can ask my question another way. Forget about what I said about controlling my machine. My question ultimately is what are the different ways the address for the next instruction gets into the next instruction register? I am assuming the address is the start of my ASM program and the CPU jumps to that address and starts consuming machine instructions until it encounters the STOP instruction. But the address of my program must first magically appear in the register. How does it happen?

Sometimes an instruction can generate an exception, which is a kind of error.A really good example is the INT 3 instruction (Step BreakPoint).When the cpu executes this instruction, an exception occurs.What happens now is that the cpu stores all its current registers, and fills the EIP register with the address of the Exception Handler.Now executing the handler, which eventually completes, the cpu restores the registers to previous values.

Literally, the exception caused the EIP register to change, and later to change back again.You can do this also, by writing to the EIP register you can decide where the program execution will flow to in the next step.

This is NOT normal thing to do, but it can be done, and is most often found in virus-like code.

OK. Definitely don't want to mess with exception handlers. It would only end up as some half-baked solution. In the end I think you've indirectly answered my question. Manipulating the instruction register is not really an option. But on the issue of controlling what is executed on a machine, would I be correct in saying that interrupt handlers are the only normal way to pick and choose what machine instructions the processor receives?

Yeah... I think what you might be interested in is the "schedualer". There's a "timer interrupt" that triggers, on bootup, about 18 times per second. The OS would crank this up to 1000 times per second, or so. Every time it fires, the "timer interrupt handler" is executed. The OS puts some code there that saves the "state" of the currently running program (register values, including eip). Then, if there's another process ready to run, its "state" is loaded, and it executes until the timer interrupt fires again. Then, if it's "my turn" to run again, this code reloads my "state" and transfers execution there - probaby by putting my old eip on the stack and doing "iret"(?).

That might be considered "feeding the instruction register". Dunno if it's what you're getting at or not...

Thanks for the info fbkotler. You bring up an interesting point about using the scheduler. Although my initial inquiry is more along the lines of how to handle the flow of instructions to the CPU that ultimately are a result of timed events, external calls, and from user-generated interrupts. My aim from the beginning was to get connected with people who have discussed (or are currently discussing) the available approaches one can use when building an OS that efficiently organizes and prioritizes all incoming interrupts. Does that make sense?

Thanks for the pointer. As always, there exists several different sites where a person can discuss ideas, or get help. I was merely pursuing the possibility of connecting with someone here to discuss, in theoretical terms, how to best control what happens on a machine and how a person might develope a more efficient OS. My quest continues...

The first instruction the CPU will be executing is at address 000FFFF0h in real mode. That means wenn you switch on your computer, it will begin there.

Because of the fact that the BIOS-Rom is located there, it will begin to execute the BIOS Code. The BIOS begins to initialise the hardware of your computer, that is the programmable Interrupt controller, the Floopy Disk controller, and so on ...

Wenn it is finished with initialising it will load your Code. Your Code can be on a Floopy Disk, a Hard Disk and so on. Your code must be in the first sector (The MBR = Master Boot Record). The BIOS Loads the first sector of a medium into the Ram at Address 00007C00h and jumps there. So youre Code will be there and the first instruction Address will be 00007C00h.

The next Addresses are determined by the CPU itself. The CPU knows the length of the Instruction it is currently executing. The next instruction is right after the instruction that is currently executing, it will jump by itself to the next instruction.