Cpu idleing

[AirFlight]

I was wonder about techniques of making cpu idleing for some miliseconds when using IN and OUT instructions to slower devices. For example PS/2 mouse, if it makes interrupt you should do three IN instructions to take curssor positions and button status, and if you take second byte too fast after first you will get first byte again.

This are some procedures to make cpu idle i know

Waitecx:
dec ecx
jnz Waitecx

is there same better way, and is something integrated in new CPUs Pentium 4 and newer like

Wait 27ms
Some instruction to specify to it how miliseconds to wait.

[abachler]

Generalyl a processor is suspended by a hlt instyruction, which only reactivates the cpu when an interupt occurs. So your Idle process woudl basically be

Code: Select all

idle_process:
     hlt
     jmp idle_process

although in a realistic OS you would have some code in there to force a task switch so it didnt deadlock other processes waiting on an interupt which may not occur for some many ms.

[Love4Boobies]

That's the wrong way to do it. Different instructions have different timings on different CPUs. And there are also other things to take into consideration, such as pipelines, hyperthreading, IRQs, cache misses, etc. The right way to do it is to use the PIT/HPET or even APIC (also calibrated using the PIT/HPET). Note that Borland's implementation for delaying used to be similar to what you're describing: after counting how much time some loop took (at initialization time), it just executed that loop many times (at calling time). This, of course, will lead to overflow problems on faster machines.

Also note that the method described earlier (the one with HLT) doesn't work if you don't want an idle process. There's no way out of the idle loop. Maybe this would do the trick:

Code: Select all

call install_new_handler
sleep:
hlt                    ; wait for HPET/PIT
cmp byte [lock],0      ; cleared by the HPET/PIT handler when the time has passed
jnz sleep

Code: Select all

install_new_handler:
mov byte [lock],1
.
.
.
ret

Anyway, normally, all of this should be used on a singlethreaded OS (which I don't know why, but it's what I think you have in mind, having read your post). Otherwise, you'd just want the current thread on the sleep queue for a period of time.

If we're talking about a multithreaded OS, the code above works perfectly, but you still need to use the PIT/HPET handler to put the idle process on the sleep queue and take out something else as soon as it can run. It doesn't deadlock anything...

[AirFlight]

Yes, thanks that is big help.
I only knew about PIT and RTC, i wanted to use RTC for precess scheduling but when i tried to enable its interrupt on int 70h something was not good, after every run of os i had to reprogram date in bios, maybe i wrote too fast to its regsters, so i needed a timer to do slow rtc registry writing and i only had PIT or software loop.

So there is PIT, RTC , LAPIC and HPET.
Thanks i guess that it is that new clock hardware, so maybe it is good to use HPET for proccess scheduling,
If it works i think im going to disable RTC interrupt.

if somebody is looking for something similar maybe this finds would help:
http://www.intel.com/hardwaredesign/hpetspec_1.pdf
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/doc/OLS2007-tickless-idle.pdf

What timers do other oss use RTC or HPET for process scheduler?

[Love4Boobies]

Not many use the RTC anymore. Typically you have HPET on newer systems, that start in PIT compatibility mode (so if you program the PIT, your code still works). Newer OSes probably detect if HPET hardware is present, and if it is, they use that. It probably makes sense best to use the local APIC (when present) because of the possibility of having a multiprocessor system. If the local APIC isn't there, scheduling schould be handled using the PIT/HPET (that's basically always there).

[AirFlight]

Oh no, Virtual PC has no ACPI HPET entry, just
FACP at 07ff0200
OEMB at 07fff040

Computer restarting, and experimenting on real computer .

[jal]

I was wonder about techniques of making cpu idleing for some miliseconds when using IN and OUT instructions to slower devices. For example PS/2 mouse, if it makes interrupt you should do three IN instructions to take curssor positions and button status, and if you take second byte too fast after first you will get first byte again.

You are wrong, you should never read more than one byte on a PS/2 interrupt! Read the byte, store it in a buffer, then return. After the last interrupt (when you've read everything and your buffer is full), process what you have read.


JAL