- KnightOS Multitasking
- 14 Jun 2010 03:33:40 pm
- Last edited by SirCmpwn on 14 Jun 2010 03:37:37 pm; edited 1 time in total
This documentation is subject to change
Multitasking in KnightOS is done with hardware interrupts. When the system interrupt is fired, the following takes place:
All registers are saved to the current thread's register cache
The entire stack is poped into the current thread's stack cache
The thead counter moves the the next thread in the thread cache
The next thread's stack cache is pushed in
The next thread's registers are restored
The interrupt resumes execution
When a program is run, the following occurs:
Interrupts (threads) are disabled
Memory equal to the program size is allocated
The location of the allocated memory is loaded into the thread cache
The default stack (see below) and zeroed registered are loaded into the cache
Interrupts (threads) are enabled
The routine returns
The default stack is empty save the address of the ThreadKill routine, which will kill the calling thread when the thread performs a RET.
When a running thread needs to load a pointer, JP, or CALL, the following occurs:
The programmer has used KLD, KJP, or KCALL instead of ld, jp, or call, which are all macros defined in KnightOS.inc.
The macros consist of:
KLD Register, Address:
rst rKLD
dw Address
db RegisterID
KJP Address:
rst rKJP
dw Address
KJP Flag, Address:
rst rKJP
dw Address
db FlagID
KCALL Address:
rst rKCALL
dw Address
KCALL Flag, Address:
rst rKCALL
dw Address
db FlagID
The RSTs will pop the address they came from. The register and flag IDs are used to determine which register/flag is affected. Since all programs are located in RAM, it can use SMC to change the macro. In the case of KJP, for example, it will change the macro code from a macro to a jp call, add the RAM offset of the current thread to the address, and resume execution. The other macros are similar.
Multitasking in KnightOS is done with hardware interrupts. When the system interrupt is fired, the following takes place:
All registers are saved to the current thread's register cache
The entire stack is poped into the current thread's stack cache
The thead counter moves the the next thread in the thread cache
The next thread's stack cache is pushed in
The next thread's registers are restored
The interrupt resumes execution
When a program is run, the following occurs:
Interrupts (threads) are disabled
Memory equal to the program size is allocated
The location of the allocated memory is loaded into the thread cache
The default stack (see below) and zeroed registered are loaded into the cache
Interrupts (threads) are enabled
The routine returns
The default stack is empty save the address of the ThreadKill routine, which will kill the calling thread when the thread performs a RET.
When a running thread needs to load a pointer, JP, or CALL, the following occurs:
The programmer has used KLD, KJP, or KCALL instead of ld, jp, or call, which are all macros defined in KnightOS.inc.
The macros consist of:
KLD Register, Address:
rst rKLD
dw Address
db RegisterID
KJP Address:
rst rKJP
dw Address
KJP Flag, Address:
rst rKJP
dw Address
db FlagID
KCALL Address:
rst rKCALL
dw Address
KCALL Flag, Address:
rst rKCALL
dw Address
db FlagID
The RSTs will pop the address they came from. The register and flag IDs are used to determine which register/flag is affected. Since all programs are located in RAM, it can use SMC to change the macro. In the case of KJP, for example, it will change the macro code from a macro to a jp call, add the RAM offset of the current thread to the address, and resume execution. The other macros are similar.