I got my self a 16bit compiler so I can compile to dos. In the header <dos.h> it has a union called REGS. May someone please give me more information on this union?
Thanx in advance!
I got my self a 16bit compiler so I can compile to dos. In the header <dos.h> it has a union called REGS. May someone please give me more information on this union?
Thanx in advance!
It is used in conjuction with the int86() and int86X() functions that generate software interrupts.
This union has members in which you can store the values of registers that you need before calling an interrupt through int86() etc...
The int86() function:
1. PUSHes the current values of the CPU registers to some other temporary space....
2. fills in the actual registers with the values provided (i.e. the members of the UNION provided by you)...
3. calls the interrupt.....
4. changes the members of the UNION provided by you with the new CPU register values (Caused by the function performed by your interrupt call)....
5. and POPs up the previous values into the actual CPU register (i.e. cleans up its mess) before returning....
There really is no mess to clean up unless EDI ESI, EBP, ESP, or DS have been altered by the interrupt handler. Otherwise int86() is simply a function that auto-saves the values of the registers. The only requirement of interrupt handlers is that they leave the registers as they were prior to entering the handler. Since most well-behaved handlers do this, int86() is overkill. But C and the IDE have a tendency to alter the registers so int86() and int86x() are simply guaranteeing that the software interrupt will work and the register values will be correct.
In pure assembly there really is no need to save every register's value on the stack so in some instances int86() and int86x() are overkill.
Hmmm, so if "int86() and int86x() are overkill," what function would you suggest instead of int86 and int86X?Originally posted by Bubba
There really is no mess to clean up unless EDI ESI, EBP, ESP, or DS have been altered by the interrupt handler. Otherwise int86() is simply a function that auto-saves the values of the registers. The only requirement of interrupt handlers is that they leave the registers as they were prior to entering the handler. Since most well-behaved handlers do this, int86() is overkill. But C and the IDE have a tendency to alter the registers so int86() and int86x() are simply guaranteeing that the software interrupt will work and the register values will be correct.
In pure assembly there really is no need to save every register's value on the stack so in some instances int86() and int86x() are overkill.
Also, have you ever heard of reentrant code? This is something that has to be considered when writing multi-tasking systems with common shared routines.
If a common shared function is interrupted by a higher priority task while it's processing and the same function is called in the new task, the registers get changed. When the original task continues, the registers no longer contain the values it had. Hence, the routine must save and restore the registers when it runs.
This is sometihing I had to consider seriously in many systems I had to design.
Definition: Politics -- Latin, from
poly meaning many and
tics meaning blood sucking parasites
-- Tom Smothers
Since a task switch will auto-save the state of the CPU then doing it manually would be overkill. The only rule is that if you alter registers other than the explicit return value registers you should save the previous values and restore them before returning from your function and/or interrupt handler.
For instance if you alter DS you would push it prior to changing what it points to. Upon completion you would pop it off the stack to restore it.
But if you alter ES you could probably get away w/o saving it. I recommend that if you alter EDI or ESI that you should probably save those as well. However, it is pointless to save EAX EBX ECX and EDX even acrossed a task switch - beings that the TSS will save it for you.
If you think I don't understand re-entrant code then check some of my earlier posts and one on the C board concerning DOS interrupt handlers.
