Why C for operating systems
in [General Programming]
|
From: Pascal J. Bourguignon on 6 Dec 2009 19:12 "BGB / cr88192" <cr88192(a)hotmail.com> writes: > "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?... That C is not better than high level programming languages for system programming since it needs the same extensions to be effective. >> (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 ?...). Not at all. See for example Movitz, or the various Lisp Machine systems. http://common-lisp.net/project/movitz/ > 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... There's no reason why the system should be programmed the C way. All the niceties of high level languages are good for system programming too, and shouldn't be disabled. -- __Pascal Bourguignon__
From: Pascal J. Bourguignon on 6 Dec 2009 19:14 "Malcolm McLean" <regniztar(a)btinternet.com> writes: > "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. Actually, this closeness prevents the compiler to implement most optimization algorithms that high llevel programming language compilers can implement, which leads to less efficient code, as soon as you get out of the microbenchmark. -- __Pascal Bourguignon__
From: Pascal J. Bourguignon on 6 Dec 2009 19:18 "BGB / cr88192" <cr88192(a)hotmail.com> writes: [... basically that GC and big runtimes is a drag to system programming ...] Have a look at Modula-3. This is a language specifically designed for system programming and specifically including a garbage collector. And for the run-times, I don't see the point of having to rewrite printf in the kernel... If you don't have a run-time library, then you will be re-implementing it yourself. (See Greenspun's Tenth Law). -- __Pascal Bourguignon__
From: James Harris on 6 Dec 2009 19:45 On 5 Dec, 23:59, "Bill Cunningham" <nos...(a)nspam.invalid> wrote: > 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? Most answers seem to focus on C's performance. As important if not more so for operating systems programming is access to memory. C allows the programmer to do things like * manipulate pointers * decompose objects down to bytes * detect endianness For an OS writer some assembler is still needed to issue certain privileged instructions. And C does not allow some low level things like manipulation of the call and return sequence. James
From: Pascal J. Bourguignon on 6 Dec 2009 21:12
James Harris <james.harris.1(a)googlemail.com> writes: > On 5 Dec, 23:59, "Bill Cunningham" <nos...(a)nspam.invalid> wrote: > >> � � 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? > > Most answers seem to focus on C's performance. Which I disqualified in my previous answers, for at least two reasons: - the processors are so much more powerful nowdays than when C was invented. - the features of C prevent the compilers to do a good job of generating really efficient code. So really no efficiency advantage for C. > As important if not > more so for operating systems programming is access to memory. C > allows the programmer to do things like > > * manipulate pointers C pointers are limited to the bytes allocated by malloc or by the compiler (plus one undereferenceable address beyond). The usefulness of such a limited "pointer" manipulation is dubious. To be able to write a memory manager in C, you have to go beyond the language, and use implementation specific behavior. Well, in high level programming languages, if pointer manipulation is not specified, you are in the same situation than in C: you have to use implementation specific features. Therefore C offers no advantage here over the other programming languages. > * decompose objects down to bytes Indeed, this is specified by the C language (with some restrictions however, when the size of the object is not a round number of bytes). But the same can be done in other programming languages (either by specification, or with implementation specific features). Lisp Machine systems had no problem in manipulating objects down to the bytes, using implementation specific primitives. Again, no advantage to C. > * detect endianness Given the previous feature this is implementable in any programming language. The question would be why you should have to do it? Anyways, no specific advantage to C either here. > For an OS writer some assembler is still needed to issue certain > privileged instructions. And C does not allow some low level things > like manipulation of the call and return sequence. So no advantage to C either. -- __Pascal Bourguignon__ |