OSDev.org

Hello all,

Been walking through some kernel sources, and noticed that they do almost all use the same technic, regarding CPU traps handling. Well according to minix code source for example, wich actually uses the same method, whenever an exception is being fired up, according to the idt it calls a small function for example (divide_zero), this function will push subsequently a dummy 0 and the exception number, afterwards it calls a common function which gonna push registers and set up kernel data segment... (does maintain a uniform stack frame) and finally will call in its turn the head function which actually handle the exception properly.

In my regard, we could have managed it in a simple and very quick way. Why not define simple functions, some of them will of course take an argument (pushed error code by CPU) and some not, and simply remap them directly in the IDT.

I think this approach is more direct and efficient. But as long as I still don't have too much experience, I wonder will it have consequences on further developpement ?

Thank you,

The improvement you're talking about is in the order of 5% of the time the processor needs to even begin executing an interrupt handler.
The advantage of the other method is the lack of code duplication, and therefore, maintainability (and memory usage for that matter).

Make your choice

Wow, thanks Combuster, always quick responses.

Well, That's true, I figure out that the main design behind the minix way, is to actually save register status for further tracing... this is a good matter for debugging purposes and so on.., Whereas my approach might actually discard cpu status the time the exception has been activated hence obfuscating things a little bit.

Hi,

stoned wrote:I think this approach is more direct and efficient. But as long as I still don't have too much experience, I wonder will it have consequences on further developpement ?

Some languages (e.g. C) aren't capable of generating an interrupt handler; so to get around the compilers limitations programmers use a small assembly language stub that calls a normal function.

If you're programming in assembly language to begin with, then there's no such limitation, and it's entirely possible to (for e.g.) do the minimum necessary to handle the exception; and only setup the stack and jump to a common critical error handler if the exception is fatal.

Reducing code duplication isn't a good reason, because a lot of the exception handlers do entirely different things (until the exception handler has determined that the exception is fatal), and exception handlers can call common routines and/or JMP to a common handler after they've done "exception specific" handling. For an example of "exception specific" handling:

• NMI: Determine if the exception was caused by the OS's watchdog timer, check if the OS has been updating some variable and IRET if everything is fine.
• Debug exception: Find the cause of the exception and send relevant information to a different process (the debugger), and IRET.
• Breakpoint exception: Send CPU state to a different process (the debugger), skip the INT3 instruction and IRET.
• Invalid opcode exception: Determine which instruction caused the exception, emulate the instruction then IRET.
• Device not available exception: Save the current FPU/MMX/SSE state and load the correct FPU/MMX/SSE state for the current task, then IRET.
• General protection fault: If the cause was RDTSC get the task's private counter and IRET.
• Page fault: Determine cause of the exception and clone the page ("copy on write") or load it from disk (swap, memory mapped file), then IRET.
• Alignment check exception: Send details to a different process (the debugger/profiler), disable alignment checking, enable "single stepping", then IRET, let the instruction execute properly and when the single-step exception occurs enable alignment checking again.

The thing is that when someone is first writing their exception handlers the OS is usually in early stages and doesn't support anything that needs exception specific handling (e.g. no support for swap space, emulating unsupported instructions, debugging/profiling, etc); so initially the exception handlers do look like they all do the same thing (e.g. blue screen of death). It's not until later on (when the OS starts supporting certain features) that it makes sense.

For performance, I agree with Combuster - the improvement is going to be small. However, from a marketing perspective better is better, and being able to claim that your OS is faster than some other OS is a good thing (regardless of how small the difference is)...


Cheers,

Brendan

Brendan wrote: Some languages (e.g. C) aren't capable of generating an interrupt handler; so to get around the compilers limitations programmers use a small assembly language stub that calls a normal function.
Brendan

Yep that's true, and that's make things easy to maintain as though. But you can still inline some assembly, but gotta control the output, since gcc will messs arround with it.

Brendan wrote: For performance, I agree with Combuster - the improvement is going to be small. However, from a marketing perspective better is better, and being able to claim that your OS is faster than some other OS is a good thing (regardless of how small the difference is)...
Brendan

Yep, that's a great advantage, but I think, relaibility and the ease of maintenance is a key issue in os implementation. what do you think ?

Thanks guys,

I wonder why GCC doesn't support the 'naked' attribute for x86, so it would be easier to call it directly.

Well, it might seems a kinda crypty and unsens but, it doest play a key role while optimizing, sometimes gcc can even optimize your assembly code :d hence letting him know about every inch of the assembly is quiet worth it

cyr1x wrote:I wonder why GCC doesn't support the 'naked' attribute for x86, so it would be easier to call it directly.

I started porting interrupt, interrupt_handler, and naked attributes, but then I realized it would involve a hell of a lot of core changes and after reading files in GCC's source I got a headache and since then I rm -rf'd my work and am currently working on fixing PCC's amd64 code generation. (If anyone is interested in helping, bfcode() in arch/amd64/code.c is miserably broken and I would greatly appreciate some help in fixing it.)