Re: Why C for operating systems
- From: "BGB / cr88192" <cr88192@xxxxxxxxxxx>
- Date: Wed, 9 Dec 2009 11:33:12 -0700
"Walter Banks" <walter@xxxxxxxxxxxxx> wrote in message
news:4B1FB950.61EE09BA@xxxxxxxxxxxxxxxx
"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
.
- References:
- Why C for operating systems
- From: Bill Cunningham
- Re: Why C for operating systems
- From: Walter Banks
- Why C for operating systems
- Prev by Date: Re: Why C for operating systems
- Next by Date: Re: Why C for operating systems
- Previous by thread: Re: Why C for operating systems
- Next by thread: Re: Why C for operating systems
- Index(es):
Relevant Pages
|
