Why C for operating systems
in [General Programming]
|
From: BGB / cr88192 on 9 Dec 2009 13:33 "Walter Banks" <walter(a)bytecraft.com> wrote in message news:4B1FB950.61EE09BA(a)bytecraft.com... > > > "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, > yep... all this is much how like one can make use of a lot of nifty CPU features (such as SIMD, ...) via compiler intrinsics, although granted the intrinsics are not standardized (for example, GCC and MSVC using different intrinsics, or possibly a compiler lacking them). in my case, then, I ended up wrapping the intrinsics via macros and inline functions, essentially to produce an API for relatively-high-performance vector math, and which looks from the C side a good deal like GLSL (but with more features). granted though, for the most part most of my codebase still uses the good old "array of floats" strategy, leaving SIMD mostly for areas where performance is being an issue (since it does manage to be faster). elsewhere, where I have used ASM, it has been to wrap some CPU instructions, such as rdtsc, ... (or, amusingly, 'sqrtss', since MSVC provides an rather slow implementation of 'sqrt', and much performance can be gained simply my using a function which directly uses the CPU instruction instead). OTOH, GCC does a better job with sqrt, since it has the idea of using it as a compiler builtin which uses either SIMD or the FPU, depending on settings (rather than some API call sitting around doing bit twiddling to determine if it might need to go off and set errno, trying to manaually handle the denormal case, ...). (granted, I have not investigated whether MSVC still does this when optimizations are on, since optimization hides the code from the debugger, but oh well...). > > Walter.. > -- > Walter Banks > Byte Craft Limited > http://www.bytecraft.com >
From: Charles E. Bortle, Jr. on 10 Dec 2009 18:34 "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message news:87aaxtb20j.fsf(a)galatea.local... > "Bill Cunningham" <nospam(a)nspam.invalid> writes: > be used for writing OSs. > > Of course any programming language can be used to write an OS. Aren't > you aware of the Turing Machine equivalence? > > > -- > __Pascal Bourguignon__ FWIW: Which I was going to mention that after I read your "machines on machines on machines" observation, and before I read this post, Pascal :-) Just a further observation...that even extends "downward" when you consider that the "Native Machine" of microcoded machines is really (generally speaking) a type of interpreted system, as the microcode implements the "machine" code. 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) This is a very interesting thread :-) 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" generation. (I don't have much experience writing OS's, so my comments are FWIW. I have used Pascal to write a recursive descent based FORTRAN IV compiler, as well as a table-driven parser Pascal compiler (not fully working as of this date) and a Parse Table Generator [input "language" is BNF], and my observation of that is that C would not have been a good choice over Pascal). Charles Bortle charlesb.cca(a)mpowercom.net
From: Charles E. Bortle, Jr. on 10 Dec 2009 18:44 "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message news:873a3ld6jm.fsf(a)galatea.local... > > The shame is that we don't already have AI systems that automatically > optimize algorithms ;-) > > __Pascal Bourguignon__ This harks back to the "incunabula days" of HLL's/Compilers, when it was widely held that Automatic Programming (as what we call Compiling) was an impossible dream. Of course, I often wonder how often such a "drastic" optimization technique is worth the time it would add to compilation, not to mention the time to develop the techniques in the first place. We dance on a tight-rope vis a vis the issue of speed/space efficiency vs implementation cost. 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. Charles Bortle charlesb.cca(a)mpowercom.net
From: Moi on 10 Dec 2009 19:17 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. 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) /2cts AvK
From: gremnebulin on 11 Dec 2009 08:12
On 10 Dec, 23:34, "Charles E. Bortle, Jr." <charlesb....(a)mpowercom.net> wrote: > 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" generation. The core C language has usuful features like the ability to lay out a structure in memory precisely to a bit. Core Pascal does not (although implementations "may"). I can't think of any feature of core Pascal that is a) useful in systems programming and b) in the core language and c) not in core Pascal. |