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.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.
.Net OS
I consider myself correctified! I still won't be using it thoughJust 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.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.
JamesM
- Colonel Kernel
- Member
- Posts: 1437
- Joined: Tue Oct 17, 2006 6:06 pm
- Location: Vancouver, BC, Canada
- Contact:
Avarok wrote:I completely agree with Crazy123; it's practically nonsensical to me.
- I don't think Crazed123 ever said it was nonsensical.
- Did you actually read the thread?
Top three reasons why my OS project died:
- Too much overtime at work
- Got married
- My brain got stuck in an infinite loop while trying to design the memory manager
-
- Posts: 12
- Joined: Wed Sep 05, 2007 6:10 am
- Location: capelle aan den ijssel, the netherlands
- Contact:
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.
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.
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.
- C. A. R. Hoare
- C. A. R. Hoare
-
- Posts: 12
- Joined: Wed Sep 05, 2007 6:10 am
- Location: capelle aan den ijssel, the netherlands
- Contact:
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..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.
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++.
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.I could go on and on about why C# could theoretically be a lot faster than c/c++ when implemented in a certain way
The rest of your post I quite agree on.
JamesM
-
- Posts: 12
- Joined: Wed Sep 05, 2007 6:10 am
- Location: capelle aan den ijssel, the netherlands
- Contact:
Yes, and the optimizing compiler could, in theory, optimize an application for a specific machine instead of for an entire generic family of machines..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.
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.
- Colonel Kernel
- Member
- Posts: 1437
- Joined: Tue Oct 17, 2006 6:06 pm
- Location: Vancouver, BC, Canada
- Contact:
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.
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.
Top three reasons why my OS project died:
- Too much overtime at work
- Got married
- My brain got stuck in an infinite loop while trying to design the memory manager
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.
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.
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.
- C. A. R. Hoare
- C. A. R. Hoare
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#.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...
You bigger picture people.
I like to keep it simple. 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 like to keep it simple. 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.
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.
- C. A. R. Hoare
- C. A. R. Hoare
- AndrewAPrice
- Member
- Posts: 2298
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
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#.Tyler wrote: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#.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...
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"?
My OS is Perception.
- Colonel Kernel
- Member
- Posts: 1437
- Joined: Tue Oct 17, 2006 6:06 pm
- Location: Vancouver, BC, Canada
- Contact:
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.Avarok wrote: You bigger picture people.
I like to keep it simple. 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.
Much to learn you still have.
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.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"?
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â€
Top three reasons why my OS project died:
- Too much overtime at work
- Got married
- My brain got stuck in an infinite loop while trying to design the memory manager
- AndrewAPrice
- Member
- Posts: 2298
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
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).
My OS is Perception.