OSDev.org

Thanks to some comments on this site, I realized I was confused about multicore. I still am. I had thought that the L1 CPU caches were independent, but now realize they must sync themselves automatically. Anyway, multicore is still tricky but not as bad as I thought.

I redid all my device, heap and document locks using semaphores (flags) residing in their own cache line and made sure to use asm locked read-modify-write instructions and it seams okay doing disk access from different cores. The locks don't work if not in their own cache line, which is weird. I had been implementing the locks as a bit in the midst of a structure and I guess the other members of the structure got corrupted or who knows. I have no idea if there is a risk of the remainder of the structures controlling disks and stuff getting out-of-sync. Maybe, I need the fence instruction or the CLFLUSH.

The cool thing is, I added a #prefetch compiler directive. (I wrote my own compiler)

Now, in my start-up scripts or makefile scripts, you place #prefetch and the other core goes to work loading and uncompressing and hands the result to the main core when it comes to a #include. I shaved maybe 5-10% off of my compile and boot times.

Sooo, your point? What's the point of creating a topic if you're not showing anything majorly new?

LoseThos wrote:Thanks to some comments on this site, I realized I was confused about multicore. I still am.

On another thread:

01000101 wrote:Maybe you should cut back on the ego, and invest some more thought/time/code into your OS...

Troy: I think that LoseThos is taking e's advice. And getting a 5-10% speedup in compile time as well as modifying semaphores is noteworthy, IMHO.

Yeah, I'm in the real mode zone, not doing ANYTHING with p or long mode...

The BIOS is my crack.

Ummm... that's just part of one makefile. The news is that the compiler now uses multicore with the help of hints to prefetch and uncompress stuff. It now boots in 1.50 seconds, down from 1.85 seconds. During boot, 40,000 lines of code are compiled. It will compile the other 40,000 lines of code in 0.89 seconds, down from maybe 1.00 seconds.

LoseThos is exclusively 64-bit, runs of bare metal and does not use the BIOS in normal operation. (Makes one call to set VGA mode and another to get amount of memory during booting.)


MultiCore is not exactly trivial to use. The locks must be isolated in a cache line to work. I'm not exactly sure what goes on, but I think if you modify other values in the same cache line, it is incapable of merging changes to the same cacheline simultaneously.

Basically, the news is that LoseThos is more like SMP, but my goal is not SMP. You can do disk access from other cores, now. Still the main use of LoseThos is video games and the main thing multicore will do is help render the graphics. Before, you could only do very limited things with multicore.


As for my ego? When you guys write your own 64-bit compiler and operate in 64-bit mode, then we can talk.

LoseThos wrote:When you guys write your own 64-bit compiler and operate in 64-bit mode, then we can talk.

That's just a bit egotistic. 01000101's OS is in long mode, and he's no better than us. Although he is sort of our resident network wizard.

LoseThos wrote:Ummm... that's just part of one makefile. The news is that the compiler now uses multicore with the help of hints to prefetch and uncompress stuff. It now boots in 1.50 seconds, down from 1.85 seconds. During boot, 40,000 lines of code are compiled. It will compile the other 40,000 lines of code in 0.89 seconds, down from maybe 1.00 seconds.

LoseThos is exclusively 64-bit, runs of bare metal and does not use the BIOS in normal operation. (Makes one call to set VGA mode and another to get amount of memory during booting.)


MultiCore is not exactly trivial to use. The locks must be isolated in a cache line to work. I'm not exactly sure what goes on, but I think if you modify other values in the same cache line, it is incapable of merging changes to the same cacheline simultaneously.

Basically, the news is that LoseThos is more like SMP, but my goal is not SMP. You can do disk access from other cores, now. Still the main use of LoseThos is video games and the main thing multicore will do is help render the graphics. Before, you could only do very limited things with multicore.


As for my ego? When you guys write your own 64-bit compiler and operate in 64-bit mode, then we can talk.

Locks are implemented to give mutual exclusion to a given processor so that it may operate on a critical region without interference from the other tasks being performed by the other processors. For the cache-line info, it is necessary to use synchronization in some cases (spinlocks being one of them iirc) as they make sure all the cache-line code has been executed and a barrier is formed so that the following command executes in-order as opposed to its normal out-of-order operations.

My OS is 64-bit (long mode) and while it was difficult to code, it was no great feat over the difficulty of just designing an OS to begin with. Even if you design a fantastic OS with a great GUI and hardware support, I still wouldn't think that a large ego would be appropriate. I have accomplished a relatively large amount and am moving into the business portion of OS development, but I still realize that I have a very long way to go and do not dwell on my past achievements as it would distract me from the next task.

Well, that's enough of that rant, I don't think I'll be posting any more on the topic (unless of course there is an actual programming question I can answer).

As for my ego? When you guys write your own 64-bit compiler and operate in 64-bit mode, then we can talk.

So, what's with refusing to listen to me as I have most certainly met those criterion. Should i quote everybody else here because you refuse to listen to them because they're less worthy?

They're right about your ego, its very annoying - they're right about your locking code, you should try to get down the basics of computation order.

Lets say that when your OS can program a GPU we can discuss this further. Yes i know your OS will always run in 640x480x16 VGA, but as I said there is no discussion until the criterium is met. Nice remark, isn't it?

Think about it, do you want your stuff tested, or do you want to be confronted about your ego time and time again?

LoseThos wrote:As for my ego? When you guys write your own 64-bit compiler and operate in 64-bit mode, then we can talk.

That is simply rude. You are not the only person to do both, you know. Drop the ego already.

(Besides that, your system is not very good for a gaming OS anyways.)

Maybe you guys should cut him some slack. If you keep jumping at him as soon as he posts, although he doesn't necessarily say anything bad, you're the trolls. Jeez... And there was no "programming question" to answer because this is the announcements thread.

Love4: Combuster's smacked him with the banhammer, he won't reply anymore.

Troy Martin wrote:Love4: Combuster's smacked him with the banhammer, he won't reply anymore.

Hmm... Where can I see who's banned and who's not?

I don't know, but Combuster announced it here: http://forum.osdev.org/viewtopic.php?f= ... 15#p145735

Troy Martin wrote:I don't know, but Combuster announced it here: http://forum.osdev.org/viewtopic.php?f= ... 15#p145735

Ah, I see. Nevermind my previous post; he should have been banhammered earlier