OSDev.org

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

Xeno wrote: ↑Sat Jun 22, 2024 10:16 am 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.

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".

chase wrote: ↑Sun Jun 23, 2024 11:14 am 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)

iProgramInCpp wrote: ↑Sun Jun 23, 2024 3:10 am

Xeno wrote: ↑Sat Jun 22, 2024 10:16 am 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.

Xeno wrote: ↑Wed Jun 26, 2024 3:26 pm XD I withdraw my statement.

Did you make a statement?

iProgramInCpp wrote: ↑Thu Jun 27, 2024 10:18 pm

Xeno wrote: ↑Wed Jun 26, 2024 3:26 pm XD I withdraw my statement.

Did you make a statement?

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

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

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.

lambduh wrote: ↑Wed Jul 24, 2024 1:59 pm 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.

eekee wrote: ↑Tue Jul 30, 2024 4:08 am 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.

lambduh wrote: ↑Fri Aug 02, 2024 8:36 am

eekee wrote: ↑Tue Jul 30, 2024 4:08 am 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.

lambduh wrote: ↑Fri Aug 02, 2024 8:36 am 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.

eekee wrote: ↑Wed Aug 07, 2024 1:23 pm 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.

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

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...