What does your OS look like? (Screen Shots..)

[BrightLight]

When the CPU is idle, it really is a constant loop of "sti; hlt; call yield", and yield gives control to the running tasks, both of which are waiting for mouse click (which is a GUI event), and so they call yield again, returning to the idle task.
CPU usage is apparently very little over 0.002%.

How many loops per second?
How fast is the core?
How does it come out of hlt?

The physical CPU is a quad-core Intel Core i3 2.40 GHz. My OS does not have a loop per second; it redraws the screen when it needs to be redrawn. If you mean how many timer interrupt per second, the timer is set up to 1000 Hz. It comes out of HLT whenever a hardware IRQ arrives. So basically, my combination of STI; HLT keeps the CPU idle until (most likely) the timer IRQ comes in.

[Octacone]

I'm sorry but I can't help posting here, lol. Too much free time in my hands. My scheduler is obviously keeping the CPU usage very low.
When the CPU is idle, it really is a constant loop of "sti; hlt; call yield", and yield gives control to the running tasks, both of which are waiting for mouse click (which is a GUI event), and so they call yield again, returning to the idle task.
CPU usage is apparently very little over 0.002%.

Nice stuff, 0.002% is not even close to 1%, impressive.
Just a quick side not I found a bug in xOS. You need to fix your mouse movement, when you drag your window around instead of being dragged it gets painted.

[BrightLight]

Nice stuff, 0.002% is not even close to 1%, impressive.
Just a quick side not I found a bug in xOS. You need to fix your mouse movement, when you drag your window around instead of being dragged it gets painted.

That's really a performance issue, not a bug, that happens if you drag the window too fast. If you drag down too fast, the mouse moves onto the canvas of the window, thus creating a "click" event. If you drag up too fast, the mouse moves out of the window's title bar. I know my mouse driver needs tweaks, and so does my graphics library. Thanks anyway!

[tsdnz]

The physical CPU is a quad-core Intel Core i3 2.40 GHz. My OS does not have a loop per second; it redraws the screen when it needs to be redrawn. If you mean how many timer interrupt per second, the timer is set up to 1000 Hz. It comes out of HLT whenever a hardware IRQ arrives. So basically, my combination of STI; HLT keeps the CPU idle until (most likely) the timer IRQ comes in.

2,400,000,000 * 0.002 % = 48,000 cycles per second
48,000 / 1000 = 48 cycles to check for messages then sti; hlt; nice..
Are you including the timer cycles (interrupt stuff)?
Can you set it up to check for a pointer. eg. begin: sti; hlt; cli; cmp xxx to 0; jne begin

[BrightLight]

2,400,000,000 * 0.002 % = 48,000 cycles per second
48,000 / 1000 = 48 cycles to check for messages then sti; hlt; nice..
Are you including the timer cycles (interrupt stuff)?
Can you set it up to check for a pointer. eg. begin: sti; hlt; cli; cmp xxx to 0; jne begin

Every time the timer interrupt comes in, it checks whether the interrupted process was idle or a running process. Depending on that, it increments one of the counters, idle_time or nonidle_time. My timer handler is very minimalistic and shouldn't take more than (maybe?) 20 cycles (not including the I/O to the PIC):

Code: Select all

; pit_irq:
; PIT IRQ Handler

pit_irq:
	push eax

	inc [timer_ticks]

	cmp [current_task], 0
	je .idle

.non_idle:
	inc [nonidle_time]
	jmp .done

.idle:
	inc [idle_time]

.done:
	mov al, 0x20
	out 0x20, al

	pop eax
	iret

[tsdnz]

2,400,000,000 * 0.002 % = 48,000 cycles per second
48,000 / 1000 = 48 cycles to check for messages then sti; hlt; nice..
Are you including the timer cycles (interrupt stuff)?
Can you set it up to check for a pointer. eg. begin: sti; hlt; cli; cmp xxx to 0; jne begin

Every time the timer interrupt comes in, it checks whether the interrupted process was idle or a running process. Depending on that, it increments one of the counters, idle_time or nonidle_time. My timer handler is very minimalistic and shouldn't take more than (maybe?) 20 cycles (not including the I/O to the PIC):

Code: Select all

