Linked by Hadrien Grasland on Sat 5th Feb 2011 10:59 UTC
OSNews, Generic OSes So you have taken the test and you think you are ready to get started with OS development? At this point, many OS-deving hobbyists are tempted to go looking for a simple step-by-step tutorial which would guide them into making a binary boot, do some text I/O, and other "simple" stuff. The implicit plan is more or less as follow: any time they'll think about something which in their opinion would be cool to implement, they'll implement it. Gradually, feature after feature, their OS would supposedly build up, slowly getting superior to anything out there. This is, in my opinion, not the best way to get somewhere (if getting somewhere is your goal). In this article, I'll try to explain why, and what you should be doing at this stage instead in my opinion.
Thread beginning with comment 461217
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Not always rational
by Alfman on Mon 7th Feb 2011 16:17 UTC in reply to "RE[4]: Not always rational"
Alfman
Member since:
2011-01-28

Morin,

"I used to consider this a plausible approach, too. However, any shared-memory approach will make the RAM a bottleneck. It would also enforce a single shared RAM by definition."

That's a fair criticism - the shared ram and cache coherency model used by x86 systems is fundamentally unscalable. However, considering that shared memory is the only form of IPC possible on multicore x86 processors, we can't really view it as a weakness of the OS.

"This made me consider isolated processes and message passing again, with shared RAM to boost performance but avoiding excessive IPC whenever possible. One of the concepts I think is useful for that is uploading (bytecode) scripts into server processes."

I like that idea a lot, especially because it could be used across computers on a network without any shared memory.

Further still, if we had a language capability which could extract and submit the logic surrounding web service calls instead of submitting web service calls individually, that would be a killer feature of these "bytecodes".

"That would be a more elegant way to do the same as could be done with paging. On 64-bit CPUs the discussion becomes moot anyway."

See my other post as to why this isn't so if we're not using a VM for isolation, but your conclusion is correct.

Reply Parent Score: 1

RE[6]: Not always rational
by Morin on Tue 8th Feb 2011 17:12 in reply to "RE[5]: Not always rational"
Morin Member since:
2005-12-31

That's a fair criticism - the shared ram and cache coherency model used by x86 systems is fundamentally unscalable.


I was referring to the shared RAM and coherency model used by Java specifically. That one is a lot better than what x86 does, but it still makes the RAM a bottleneck. For example, a (non-nested) "monitorexit" instruction (end of a non-nested "synchronized" code block) forces all pending writes to be committed to RAM before continuing.

However, considering that shared memory is the only form of IPC possible on multicore x86 processors, we can't really view it as a weakness of the OS.


If you limit yourself to single-chip, multi-core x86 systems, then yes. That's a pretty harsh restriction though: There *are* multi-chip x86 systems (e.g. high-end workstations), there *are* ARM systems (much of the embedded stuff, as well as netbooks), and there *are* systems with more than one RAM (e.g. clusters, but I'd expect single boxes that technically contain clusters to be "not far from now").

Reply Parent Score: 2

RE[7]: Not always rational
by Alfman on Wed 9th Feb 2011 01:12 in reply to "RE[6]: Not always rational"
Alfman Member since:
2011-01-28

Morin,

"There *are* multi-chip x86 systems (e.g. high-end workstations), there *are* ARM systems (much of the embedded stuff, as well as netbooks), and there *are* systems with more than one RAM..."

Sorry, but I'm not really sure what you're post is saying?

Reply Parent Score: 1