Page 5 of 7

Posted: Wed Sep 05, 2007 7:54 am
by paul
JamesM wrote:While I would not myself use C# for OS development (nothing against anyone else, I just don't personally like it, and lack of pointers would make low-level stuff a chore) it seems a perfectly reasonable concept to me.
Just to point out: in C# you can declare methods and assemblies "unsafe" and from inside "unsafe" methods you can use pointers just as in C/C++. The only disadvantage this has is that the code can obviously no longer be verified as type safe by the JIT (or AOT in SharpOS's case) compiler.

Posted: Wed Sep 05, 2007 8:04 am
by JamesM
JamesM wrote: While I would not myself use C# for OS development (nothing against anyone else, I just don't personally like it, and lack of pointers would make low-level stuff a chore) it seems a perfectly reasonable concept to me.
Just to point out: in C# you can declare methods and assemblies "unsafe" and from inside "unsafe" methods you can use pointers just as in C/C++. The only disadvantage this has is that the code can obviously no longer be verified as type safe by the JIT (or AOT in SharpOS's case) compiler.
I consider myself correctified! I still won't be using it though :P

JamesM

Posted: Wed Sep 05, 2007 8:04 am
by Colonel Kernel
Avarok wrote:I completely agree with Crazy123; it's practically nonsensical to me.
  1. I don't think Crazed123 ever said it was nonsensical.
  2. Did you actually read the thread?

Posted: Wed Sep 05, 2007 8:37 am
by LogicalError
JamesM wrote: I consider myself correctified! I still won't be using it though :P
Pretty please? ;)

But seriously: whatever you prefer ...

Posted: Thu Sep 06, 2007 3:24 am
by Avarok
With all due respect, I mean, I'm sure you guys have put alot of work into this. I'm sure you could probably also create an OS in javascript or python, but C# is usually more or less a scripting language in that it compiles to a IL which is then actually compiled/interpreted during runtime and requires a VM, the .net platform to run.

To bring it away from programming, I'm seeing this as being similar to using a lawn mower to trim the hedge by taking the cover off, shortening the blade, removing the wheels, and building a big lifting robot so you don't have to.

Do you see what I mean. That's where the (I admit, rather offensive) comment came from. Most of us are trying to go from using a piano to trim the hedge, to using scissors, and you've hauled out the lawn mower.

:D

Posted: Thu Sep 06, 2007 5:08 am
by LogicalError
Avarok wrote:.. but C# is usually more or less a scripting language in that it compiles to a IL which is then actually compiled/interpreted during runtime and requires a VM, the .net platform to run.
I really advise you to read the documents about singularity on microsofts' site, then you'll have a better idea about what we're trying to accomplish..
Try thinking a bit more outside the box...

I could go on and on about why C# could theoretically be a lot faster than c/c++ when implemented in a certain way, but that will just result in a language flame war.. which is boring, so let's not go there.
But i'll say this; C# is definitely a full language, and not a scripting language.
It's not interpreted and doesn't require a VM.
See it this way; the last compilation phase is performed at the last moment, and -then- the application is run.
And in the case of SharpOS, it's compiled -before- it's run.. just like with C/C++.

Posted: Thu Sep 06, 2007 6:38 am
by JamesM
I could go on and on about why C# could theoretically be a lot faster than c/c++ when implemented in a certain way
Interesting... I would disagree and say that it is the algorithms inside the program (and the optimising compiler) that determine runspeed and less so the language in which it is written. Unless of course that language requires runtime interpretation. Which neither C# (in your case) or C do.

The rest of your post I quite agree on.

JamesM

Posted: Thu Sep 06, 2007 7:01 am
by LogicalError
JamesM wrote:Interesting... I would disagree and say that it is the algorithms inside the program (and the optimising compiler) that determine runspeed and less so the language in which it is written. Unless of course that language requires runtime interpretation. Which neither C# (in your case) or C do.
Yes, and the optimizing compiler could, in theory, optimize an application for a specific machine instead of for an entire generic family of machines..
The optimizing compiler can also make much more informed decisions when optimizing an application when the language is type safe, because the compiler has to guess a lot less and has to "play it safe" a lot less..

Also keep in mind that .net is somewhat slower than normal applications on windows because .net is an extra layer between the hardware and the OS and JIT compiles (=not fully optimizing) applications.
If you move the garbage collector etc. closer to hardware, remove layers etc. and fully optimize applications (like singularity does), then a C# application will most definitely not be slower compared to a C/C++ application... in fact it would actually be faster because you can guarantee that a safe C# application is, well, safe.. so you can do away with a lot of OS safety measures (for safe applications, not necesarilly for all applications) which would slow down a C/C++ application..

