Why C for operating systems
in [General Programming]
|
From: gremnebulin on 11 Dec 2009 08:41 On 10 Dec, 23:44, "Charles E. Bortle, Jr." <charlesb....(a)mpowercom.net> wrote: > "Pascal J. Bourguignon" <p...(a)informatimago.com> wrote in messagenews:873a3ld6jm.fsf(a)galatea.local... > Which comes back to the OP's question: is C > a reasonable choice for OS implementaion. > IMVHO Pascal or other ALGOL-like language > would be clearer to follow and debug if the > compiler for said implements a "bare-bones code" > code generator. I just surfed up an Algol-like language for LLP http://en.wikipedia.org/wiki/Mary_(programming_language)
From: Pascal J. Bourguignon on 11 Dec 2009 19:36 Walter Banks <walter(a)bytecraft.com> writes: > Once low level access was available we found that DSP programs > could be written in C and take advantage of the compiler optimization > and data management. This is good. The same of course can be and has been done for compilers of other programming languages. This kind of modification of the language is something that is useful for all applications, not only for low level processor access. In any application domain, you may need to have some domain specific language extensions in the compiler. That's where Lisp shines: you can easily modify or extend the lisp language, from user code, without a need to modify and recompile the compiler itself, thanks to the metalinguistic features and homoiconicy of lisp. The best you can do in C, if you want to avoid patching the compiler (or if you want to make a extension that works with several C compilers), is to provide a pre-processor (for example, Objective-C, C++, Pro*C, etc (of course, nowadays, Objective-C and C++ have been integrated as front ends to gcc)). This is nice, but the problem with front ends, is that it is more work to implement than a simple lisp macro... With a front end in general you still have a lot of parsing work to do, to integrate well your extensions. And it is difficult to combine various front ends. There's no Pro*Objective-C, or MyFront*Pro*C. On the other hand, you can easily mix and match macros from different libraries in lisp. But I guess we're moving away from the subject. -- __Pascal Bourguignon__
From: Pascal J. Bourguignon on 11 Dec 2009 19:43 "Charles E. Bortle, Jr." <charlesb.cca(a)mpowercom.net> writes: > But I would add two wrinkle to your statment. > You could write an OS in, say, Pascal, but the > general implementation of the Pascal language, > at least the implementations I have used, do not > produce stand-alone code for a bare CPU, which > is often the platform in view when "OS" is mentioned. > I would qualify Any Programming Language and > say any General Purpose Programming Language > (Of course, that is really the Turing definition) The important point here is that it is not a question of language, but a question of implementation. Apple had no difficulty to write their system in Pascal. (Ok, the MacOS "kernel" was written in 68000 assembler, only the "Toolbox" was written in Pascal). There's also the question of "standard library", which may be thought of as non optional and pose problems in a barebone implementation, but it should not, really. Even the current C standard specifies a "standard library", which you have to ignore when writing a unix kernel. Modula-2 would be the most barebone language I know (and I guess Oberon is similar). -- __Pascal Bourguignon__
From: Pascal J. Bourguignon on 11 Dec 2009 19:46 Moi <root(a)invalid.address.org> writes: > On Thu, 10 Dec 2009 15:34:14 -0800, Charles E. Bortle, Jr. wrote: > >> "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message >> news:87aaxtb20j.fsf(a)galatea.local... >>> "Bill Cunningham" <nospam(a)nspam.invalid> writes: > >> >> This is a very interesting thread :-) > It is, indeed! > >> >> My personal view is that C does not have any advantage, and has some >> drawbacks, when it comes to system level programming (I have only used C >> a little). I feel Pascal really would be better in terms of the clarity >> of the code, if a Pascal implementation provided "bare-bones code" > > IMHO the advance of C over Pascal in this respect is that it ignores I/O. > I/O just needs OS and machine specifics, and has to be implemented in > asm or machine code. This keeps the language small and the system-specific > stuff constrained to the libraries. Lean and mean. Indeed. But I can assure you that in the ROM of the Macintosh, there was no writeln. Specifying an I/O library doesn't prevent you to implement a compiler able to generate kernel level code. > The other advantage is that the Pascal "record" structure is too rigid. > And circumventing it is tedious, even more tedious than with C's > typecasting and struct hacks. C allows one to restrict the ugliness to > only a few parts of the code. But it is easy to control every bit in the > address space, without too much hassle. > > Also: an OS is a resource manager. It manages clock tics, memory pages, > disk pages, files, processes, threads, and maybe a few more. Having GC or > disk-block management embedded into the language would probably complicate > things even more. (Yes, I know Pascal does not have GC) But to manage resources, you have to use resources too. There are kernel memory managers in unix kernels. It really doesn't matter much, it's just layered more or less virtual machines. -- __Pascal Bourguignon__
From: bartc on 11 Dec 2009 20:33
"Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message news:87ocm59gf8.fsf(a)galatea.local... > Walter Banks <walter(a)bytecraft.com> writes: > >> Once low level access was available we found that DSP programs >> could be written in C and take advantage of the compiler optimization >> and data management. > > This is good. > > The same of course can be and has been done for compilers of other > programming languages. > > > This kind of modification of the language is something that is useful > for all applications, not only for low level processor access. In any > application domain, you may need to have some domain specific language > extensions in the compiler. That's where Lisp shines: you can easily > modify or extend the lisp language, from user code, without a need to > modify and recompile the compiler itself, thanks to the metalinguistic > features and homoiconicy of lisp. But there's a steep learning curve for Lisp. Before you can do much with it, you have to confront difficult ideas that in other languages you may not have to bother with for years, if ever. (For example, what on earth do metalinguistic and homoiconicy mean; I'm sure these never came up in K&R2) > But I guess we're moving away from the subject. I guess so. -- Bartc |