Why C for operating systems
in [General Programming]
|
From: BGB / cr88192 on 8 Dec 2009 17:39 "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message news:87iqchb2a6.fsf(a)galatea.local... > Daniel Pitts <newsgroup.spamfilter(a)virtualinfinity.net> writes: > >> Bill Cunningham wrote: >>> "cbcurl" <cbcurl(a)gmail.com> wrote in message >>> news:679a89c3-8396-4672-95ce-58b37558b8f2(a)g7g2000yqa.googlegroups.com... >>> On Dec 7, 8:16 pm, p...(a)informatimago.com (Pascal J. Bourguignon) >>> wrote: >>> >>>> Don't be silly, markup languages are not programming languages. >>> They can be. Curl is a programming language that can also be used as >>> a >>> markup language. >>> What is Curl? Now I've never heard of that. I thought TCL/TK >>> might be mentioned in writing OSs but maybe not. I have never used >>> tcl/tk so I can't comment on it. It's interpreter driven anyway so >>> neither it nor perl could be used for writing OSs. >> >> I think you are confusing OS with kernel. The core of a kernel must >> be a compiled language, > > Why? > > Actually, Apple is known to sell kernels that are interpreted. Well, > I mean kernels compiled for one processor running on an emulator for a > new processor. And Apple is not alone and not the first. Another > example, in 1983, I worked on a computer that emulated an older > computer as software running on microprocessors. The system and all > the applications were just being interpreted all the time. > > There's no fundamental difference between a virtual machine and an > "interpreter", and there's no fundamental reason why the kernel > should run on "native" code, it could very well include an interpreter > and be interpreted. > > In fact, a lot of kernels do. For example, kernels running > openfirmware drivers are interpreting them. > agreed on this point... I had looked some at EFI bytecode as a possibility for interpreted C prior to settling on x86. the main downside, then, of EFI bytecode, was that it didn't support floating point or SIMD (well, and it did addressing in a way where I was unsure if it could deal with arbitrary datastructures...). I had tried, via specs, for several attempts to expand on EFI bytecode to create a more general purpose bytecode, and ended up with a result that looked about like x86 with different instruction encodings, and soon enough ended up just using x86 as I realized it would be less effort... an issue does come up fairly quickly though: the simulated app and host app run in different address spaces, which is an issue not shared by most other bytecodes. I also soon ran into the problem that direct interaction between code running in different address spaces is not nearly so easy to gloss over as I had originally thought, ... > >> but nothing says the rest of an operating >> system (or even the rest of the kernel) must be compiled. In theory, >> it would be relatively easy to bootstrap an interpreter or VM, and run >> non compiled-code for the rest of the OS operations. >> >> An OS is a collection of many components that let the user use the >> computer. If you interpret that definition wide enough, any >> application that is installed on the computer becomes part of the OS. > > Machines running on machines running on machines... > yep... one may also find that, often times problems are never really solved, they are just layered. the hardware deals with problems, the OS deals with problems, and the application deals with the same problems... in some cases, the line between hardware and software blurs, as one may find that a few pieces of "hardware" in their computer are actually just software running on a mini-processor in their bus controller (meaning that even their real computer is not altogether different than the nearly entirely fake computer existing in something like DOSBox / QEMU / Bochs / ...). or something... > -- > __Pascal Bourguignon__
From: Patricia Shanahan on 8 Dec 2009 18:03 Bill Cunningham 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? UNIX was in the right place at the right price at the right time, and that led to a whole series of network effects, including a generation of system programmers who have used C throughout their careers. In the 1980's, there was a flowering of processor ideas. The start-up companies and projects implementing them had neither the time nor the resources to write an operating system from scratch. The UNIX license fees were a tiny fraction of the cost of developing an OS. UNIX was written in C. If the easily-licensed high level language OS at that time had been implemented by Burroughs rather than Bell Labs, my first task as languages project leader at Celerity Computing in 1983 would have been a functionally correct Algol compiler, and you would probably have asked why Algol is so good for operating systems. Patricia
From: Daniel Pitts on 8 Dec 2009 18:35 Pascal J. Bourguignon wrote: > Daniel Pitts <newsgroup.spamfilter(a)virtualinfinity.net> writes: > >> Bill Cunningham wrote: >>> "cbcurl" <cbcurl(a)gmail.com> wrote in message >>> news:679a89c3-8396-4672-95ce-58b37558b8f2(a)g7g2000yqa.googlegroups.com... >>> On Dec 7, 8:16 pm, p...(a)informatimago.com (Pascal J. Bourguignon) >>> wrote: >>> >>>> Don't be silly, markup languages are not programming languages. >>> They can be. Curl is a programming language that can also be used as >>> a >>> markup language. >>> What is Curl? Now I've never heard of that. I thought TCL/TK >>> might be mentioned in writing OSs but maybe not. I have never used >>> tcl/tk so I can't comment on it. It's interpreter driven anyway so >>> neither it nor perl could be used for writing OSs. >> I think you are confusing OS with kernel. The core of a kernel must >> be a compiled language, > > Why? > > Actually, Apple is known to sell kernels that are interpreted. Well, > I mean kernels compiled for one processor running on an emulator for a > new processor. And Apple is not alone and not the first. Another > example, in 1983, I worked on a computer that emulated an older > computer as software running on microprocessors. The system and all > the applications were just being interpreted all the time. > > There's no fundamental difference between a virtual machine and an > "interpreter", and there's no fundamental reason why the kernel > should run on "native" code, it could very well include an interpreter > and be interpreted. > > In fact, a lot of kernels do. For example, kernels running > openfirmware drivers are interpreting them. > > >> but nothing says the rest of an operating >> system (or even the rest of the kernel) must be compiled. In theory, >> it would be relatively easy to bootstrap an interpreter or VM, and run >> non compiled-code for the rest of the OS operations. >> >> An OS is a collection of many components that let the user use the >> computer. If you interpret that definition wide enough, any >> application that is installed on the computer becomes part of the OS. > > Machines running on machines running on machines... Right, but the top-most "machine" in the system runs the top-most kernel of the operating system. Even if the kernel itself is just the interpreter or emulator. -- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Moi on 9 Dec 2009 08:21 On Mon, 07 Dec 2009 06:29:36 -0800, Chris M. Thomasson wrote: > "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message [snip] > > Try to convince Linus Torvalds that a full-blown GC in the Kernel would > be better and more efficient than using the RCU algorithm. > Has been done in one of the linux newgroups around 1995; "C++ is so much more modern. C is oldfashoned, blabla". Linus is an excellent flamer ;-) AvK
From: Walter Banks on 9 Dec 2009 09:50
"Pascal J. Bourguignon" wrote: > 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. > > But other programming languages have good bit manipulation primitives > too, and the C language doesn't allow you actually to access hardware > registers. If you read closely the C standard, you'll see that > there's no standard way to access random memory addresses, or for > example ix86 I/O port (using the INP and OUT instructions). It's even > much less possible in C to access the status register, whose > manipulation is essential when you write an operating system. > > For all these low level processor and hardware accesses, you have to > use assembler, even when you're programing the rest in C, like in most > other programming languages. 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. The above paragraphs outline some of the biggest missing low level capabilities of C. We have implemented a bunch of C compilers primarily targeted to low level programming on non hosted embedded systems. Compiler implementation can go a long way to make some of these language issues not particularly significant. ISO/IEC 18037 addressed how C could be reasonably extended to support low level processor access and multiple memory spaces. 1) Multiple address spaces can be implemented as a single virtual address space mapped on the multiple address spaces natural to the processor and stay within the the C definition. 2) Specialized calls (syscalls, SWI's, limited range calls,interrupts) can all be mapped by a compiler on normal C syntax for functions. Some cases may require pragma's or modifiers as part of the declaration but the rest can be managed by the compiler. No language changes needed. 3) Access to the processor status register. This is not available in a standard way with the C standard. This single change to the language can effectively eliminate the need for asm in C applications. We added an extension to access the status register to several of our compilers and found that we could then write a C statement for every asm instruction and it would compile to a single instruction. (Anything that could be written in asm could then be written in C) The implementation essentially turned the status register into a structure of condition code bits. 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. The points are well taken. C was designed as an implementation language and may not be the most appropriate language to express some applications. All the best of the season, Walter.. -- Walter Banks Byte Craft Limited http://www.bytecraft.com |