Ofcourse this is 'theory', we're working on the 'practice' part.

Posted: Thu Sep 06, 2007 7:59 am
by Colonel Kernel
Avarok wrote:C# is usually more or less a scripting language in that it compiles to a IL which is then actually compiled/interpreted during runtime and requires a VM, the .net platform to run.
:roll:

If you'd read the thread (and others like it), you would have seen that umpteen people have said exactly the same thing, and each time some of us have told them to Read The Papers. Uninformed opinions are less than useless here.

Posted: Fri Sep 07, 2007 8:47 am
by Avarok
Yeah, I suppose so. So it's not a scripting language, eh?

Again, I asked, is it the most suitable language to be describing things that an OS does? These things include: 16-bit vm86 mode, GDT, IDT and interrupt vectors, CR registers, PICs and port I/O, memory paging mechanisms, handling the finer points on threads and SMP...

To me, and I still stand by this, it most definitely does not seem to be the most appropriate language for that. Since it is not the pretty syntax that matters, but the semantics, I'll admit you most definitely could program an OS in javascript, python, or C#. It just won't be nearly as succinct or effective at doing so. To me, it just doesn't make sense.

Like trimming your hedge with a modified lawnmower.

That said, good luck. I'm done trolling your thread. :oops: :)

Posted: Fri Sep 07, 2007 9:02 am
by Tyler
Avarok wrote:Again, I asked, is it the most suitable language to be describing things that an OS does? These things include: 16-bit vm86 mode, GDT, IDT and interrupt vectors, CR registers, PICs and port I/O, memory paging mechanisms, handling the finer points on threads and SMP...
Well that 5% of OS Development can easily be handled by Unsafe code. Note that none of that is really OS Development, but more the specifics of he x86 Low Level. Once they are abstracted, everything can be done in C#.

Posted: Sat Sep 08, 2007 3:49 am
by Avarok
:D You bigger picture people.

I like to keep it simple. 8) I personally view it as just being the memory, port, and processor drivers.

IMHO, everything else isn't the OS, but stuff that runs on it.

Posted: Sat Sep 08, 2007 6:57 am
by AndrewAPrice
Tyler wrote:
Avarok wrote:Again, I asked, is it the most suitable language to be describing things that an OS does? These things include: 16-bit vm86 mode, GDT, IDT and interrupt vectors, CR registers, PICs and port I/O, memory paging mechanisms, handling the finer points on threads and SMP...
Well that 5% of OS Development can easily be handled by Unsafe code. Note that none of that is really OS Development, but more the specifics of he x86 Low Level. Once they are abstracted, everything can be done in C#.
Agreed. The specific low-level and bootstrapping code specific for x86 code is probably only takes up 5% of the kernel and could be done in C or assembly in the worst case scenario. Even so, claiming 95% or more of the kernel is written in C# is a major feat! From looking at their sources it seems as if they have done the memory management in C#.

I have a question. If C# is a strictly type-safe language, how does one, say, convert the address of a variable (i.e. a bool or char) into an integer? Would not C# complain "Cannot convert from bool * to int"?

Posted: Sat Sep 08, 2007 9:53 am
by Colonel Kernel
Avarok wrote::D You bigger picture people.

I like to keep it simple. 8) I personally view it as just being the memory, port, and processor drivers.

IMHO, everything else isn't the OS, but stuff that runs on it.
I think nearly everyone would disagree with that definition. Even those in the exokernel camp acknowledge that file systems, networking, scheduling, synchronization primitives, timers, etc. are all part of the OS, even if they're not part of the kernel proper.

Much to learn you still have. :)
MessiahAndrw wrote:I have a question. If C# is a strictly type-safe language, how does one, say, convert the address of a variable (i.e. a bool or char) into an integer? Would not C# complain "Cannot convert from bool * to int"?
That's exactly the thing that most people overlook -- C# is not always strictly type safe. You can turn off type safety in a method or block by using the "unsafe" keyword. In such "unsafe" blocks you can use pointers and casts, just like in C. This is what makes it more convenient for OS dev than Java, for example.

Here are some language stats from Singularity (from the MSDN Channel 9 videos): The Singularity kernel is about 2% assembler, 3% C++, and 95% Sing# (a variant of C#). 18% of the source files contain some “unsafeâ€

Posted: Sat Sep 08, 2007 11:34 pm
by AndrewAPrice
Wouldn't this then make C# the perfect language for OSdeving? (Although I'm sticking with C++ until more mature methods of low-level C# programming are developed).