Why C for operating systems
in [General Programming]
|
From: Chris M. Thomasson on 6 Dec 2009 15:49 "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message news:878wdgiedq.fsf(a)galatea.local... [...] > If you want to write an operating system, I'd advise Common Lisp, > Scheme, Modula-3, Oberon, Haskell, or design your own high level > programming language like BitC (http://www.bitc-lang.org/) in the > CoyotOS project (http://www.coyotos.org). You forgot Visual Basic! BTW, can I do an x86 bootloader in Haskell?
From: Pascal J. Bourguignon on 6 Dec 2009 16:19 "Chris M. Thomasson" <no(a)spam.invalid> writes: > "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message > news:878wdgiedq.fsf(a)galatea.local... > [...] >> If you want to write an operating system, I'd advise Common Lisp, >> Scheme, Modula-3, Oberon, Haskell, or design your own high level >> programming language like BitC (http://www.bitc-lang.org/) in the >> CoyotOS project (http://www.coyotos.org). > > You forgot Visual Basic! BTW, can I do an x86 bootloader in Haskell? You can do it as well as in C. In both case, you will have to generate some assembly. Squeak would be a good example here of what I mean. This whole Smalltalk system is entirely written in Smalltalk. Including a small bootstrapping translator that will compile a subset of Smalltalk to some assembler so that it can boot on an existing platform. The same technique can be applied to boot loaders and similar parts, and for any programming language. -- __Pascal Bourguignon__
From: Bill Cunningham on 6 Dec 2009 16:40 "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message news:878wdgiedq.fsf(a)galatea.local... > Now the general belief is that C is good for OS because it has bit > manipulation instructions, and allows you to access the hardware > registers of the computer. That's what I've always believed but I've never actually felt like I was working with literal addresses and values but but looking at the kernel's virtual addresses applied to physical addresses and I am assuming posix has in its standard (written in C too) protection of kernel space virtual addresses. If not at the posix user space level then in the kernel source. [snip] .. Even something as fundamental as the > system calls, just cannot be programmed in C, you have to write the > syscalls in assembler, because they are not a normal "jump subroutine" > instruction. You mean posix's read() and write() open() creat() and close() syscalls are not written in C? I've used these directly several times and bypassed C's fwrite, fopen and fread functions when using a posix system. Bill
From: Bill Cunningham on 6 Dec 2009 16:49 "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message news:87r5r7hkb8.fsf(a)galatea.local... > "Chris M. Thomasson" <no(a)spam.invalid> writes: > >> "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message >> news:878wdgiedq.fsf(a)galatea.local... >> [...] >>> If you want to write an operating system, I'd advise Common Lisp, >>> Scheme, Modula-3, Oberon, Haskell, or design your own high level >>> programming language like BitC (http://www.bitc-lang.org/) in the >>> CoyotOS project (http://www.coyotos.org). >> >> You forgot Visual Basic! BTW, can I do an x86 bootloader in Haskell? > > You can do it as well as in C. In both case, you will have to > generate some assembly. > > Squeak would be a good example here of what I mean. This whole > Smalltalk system is entirely written in Smalltalk. Including a small > bootstrapping translator that will compile a subset of Smalltalk to > some assembler so that it can boot on an existing platform. The same > technique can be applied to boot loaders and similar parts, and for > any programming language. Isn't there a way in C to write assembly? I've never done it but I have seen macros like __ASM__ which maybe a system macro I don't know, because of the two leading and trailing underscores. And I don't mean just bypassing the linker and assembler to just compile into assembly I mean C code and assembly mixed in the same program. Bill
From: BGB / cr88192 on 6 Dec 2009 17:41
"Bill Cunningham" <nospam(a)nspam.invalid> wrote in message news:4b1c24b4$0$5361$bbae4d71(a)news.suddenlink.net... > > "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message > news:878wdgiedq.fsf(a)galatea.local... > >> Now the general belief is that C is good for OS because it has bit >> manipulation instructions, and allows you to access the hardware >> registers of the computer. > > That's what I've always believed but I've never actually felt like I > was working with literal addresses and values but but looking at the > kernel's virtual addresses applied to physical addresses and I am assuming > posix has in its standard (written in C too) protection of kernel space > virtual addresses. If not at the posix user space level then in the kernel > source. > > [snip] > > . Even something as fundamental as the >> system calls, just cannot be programmed in C, you have to write the >> syscalls in assembler, because they are not a normal "jump subroutine" >> instruction. > > You mean posix's read() and write() open() creat() and close() syscalls > are not written in C? I've used these directly several times and bypassed > C's fwrite, fopen and fread functions when using a posix system. > well, they are C, in the kernel. but, what happens generally is that these usually make use of a small chunk of assembler which initiates the system call (via special CPU instructions, with the exact instructions used depending some on the OS), and once stably in kernel space, control is passed back into the C code in the kernel (usually, at this point, it will attempt to transfer any argument data between address spaces, and dispatch to the correct system-call handling code). once in the kernel though, nearly all of the logic is in C, just a few small pieces of ASM are used for transferring between address spaces (or, between processes or threads, ...). so, the 'read' seen in a user app may be little more than some code for marshalling the arguments into a buffer and/or putting some stuff in registers, and then initiating a transfer into the kernel (AKA: a stub or a thunk). this is much the same as how one can generate closures in C, or handle calling an arbitrary function indirectly and with arbitrary arguments (such as via a "reflection" API, ...): it can be done, but not in pure C, as it requires a few chunks of assembler (possibly dynamically generated) to pull it off... > Bill > > |