Why C for operating systems
in [General Programming]
|
From: Pascal J. Bourguignon on 6 Dec 2009 17:47 "Bill Cunningham" <nospam(a)nspam.invalid> writes: > "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. Which just proves my point. (In most other system programming languages or implementations, it is also possible to insert short assembler routines in the same source, eg. in MPW Pascal or in SBCL Common Lisp). -- __Pascal Bourguignon__
From: Pascal J. Bourguignon on 6 Dec 2009 17:51 "Bill Cunningham" <nospam(a)nspam.invalid> writes: > "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. Yes, all the functions in man2 are written in assembler, not in C, because they reduce basically to a syscall that is not specified by the C language. You cannot write in C a declaration such as: system call 3 int read(int,void*,int); At most what you can do is to implement it in assembler. -- __Pascal Bourguignon__
From: Malcolm McLean on 6 Dec 2009 17:54 "Bill Cunningham" <nospam(a)nspam.invalid> wrote in message news: > One reason why I am so attracted to C and not just markup languages > scripts and java is that C is for designing OS's. What exactley is it > about C that makes it good to right operating systems? > It's very close to assembler. With a few exceptions, all C constructs compile to a few machine language instructions. So it's easy in C to keep control of how much time your program is taking to execute. Since operating systems have to be efficient, this is very valuable.
From: BGB / cr88192 on 6 Dec 2009 18:40 "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message news:87my1vhg9n.fsf(a)galatea.local... > "Bill Cunningham" <nospam(a)nspam.invalid> writes: > >> "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. > > Which just proves my point. > then one can ask: which point?... > > (In most other system programming languages or implementations, it is > also possible to insert short assembler routines in the same source, > eg. in MPW Pascal or in SBCL Common Lisp). > granted, but there is a bit of a difference between "well, these other languages can do X task" and "any language can do X task" (with an implied level of equality). in most cases, what one compiles is usually a subset (of the main language) and a superset (for certain low-level facilities). in C, this means most (if not all) of the standard runtime (apart from maybe those parts one writes themselves, which in C's case can usually be written entirely or almost entirely in C). some other languages have implementations which can do similar, and the level of divergence (from the main language) would be greater or lesser. for CL, likely the variant which could be used effectively for system programming would diverge in many ways from the main version (such as lacking list-handling and placing restrictions on function scope behavior / absence of lexical closures ?...). in C, however, this divergence is minimal, and does not effect the core language, whereas for some others, much more divergence may be necessary. for example, if ActionScript were adapted to system programming, and made to be effective at doing so, apart from syntax the language would likely be almost unrecognizable (one suddently finding themselves using a C-like language passing itself off as AS). "what do you mean this language is statically-typed and has pointers and only statically-visible scope is allowed?...". similarly for the Java example: one would either need a Java variant (adding in many built-in facilities and a special set of restrictions for low-level tasks), or a big glob of support machinery, just to keep the thing from collapsing (even if statically compiled to native code). it is not much at all equal...
From: BGB / cr88192 on 6 Dec 2009 19:06
"Malcolm McLean" <regniztar(a)btinternet.com> wrote in message news:xdedne8L8NaLq4HWnZ2dnUVZ8vudnZ2d(a)bt.com... > "Bill Cunningham" <nospam(a)nspam.invalid> wrote in message news: >> One reason why I am so attracted to C and not just markup languages >> scripts and java is that C is for designing OS's. What exactley is it >> about C that makes it good to right operating systems? >> > It's very close to assembler. With a few exceptions, all C constructs > compile to a few machine language instructions. So it's easy in C to keep > control of how much time your program is taking to execute. > Since operating systems have to be efficient, this is very valuable. > agreed... this is the most sense in this thread thus far. granted, the tranlation is not as simple as this would seem to imply, as probably most who have written C compilers would likely agree to. however, C does matches fairly closely with the capabilities of raw ASM, and so the need for any kind of support machinery to be able to run standalone is minimal, also making it fairly nice for things like kernel development. if one knows what they are doing, it is also fairly straightforwards to address matters of keeping the memory footprint small (since raw pointers and a byte-centric worldview make it easier to address such matters), ... these kinds of performance also matter a lot in backend library code, where slow frontend code is often far less problematic than a slow library backend or API call. if, for example, a frontend function takes 10us to execute, no one may notice. if a backend API call takes even 1us, it can potentially kill the overall performance of an app which uses it (and it may well be the case that the person writing the app can do little to address this, for example, because they neither have access to the code for the library, nor the means to otherwise simulate the operation...). .... > |