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

[Xeno]

is it just me or is it de facto to print 'A' and 'B' when working on multi-threading?

[iProgramInCpp]

is it just me or is it de facto to print 'A' and 'B' when working on multi-threading?

I like to differ:



In the above image, each 'ball' (more of a square) is operated by one thread. They don't collide among each other, though.
In the below image, each particle is operated by a thread. Every now and then a particle is launched from the lower center of the screen, and then after some time it explodes into like 50 other particles. It's a neat way to test my threading infrastructure, I feel. I actually caught some bugs with this test, though mostly due to out of memory errors instead of anything related to my scheduler.

[chase]

How is the synchronization handled between the balls/particles? You said they don't collide, did you mean they avoid overlapping or that they can't tell if they occupy the same space?

I always did "thread-1" and "thread-2".

[iProgramInCpp]

How is the synchronization handled between the balls/particles? You said they don't collide, did you mean they avoid overlapping or that they can't tell if they occupy the same space?

I always did "thread-1" and "thread-2".

That's the thing - inter-ball collision, in the context of each ball being operated by a separate thread, would be more complicated, so I did not bother. Several balls can occupy the same space, and they can't tell that they are. This is just a test so I know that my scheduler works. It tests thread scheduling, multi-core work stealing, spinlocking (each time a ball thread calls DbgPrint() to print itself at its position, a spin lock is held) and timer expiration.

The fireworks test is similar but upgraded to eleven. It also tests some codepaths regarding out of memory conditions. (fireworks won't explode fully if they run into OOM conditions while creating the exploded particles)

[Xeno]

is it just me or is it de facto to print 'A' and 'B' when working on multi-threading?

I like to differ:



In the above image, each 'ball' (more of a square) is operated by one thread. They don't collide among each other, though.
In the below image, each particle is operated by a thread. Every now and then a particle is launched from the lower center of the screen, and then after some time it explodes into like 50 other particles. It's a neat way to test my threading infrastructure, I feel. I actually caught some bugs with this test, though mostly due to out of memory errors instead of anything related to my scheduler.

XD I withdraw my statement.

[iProgramInCpp]

XD I withdraw my statement.

Did you make a statement?

[Xeno]

XD I withdraw my statement.

Did you make a statement?

nah it was more of a question I just couldnt remember the word

[cloudapio]

After taking a look at https://sha256algorithm.com/ and a few struggles with endianness, I have implemented the SHA-256 hashing algorithm for my OS! Now I won't have to store passwords in plaintext

[lambduh]

Code: Select all

Hello.
Setting exception handlers.. done
Initializing page tables.. done
Initializing the virtual filesystem.. done
Starting the timer.. done
Starting the scheduler..
Extracting crtbegin.S (2446 bytes).. done
Extracting bin/wc (304164 bytes).. done
Extracting bin/echo (95248 bytes).. done
Extracting bin/sh (318180 bytes).. done
Extracting bin/cat (306012 bytes).. done
Extracting user.elf (140372 bytes).. done
$ bin/echo hello world
hello world
$ bin/echo hello again
hello again
$ wc crtbegin.S
exec wc failed
$ bin/wc crtbegin.S
142 349 2446 crtbegin.S
$ 

Well, not a screen shot because I only have serial I/O, but as of today my OS has a working shell. It took about two weeks to get fork() working right, then a couple more ironing out bugs with exec() and wait(). All the userspace programs here are from xv6 linked against newlib.

[eekee]

Well, not a screen shot because I only have serial I/O

I expect my first "screenshot" will be serial output too, and maybe more than the first. And I like it because I find VGA text mode screenshots very hard to read. I've always had a problem with the low contrast of normal text in bright-for-bold displays. This is why I pay more attention to GUI screenshots even though I know it's all too easy to build a GUI when the OS underpinnings aren't really there; I can hardly read the text-mode screenshots.

[lambduh]

I expect my first "screenshot" will be serial output too, and maybe more than the first. And I like it because I find VGA text mode screenshots very hard to read. I've always had a problem with the low contrast of normal text in bright-for-bold displays. This is why I pay more attention to GUI screenshots even though I know it's all too easy to build a GUI when the OS underpinnings aren't really there; I can hardly read the text-mode screenshots.

It's pretty easy to be misleading with a serial dump too, of course :p it might have looked, for example, like I have a real filesystem. In fact, there is no "bin/" directory, just files with names like "bin/sh".

Fortunately I won't need to deal with VGA at all because I'm not targeting PC architecture. I plan on writing a framebuffer terminal when the user space is more stable because I do eventually want to run on real hardware, but as long as I'm only in virtual machines, nothing's going to work better than serial.

[eekee]

I expect my first "screenshot" will be serial output too, and maybe more than the first. And I like it because I find VGA text mode screenshots very hard to read. I've always had a problem with the low contrast of normal text in bright-for-bold displays. This is why I pay more attention to GUI screenshots even though I know it's all too easy to build a GUI when the OS underpinnings aren't really there; I can hardly read the text-mode screenshots.

It's pretty easy to be misleading with a serial dump too, of course :p it might have looked, for example, like I have a real filesystem. In fact, there is no "bin/" directory, just files with names like "bin/sh".

Oh, the old 'just accept / in filenames' trick! But it's not really a trick, just a simplification which I guess may be suboptimal for full-featured filesystems. (I've never written a filesystem.) Tar stored paths this way.

Fortunately I won't need to deal with VGA at all because I'm not targeting PC architecture. I plan on writing a framebuffer terminal when the user space is more stable because I do eventually want to run on real hardware, but as long as I'm only in virtual machines, nothing's going to work better than serial.

Me either. I might initially target 32-bit PC as that's the only architecture my compiler supports, as baby steps in porting the compiler and its library, but I want to go for ARM32 after that. Maybe ARM64.

[nullplan]

but I want to go for ARM32 after that. Maybe ARM64.

I'd suggest you avoid ARM32, because the architecture is a mess. Unless you limit yourself to ARMv7, then it is pretty sane. But attempting to support all ARM architecture versions up to 7 (or even just v4-v7, the range of the EABI) is pretty demanding. ARMv4 didn't even have compare-and-swap.

[eekee]

@nullplan: Thanks, noted. I'm pretty sure I don't have ARMv4, only 1 or 2 ARMv5 and a few ARMv7.

[avcado]

I guess I finally have something to show. Recently finished implementing IRQ0 & IRQ1, so I thought it'd be appropriate to implement a math library before I forget/add more features. Here I've implemented sin(x). Next steps (at least what I currently want so far) are:

• The other two trig functions, cos(x) and tan(x)
• Some implementation of imaginary numbers

Soon I'll write a graphing calculator, but that's not until I get into ring 3...

Screenshot from 2024-08-19 21-17-48.png (11.7 KiB) Viewed 6440 times