As far as I know it should execute completely to preempt. If the instruction can be halted in the middle of the process I am pretty sure it will need to be considered as not being executed at all (as the process of changing from one process to another will copy all the registers, including the stack pointer).
So, even if at the hardware level it may be interrupter without completing, I am sure we will never see partial values lost (but I really believe the interrupt itself will only work at the next instruction).
There is a part that says this: "Interrupt processing has some basic requirements from the CPU. Before it can respond to an interrupt, the processor must wait for an "interruptible" state in its processing. For example, if the processor's writing to memory, it must wait until the write is done before processing the interrupt."
So, it will never interrupt in the middle of a instruction. The instruction itself is always atomic.
Sorry for the late reply, but I had to chime in here:
It is a common misunderstanding, unless an instruction is designed to be atomic (like x86 CMPXCHG or 680x0 TAS), an instruction can be interrupted mid-execution (e.g. INC [mem] can be interrupted after the read and before the write of the incremented value. This moment would be considered interruptible even tough the operation is not completed). If you need guaranteed atomic operation, you have to either use an instruction that is designed as atomic or you have to implement an access control mechanism that is based on these atomic operation around your non-atomic operations. Semaphores etc. are based on these guaranteed atomic operations to guard complex, i.e. non-atomic, operations.
On a side note, this concept becomes even worse when executing with multiple CPUs or cores where several instructions are executing simultaneously and they can interfere with each other even without preemption. In this situation atomically-designed operations still guarantee atomic execution while others are becoming indeterministic as they are executed in parallel.
how do i interface with the gprs modem using j2me without using a pc...i want to use it to send a sms through the gprs modem in a home security system to a predefined mobile number...pls help me regarding this...
This will be the next challenge and the last will be how to do this within Windows and not through the DOS.
Well, there's a little problem with that. You'll have to rewrite this application from scratch and supply a device driver to pull this off. User mode applications do not have any access to the hardware, hence the need for a driver.
If you've got the complete specs for reading/writing the CMOS on a Gigabyte board, the ability to write and debug kernel mode code, specically device drivers, and can write said device drivers in C (cannot use C#!), you should be able to pull this off.
The basic Line Print Terminal connector (parallel port) pin function specifies pins 2 - 9 for data bits 0 - 7. So I suppose you need to make a distinction between the hardware and the software you might be using. with the hardware accepting 1 byte, buffer size in your software - whatever that is - is now the question you need to address.