Why C for operating systems
in [General Programming]
|
From: James on 6 Dec 2009 23:28 "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message news:87ws0zfxgf.fsf(a)galatea.local... > "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. Garbage collected bootloader and Kernel? Can I really use Haskell or Modula-3 to create that? What about a garbage collected Kernel with exceptions that beats the heck out of a Kernel written in CO and assembly language? Is that possible? > 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). Are you saying that I can take an existing C runtime and use it in the Kernel as-is? BTW, what language is the runtime for Haskell or Modula-3 generally written in? Can I write a high-performance JVM in Logo?
From: James on 6 Dec 2009 23:33 "James" <no(a)spam.invalid> wrote in message news:hfi073$3q8$1(a)aioe.org... > "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message > news:87ws0zfxgf.fsf(a)galatea.local... >> "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. > > Garbage collected bootloader and Kernel? Can I really use Haskell or > Modula-3 to create that? What about a garbage collected Kernel with > exceptions that beats the heck out of a Kernel written in > CO and assembly language? Is that possible? ^^^^^^^^^^^^ That should read as: C and assembly language? Is that possible?
From: BGB / cr88192 on 7 Dec 2009 02:42 "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message news:87skbnfs6r.fsf(a)galatea.local... > 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. > and, this is, irrelevant... by this reasoning, data compression would also have no reason to exist anymore, since we have so much more RAM and HD space... just because there are more clock cycles does not mean programmers are free to needlessly waste them, as it does not take long before one finds themselves writing code where speed does actually matter... > - the features of C prevent the compilers to do a good job of > generating really efficient code. > vs, what? and under which exact criteria?... for example, for some kinds of tasks, for example, a pure functional language can beat out something like C performance-wise, granted... does this excuse its inability to be used for the majority of programming tasks?... the main practical competitors to C (and C++) are Java and C#, and neither has managed to "generally" beat out C performance-wise (often, it is carefully crafted Java vs poorly or naively written C). nearly all others have to little weight to really be worth consideration. > So really no efficiency advantage for C. > depends on the specifics... granted, in practice it is better at optimizing the memory footprint than of raw performance (if written by someone who has some idea what they are doing...). this is where it shows through most, as, most of its main competitors run through memory like it was nothing... > >> 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. > so, the point being?... purely standard C is too restrictive to do much of anything interesting, but little is to stop people from doing them. > 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. > except that, these "implementation specific" behaviors are far more standard in C than in most other languages... the standard doesn't say some things, but we know them regardless... > >> * 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. > so says you... > >> * 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. > C offers lots of different ways to detect endianess... granted, for what it matters, in many cases we can ignore this whole issue anyways, since one can also know with a reasonable level of accuracy that whatever system runs their code is going to be x86 based... > >> 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. > there are advantages, since the need for a few random ASM fragments here in there for more advanced tasks hardly gets in the way of most projects... FWIW, most people have much bigger issues to worry about...
From: BGB / cr88192 on 7 Dec 2009 02:46 "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message news:871vj7hc8l.fsf(a)galatea.local... > "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. > this is why it matters that people have to know what they are doing... if someone writes stupid code and it performs poorly, it is their fault, not the compiler's... it also helps to know some about how ASM works and how the compiler they are using does its optimization (since, as I have observed, some things which work well in GCC don't work as well in MSVC, and the inverse is also true, but either way, it is not too difficult to get fairly good general-case behavior...). > -- > __Pascal Bourguignon__
From: BGB / cr88192 on 7 Dec 2009 03:04
"Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message news:87638jhcao.fsf(a)galatea.local... > "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. > not really, since most of these "extensions" are part of the core language by default, and so not seen as extensions by those using the language. for example, pointer arithmetic, ... is just another part of the job... > >>> (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/ > too late to look into this for now... > >> 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. > they would need to be disabled in order to be able to get the language to be able to bootstrap itself... for example, you can't use the GC before the GC is operational, and you can't use the GC for the code implementing the GC. this much is essentially a hard limit. such a restricted subset is then needed, and the system can switch to a more full-featured form only after bootstrapping... this would be analogous to how C usually requires a runtime library to be written before one can use the runtime library. granted, it can be noted that one can write pretty much the entire runtime library (apart from a few small pieces) in C. any language capable of doing similarly also needs to be able to do similarly. while this allows an implementation of a language designed for the task, it does not allow one not designed for this... for example, system programming in Java would be possible, but apart from a specialized compiler with a lot of extensions, one would need a fairly large amount of ASM (maybe 10-15 kloc?...) to be able to essentially bootstrap the language (such as the garbage collector, core language facilities, OO and Interface machinery, ...). why is it then that, in such efforts, it is far more common to bootstrap Java via C?... granted, Java is a poor example of a non-C HLL, but FWIW, it is about the only one at present which poses that much of a threat... nearly everything else has become marginal... > -- > __Pascal Bourguignon__ |