Page 151 of 262
Re: What does your OS look like? (Screen Shots..)
Posted: Fri Jul 29, 2016 11:39 pm
by BrightLight
tsdnz wrote:omarrx024 wrote: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.
Re: What does your OS look like? (Screen Shots..)
Posted: Fri Jul 29, 2016 11:45 pm
by Octacone
omarrx024 wrote: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.
Re: What does your OS look like? (Screen Shots..)
Posted: Fri Jul 29, 2016 11:48 pm
by BrightLight
octacone wrote: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!
Re: What does your OS look like? (Screen Shots..)
Posted: Fri Jul 29, 2016 11:58 pm
by tsdnz
omarrx024 wrote: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
Re: What does your OS look like? (Screen Shots..)
Posted: Sat Jul 30, 2016 12:03 am
by BrightLight
tsdnz wrote: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
Re: What does your OS look like? (Screen Shots..)
Posted: Sat Jul 30, 2016 12:15 am
by tsdnz
omarrx024 wrote:tsdnz wrote: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?
Re: What does your OS look like? (Screen Shots..)
Posted: Sat Jul 30, 2016 12:20 am
by BrightLight
tsdnz wrote: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.
Re: What does your OS look like? (Screen Shots..)
Posted: Sat Jul 30, 2016 12:24 am
by tsdnz
omarrx024 wrote:tsdnz wrote: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.
Re: What does your OS look like? (Screen Shots..)
Posted: Sat Jul 30, 2016 12:28 am
by BrightLight
tsdnz wrote: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.
Re: What does your OS look like? (Screen Shots..)
Posted: Sat Jul 30, 2016 12:31 am
by Octacone
omarrx024 wrote:tsdnz wrote: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.
omarrx024 wrote:"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.
Re: What does your OS look like? (Screen Shots..)
Posted: Sat Jul 30, 2016 12:34 am
by BrightLight
It's been done before. IMHO, Menuet and Kolibri are the best examples of 100% assembly OSes, and both achieve decent performance, especially Kolibri.
Re: What does your OS look like? (Screen Shots..)
Posted: Sat Jul 30, 2016 12:36 am
by tsdnz
omarrx024 wrote:
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.
Re: What does your OS look like? (Screen Shots..)
Posted: Sat Jul 30, 2016 2:55 am
by onlyonemac
omarrx024 wrote:octacone wrote: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.
Re: What does your OS look like? (Screen Shots..)
Posted: Sat Jul 30, 2016 3:03 am
by BrightLight
onlyonemac wrote: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.
Re: What does your OS look like? (Screen Shots..)
Posted: Sat Aug 06, 2016 9:54 am
by narke
I'm kind of able to navigate through Chuck Moore's colorForth's blocks.