jmp $ or hlt?

[Candamir]

In my kernel start.asm file, I invoke the main method of my c file and afterwards jmp $, but I've seen other implementations that do hlt instead. What is better?

I think that jmp $ is an endless loop (pretty sure on this, actually) and hlt stops the cpu. So, if I would like to save energy, I invoke hlt. But what would be the advantages on invoking jmp $? Because if I leave my kernel just waiting for interrupts happening, I could essentially invoke hlt, couldn't I?

[YeXo]

The best way to do this is in my opinion hlt, but you have to look out. After an interrupt the processor continues with the next instruction. The right code would be:

Code: Select all

hltloop: hlt
    jmp hltloop

[paulbarker]

Stick a "cli" before you start the loop. The only interrupt that can happen then is an NMI, which can't be avoided.

[Candamir]

Does hlt return inmediately or only after the next interrupt?

[paulbarker]

It stops the processor until the next interrupt. I do not know the details of what happens when an interrupt occurs during this halted state, so you should look it up in the Intel manuals. Just lookup the hlt instruction in the 2nd book (instruction reference).

The manuals should be linked to from the FAQ, quick links or anything else around here. Alternatively, google for it .

Sorry I can't be more specific about the workings of hlt.

[Candamir]

I just checked the manuals, and it seems that it doesn't mention that either, but with the looping code of YeXo I think it's anyway the same thing.

[Pype.Clicker]

cli ; hlt
you definitely halt the processor, making it unable to execute any further instruction (except maybe NMI or SMM interrupts). The only way you could want this is in a "shutdown" for non-ATX systems, imho.

hlt
no instruction will be processed until an interrupt arise. When the interrupt handler is completed, iret executes the instruction past "hlt", so this is more a "wait for the next interrupt" than really a definite halt.

jmp $
literally, you're doing "here: jmp here". This keeps the CPU busy doing nothing ... interrupts can still be handled (unless you just did a CLI before, of course). You usually don't see this except in being-debugged code to mark a pause that only the debugger can jump over.

here: hlt; jmp here
that's the most common "idle loop": some code you can ask the CPU to execute when there's actually nothing useful to be done. energy is saved and interrupts are still processed, but we never get "out" of the loop (so as soon as interrupts are completed, you go back saving energy).

[Candamir]

Thank you. What do you mean by 'useful things'? Could that be things like cleaning up RAM and so on or defragment the hard disks?

[Solar]

...or running the screensaver, or crunching SETI@home. Whatever your computer does while it's waiting for you to hit the next key or make the next mouse move.

[Candamir]

Hey, Solar, I liked the one with SETI@home; I think there is a similar program at Stanford, supported by Google (about protein foldings), it would be great if the user could select from a few of these projects during installation after the kernel checked that there is an ethernet card or a modem installed (the user could also disable the feature). Has anyone done anything similar to this, on the lowest level of an OS?

[bubach]

It doesn't really matter what you use in this case..
Your main function will never (hopefully) return to the "jmp $" or "hlt" anyway.. The OS "quits" when the user presses the power button, not by doing "return 0;"..

[Candamir]

Why shouldn't it return? My main function is void, and it returns and right afterwards in the assembly code comes this:

Code: Select all

hltloop:
   hlt
   jmp hltloop

There you had to implement SETI or whatever...

[paulbarker]

Its common practice that kmain (or whatever its called) ends with the idle loop. kmain should never return (unless you design otherwise and confuse me and most of the other people here), and the infinite loop after the call to kmain is just to catch this error (otherwise any piece of code could be executed, or the processor may try executing data as code).

[Candamir]

But what is wrong in the fact that I have my idle loop right after kmain and not inside it? I think in the end, it is the same... And if you want to use an energy-efficient loop inside kmain, you had to use inline assembly anyway __asm__("hlt");

[Colonel Kernel]

And if you want to use an energy-efficient loop inside kmain, you had to use inline assembly anyway __asm__("hlt");

No you don't.

From my main.c:

Code: Select all

Processor_enableInterrupts();

while (true)
{
   Processor_waitForInterrupt();
}

Elsewhere...

Code: Select all

global Processor_enableInterrupts

Processor_enableInterrupts:
   sti
   ret


global Processor_waitForInterrupt

Processor_waitForInterrupt:
   hlt
   ret

Or, you could use inline assembly to implement those two functions. Either way, your kmain() can be implemented entirely in C if asm offends your sense of aesthetics...