; pit_irq:
; PIT IRQ Handler

pit_irq:
	push eax

	inc [timer_ticks]

	cmp [current_task], 0
	je .idle

.non_idle:
	inc [nonidle_time]
	jmp .done

.idle:
	inc [idle_time]

.done:
	mov al, 0x20
	out 0x20, al

	pop eax
	iret

Cool, what about the code after the hlt; does it just check for a pointer?

[BrightLight]

Cool, what about the code after the hlt; does it just check for a pointer?

It calls yield. Yield then checks if there's a task to be run. If there's not, it returns to the idle task. If there is, it runs the task. The tasks are waiting for mouse event, and while they wait, they also keep calling yield, thus spending most CPU time in the idle task.
But this is too off-topic, take a look at my GitHub repo if you want to know more.

[tsdnz]

Cool, what about the code after the hlt; does it just check for a pointer?

It calls yield. Yield then checks if there's a task to be run. If there's not, it returns to the idle task. If there is, it runs the task. The tasks are waiting for mouse event, and while they wait, they also keep calling yield, thus spending most CPU time in the idle task.
But this is too off-topic, take a look at my GitHub repo if you want to know more.

Ok, was trying to help you get more performance.

[BrightLight]

Ok, was trying to help you get more performance.

Thanks, but my performance issues are not in the scheduler. I mostly need more graphics performance.

[Octacone]

Cool, what about the code after the hlt; does it just check for a pointer?

It calls yield. Yield then checks if there's a task to be run. If there's not, it returns to the idle task. If there is, it runs the task. The tasks are waiting for mouse event, and while they wait, they also keep calling yield, thus spending most CPU time in the idle task.
But this is too off-topic, take a look at my GitHub repo if you want to know more.

"xOS is an operating system written for the PC entirely in assembly language."

...hlt... ...shocked...hlt...
I know that this is possible, but really?
Trust me, I could of never do that, not even in 200 years.

[BrightLight]

I know that this is possible, but really?
Trust me, I could of never do that, not even in 200 years.

It's been done before. IMHO, Menuet and Kolibri are the best examples of 100% assembly OSes, and both achieve decent performance, especially Kolibri.

[tsdnz]

I know that this is possible, but really?
Trust me, I could of never do that, not even in 200 years.

It's been done before. IMHO, Menuet and Kolibri are the best examples of 100% assembly OSes, and both achieve decent performance, especially Kolibri.

Yes very cool, well done.

[onlyonemac]

Nice stuff, 0.002% is not even close to 1%, impressive.
Just a quick side not I found a bug in xOS. You need to fix your mouse movement, when you drag your window around instead of being dragged it gets painted.

That's really a performance issue, not a bug, that happens if you drag the window too fast. If you drag down too fast, the mouse moves onto the canvas of the window, thus creating a "click" event. If you drag up too fast, the mouse moves out of the window's title bar. I know my mouse driver needs tweaks, and so does my graphics library. Thanks anyway!

When the mouse button is pressed, you should keep track of whether the press was within a window or on the title bar. Then when the mouse is dragged, you can see if the button press initially occurred in the title bar, in which case you can say "don't send any click events, but move the window to the new location of the mouse pointer (offset by the initial offset of the window from the mouse pointer)". The window would keep moving with the mouse pointer no matter how fast the pointer is moved. Another thing you might want to try is only updating the window position when the button is released, or if you really want to show the window contents while dragging then you could try some sort of buffering whereby the window doesn't get a redraw event for each "step" of the drag but you simply copy an image of the window to a buffer, redraw the screen without the window, and then overlay the image on the screen at each step, and finally when the button is released update the position of the window and redraw the screen with the window. I'm not sure if that would be faster, because maybe you're already buffering windows.

[BrightLight]

When the mouse button is pressed, you should keep track of whether the press was within a window or on the title bar. Then when the mouse is dragged, you can see if the button press initially occurred in the title bar, in which case you can say "don't send any click events, but move the window to the new location of the mouse pointer (offset by the initial offset of the window from the mouse pointer)"

You're right. I'll try this, thanks!
I never thought of saving the initial mouse state once the button is pressed.

[narke]

I'm kind of able to navigate through Chuck Moore's colorForth's blocks.