Why is C used for writing drivers and OS codes? [closed] - c

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Why is C used for writing drivers and OS codes?
Is there a size problem?
Are there any drivers written in other languages?
Which language were XP, Vista, and Solaris written in?

C compiles down to machine code and doesn't require any runtime support for the language itself. This means that it's possible to write code that can run before things like filesystems, virtual memory, processes, and anything else but registers and RAM exist.

In safety-critical environments (think avionics, spacecraft, medical devices, transportation, control software for process control), systems (as well as drivers) are often written using Ada or even SPARK/Ada.
To clarify: C is usually understood to be fairly low level, and pretty much like a "macro language" for assembly itself, that's also where its power is coming from (speed, size, portability).
Ada, on the other, hand has been specifically designed for safety-critical applications with verifiability in mind, to quote Ada 2005 for Mission-Critical Systems:
Ada [9] is the language of choice for many critical systems due to its careful design and the existence of clear guidelines for building high integrity systems [10]
That's also where Ada's support for strong typing comes in, as well as a number of other important features (quoting design for safety):
Programming languages differ wildly in
their appropriateness for use in
safetyrelated systems. Carré et al.
identified six factors that influence
the suitability of a language for
high-integrity applications [Carré
1990]. These are:
Logical soundness
Complexity of definition
Expressive power
Security
Verifiability
Bounded time and space constraints
No standard programming language performs
well in all these areas although some
(such as Pascal and Ada) perform much
better than languages such as C or
C++. In highly critical applications
‘verifiability’ is of great
importance. Certain languages allow
powerful software verification tools
to be used to perform a wide range of
static tests on the code to detect a
range of programming errors.
[...] An
important issue in the selection of a
programming language is the quality of
the available compilers and other
tools. For certain languages validated
compilers are available. While not
guaranteeing perfection, validation
greatly increasing our confidence in a
tool. Unfortunately, validated
compilers are only available for a
limited number of languages, such as
Ada and Pascal. In addition to
compilers, developers of critical
systems will make use of a range of
other tools such as static code
analysis packages. The static tests
that can be performed on a piece of
code vary greatly depending on the
language used. To aid this process it
is common to restrict the features
that are used within certain languages
to a ‘safe subset’ of the language.
Well structured and defined languages
such as subsets of Ada, Pascal and
Modula-2 allow a great many tests to
be performed such as data flow
analysis, data use analysis,
information flow analysis and range
checking. Unfortunately many of these
tests cannot be performed on languages
such as C and C++ .
It would be really beyond the scope of this question to go into even more detail, but you may want to check out some of the following pointers:
Ada compared to C and C++
Ada vs. C
Quantifying the Debate: Ada vs. C++
Why choosing Ada as a teaching language? (Ada vs. C in University)
Comparing Development Costs of C and Ada (summary)
C / C++ / Java Pitfalls
& Ada Benefits
Is Ada a better C?
Ada, C, C++, and Java vs. The Steelman
Ada: Dispelling the Myths
Real-time programming safety in Java and Ada
If anyone wants to look into Ada some more, check out this: Ada Programming (wikibooks)
There are even programming languages that are specifically developed for highly critical applications, such as JOVIAL or HAL/S, the latter of which is used by the space shuttle program.
Is there any drivers written in any other languages?
I have seen some Linux drivers for special hardware being written in Ada, don't know about other operating systems though. However, such drivers usually end up wrapping the the C API.

Because C has the best combination of speed, low memory use, low-level access to the hardware, and popularity.
Most operating systems have a kernel written in C, and applications on top of that written in either C, C++, C# or Obj-C

C is by far the easiest language(other than assembly) to "get going" on bare bones hardware. With C, (assuming you have a 32bit bootloader such as GRUB to do the hard mode switching) all you must do is make a little crt0.asm file that sets up the stack and that's it(you get the language, not including libc). With C++ you must worry about dynamic casts, exceptions, global constructors, overriding new, etc etc.. With C# you must port the .Net runtime(which on it's own basically requires a kernel) and I'm not sure about Obj-C, but Im sure it has some requirements also...
C is simply the easiest language to use for drivers. Not only is it easy to get started with, but also it's easy to know exactly what happens at the machine level. Their is no operator overloading to confuse you and such. Sure it's handy in a "good" environment, but in Ring 0 where a bad pointer not only crashes your application, but usually results in a triple fault(reboot), blue screen, or kernel panic. You really like knowing what goes on in your machine..

"why we are using C language for writing drivers and OS codes.?"
So that programmers won't have to learn new syntax of each new assembly language for each new kind of machine.
"Is there any drivers written in any other languages?"
Historically, assembly languages. I don't remember if PL/S or BLISS could be used for drivers. Maybe B. In modern times, a few brave people use C++ but they have to be very careful. C++ can be used a bit more easily in user mode drivers in some situations.

Lisp machines had their operating systems written in Lisp, which shows that you don't have to use C or assembly. The Lisp machine business was destroyed by the availability of cheap PCs, whose operating systems were of course written in C and assembly.

C was one of the very first languages (that wasn't assembly) that was suitable for writing operating systems, so it caught on early. While other languages have appeared since that are also suitable for writing operating systems in, C has remained popular perhaps due to its long history and the familiarity programmers have with its structure and syntax.

C is also a language that teaches a lot about memory management and is low-level enough to show the barrier between hardware and software. This is something that is rare among many methodologies today, that have grown more towards abstraction way above anything at the hardware level. I find C is a great way to learn these things, while being able to write speedy code at the same time.

Remember that C was originally developed for writing operating systems (in this case - Unix) and similar low-level stuff. It is wery close to the system architecture and does not contain any extra features that we want to control, how they exactly work. However, please note that the rest of the operating system, including the programming libraries, does not have to be written in the same language, as the kernel. The kernel functions are provided through a system of interrupts and in fact such programming libraries can be written in any language that supports assembler snippets.
The most popular operating system nowadays are written in C: Windows, Linux and many other Unix clones, however this is not the rule. There are some object-oriented operating systems, where both the kernel and the programming interface are written in an objective language, such as:
NeXTSTEP - Objective-C
BeOS - C++
Syllable - C++
See: Object-oriented operating system on Wikipedia
Note that in Linux, it is possible to write kernel drivers in the languages other than C (however, it is not recommended). Anyway, everything becomes a machine code when it comes to running it.

"C compiles down to machine code and doesn't require any runtime support for the language itself."
This is the best feature of C

It's my belief that languages like Python, Java, and others are popular mainly because they offer extensive standard libraries that allow the programmer to code a solution in less lines. Literally a ruby programmer can open and read a file in one line where in C it takes multiple lines. However beneath this abstraction are multiple lines. Therefore the same abstraction be done in C and it's recommended. Oddly it seems the C philosophy is not to reduce the total lines of code so there is no organized effort to do so. C seems to be viewed as a language for all processor chips and naturally this means that it's hard to create any 'standard' abstracted one line solutions. But C does allow you to use #ifdef preprocessor commands so in theory you can have multiple variations of an implementation for multiple processors and platforms all on one header file. This can't be the case for python, or java. So while C does not have a fancy standard library it's useful for portability. If your company wants to offer programs that run on computers, embedded, and portable devices then C is your choice language. It's hard to replace C's usefulness in the world.

As another note for machines that have drivers in other languages, there is the SunSpot robotics platform. Drivers for devices that are connected (sensors, motors, and everything else that can communicate via the I/O pins) are written in Java by the user.

Related

Are there any languages that fit the same niches as C?

Do any proposed, or implemented languages fit in the same (enormous) niche as C, with the intention of being an alternative, while maintaining all the applicability to OS, high performance, embedded and other roles?
There are quite a number of languages that were explicitly designed to fit all of that niche:
BitC
Cyclone
Forth
Mesa
CPL
BCPL (simplified version of CPL, implementation language of MULTICS)
B (Ken Thompsons first try at a systems programming language, based loosely on BCPL, precursor to C)
Ada
Go
D
C++
Modula-2 (specifically designed for the Lilith personal computer as a successor to Pascal for systems programming, also used by IBM as the implementation language for the original OS/400)
Oberon (specifically designed as a simpler successor to Modula-2)
Component Pascal (object-oriented successor to Oberon, despite the name it is not a direct successor to Pascal)
Modula-3 (despite the name not a successor to Modula-2 but an independent development)
Sing# (the implementation language of Microsoft Research's Singularity Research OS)
Limbo (language for the Inferno operating system (successor to Plan 9 (successor to Unix)))
Ooc
Erlang (maybe not for operating systems, but embedded realtime systems, especially in the telco industry (phone switches etc.), also lately (somewhat surprising to Erlang's inventors, actually) web servers, databsase systems, etc.)
Interestingly, there are also a number of languages that were not specifically designed to fill that niche, but that have been very successfully used in that niche:
Smalltalk (several Smalltalk OSs, embedded systems, microcontrollers, realtime systems, most famous: the Tektronix TDS500 series of digital oscilloscopes)
Lisp (several Lisp OSs, embedded systems, microcontrollers, some NASA spacecraft)
Java (several Java OSs (JNode, NewOS), embedded systems, microcontrollers, smartcards)
C# (several OSs (Cosmos, SharpOS), Mono is used in High-Performance Computing)
Haskell (the House OS, the seL4 verified microkernel)
Pascal (MacOS)
There's also a lot of languages that have not yet been used in that niche, but that certainly could be. (Mostly that is because those language communities themselves have been so indoctrinated by the "you can only write operating systems in C" bullshit that they actually believe their own language to be unusable.)
Ruby
Python
ECMAScript (which is actually used for writing high-performance webservers lately)
[Note that for each one of the three categories I listed there are literally thousands more languages that fit in there.]
In fact, one sometimes gets the feeling that languages which are not specifically designed for, say, operating system programming are actually better for that kind of thing. Compare, for example, the level of innovation, the stability, number of security holes, performance in something like a Smalltalk OS from the 1970s and Windows or OSX from 2010.
Personally, I believe that this is based on some deep-seated myths in the systems programming community. They believe that systems programming in a language with, say, strong typing, type safety, memory safety, pointer safety, automatic storage management is impossible and that the only way to get performance or realtime guarantees is to forego powerful abstraction facilities. However, it turns out that when you try to design a programming language for humans instead of machines, then humans can actually understand the programs they wrote, find security holes, fix bugs and locate and fix performance bottlenecks much better in a 1 line monad comprehension than in a 100 line for loop.
For example SqueakNOS, which is a variant of the Squeak Smalltalk system that runs without an OS (in other words: it is the OS) has pretty much all of the features that you would expect from a modern OS (graphical user interface, ...) plus some that you don't (embedded scripting language that can modify every single piece of the OS at runtime) and weighs in at just 300k SLOC and boots in less than 5 seconds while e.g. Windows weighs in at 50 million SLOC.
The obvious one is C++.
Does everything you describe, but extends C quite a bit with other features (Object Oriented, etc.).
Another interesting system programming language from Google: Go
BitC is a specific attempt. Here's a great article on alternatives to C, and why they've failed.
Ada is probably the most widely used language in this space apart from C.
It is designed above all to produce reliable bug free code, but, most Ada compilers produce well optimised effiecient machine code as well.
For a while this language was compulsary for Department of Defence projects and it is still widly used in avaionics, radar, navigation and weapons control systems.
You could consider D. From the homepage:
D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability.
The D language is statically typed and compiles directly to machine code. It's multiparadigm, supporting many programming styles: imperative, object oriented, and metaprogramming. It's a member of the C syntax family, and its appearance is very similar to that of C++.
Ada and in most cases Objective-C.
freepascal.
pascal was created even before C, when there was not enough RAM and CPU for virtual machines and is still used for exactly the same porpuses than C.
modern incarnations of pascal namely Delphi and freepascal added OO and generics, following the evolution C++ has represented.
they share many concepts and design like pointers, direct allocation deallocation of memory, direct call of ASM inside programs, they are so similar that is not unusual to load dll or c/c++ code in pascal programs and vice versa.
probably looking at ancient languages like Basic it is possible to find implementations that are fitting the same niche of c.
languages follow platforms...
Do any proposed, or implemented languages fit in the same (enormous) niche as C, with the intention of being an alternative, while maintaining all the applicability to OS, high performance, embedded and other roles?
OSs were historically implemented in assembler. Later on development shifted to C, which initially was a sort of macro assembler.
Now most OSs are written mostly in C because it is pretty much only language which maintains some sort of assembler backward compatibility (e.g. one can map one to one lion share of the assembler found in the hardware specs into C). And libc is the primary interface - often is the only interface - between kernel and user-space. And yet the interface covers not everything: some things in kernel has to be accessed directly as no standard interface is (yet) provisioned. E.g. one has to use a C struct to pass parameters/retrieve results to/from ioctl.
That means that the use of C in application development is in greater part pushed by the simple fact that if you use C you get automatically access to all the features of kernel (OS) which is also written in C.
Only language which can somehow compete with C is the language which is based/compatible with C. The sole alternative known to me is the C++. In older times there were also relatively popular translators like p2c (Pascal to C): developer programs in one language, but the source code is automatically translated into C for compilation. But the translators were rather buggy and without knowledge of C often programs couldn't be debugged. So if you have to know some C anyway, why bother with the translators.
I personally (and many other developers I'm sure) using various languages often stumbled upon the problem that the OS has a feature, but the language used doesn't provide any facility to access it. That I think is the major deterrent factor for other language development. Even if you have bright a idea for a new language (which is likely to be incompatible with C, otherwise idea wouldn't be that bright) you end up with the burden to reimplement interface to the pretty much whole OS (and various must-have application libraries).
As long as (1) C remain the sole language for system programming and (2) OS interfaces are still evolving, all non-C-compatible languages on the other side of fence, application development, would be at greater disadvantage.
P.S. Actually that is one of the molds I hope LLVM/clang might break. clang is implemented as a reusable library theoretically allowing to mix languages. E.g. main source file can be in one language (and parsed by one front-end), but the #includes could be in C (and parsed by the clang).
Scala Native tries to be the functional-programming & functional-objects evolution of C's niche. Scala Native generates hardware machine code instead of JVM. https://scala-native.readthedocs.io/en/v0.4.0/

Languages using for OS development before C

I know that C is the standard programming language for operating system development, but out of curiosity I was wondering what preceded it. What was the main programming language used for operating system development before C?
There were a lot of systems before C was used for Unix (1969...). Here's a sparse timeline. Click on each system for details. Most early systems would be implemented in assembler. A notable exception (not listed in the timeline) was the ahead-of-its-time 1961 B5000 with an O/S written in ALGOL.
Burroughs was one of the first to use something other than assembler for OS development. They chose a dialect of Algol.
In 1965 Multics(Project MAC, funded by ARPA) design began and PL/I was chosen to develop the OS. In 1969 Multics was opened for use at MIT, but there were frustrations and Bell Labs withdrew from Project MAC. Ken Thompson, Dennis Ritchie, Doug McIlroy, and J. F. Ossanna continued to seek the holy grail and Unics (later Unix) development began.
Multics History
Multics Failure?
Unix v. Multics
During the 1970's "Cold War" there was an effort to use the data security and parallel processing features of ALGOL 68 to create Secure/Capability based operating systems:
Cambridge CAP computer - All procedures constituting the operating system were written in ALGOL 68C, although a number of other closely associated protected procedures - such as a paginator - are written in BCPL. c.f. microsoft
Flex machine - The hardware was custom and microprogrammable, with an operating system, (modular) compiler, editor, garbage collector and filing system all written in Algol 68RS. A Linux port of this Algol68RS can be downloaded from compile can be downloaded from Sourceforge:algol68toc.
/* Interestingly portions of DRA's algebraically specified abstract machine Ten15 is still available, also from Sourceforge:TenDRA (for minux). Ten15 serves as DRA's intermediate language for compilers, and evolved to support C and Ada. Apparently an attempt was made to port FreeBSD/Unix using the TenDRA C compiler */
ICL VME - S3 programming language was the implementation language of the operating system VME. S3 was based on ALGOL 68 but with data types and operators aligned to those offered by the ICL 2900 Series. This OS is still in use as a Linux VM, and has some 100,000 users.
The Soviet Era computers Эльбрус-1 (Elbrus-1) and Эльбрус-2 were created using high-level language uЭль-76 (AL-76), rather than the traditional assembly. uЭль-76 resembles Algol-68, The main difference is the dynamic binding types in uЭль-76 supported at the hardware level. uЭль-76 is used for application, job control, system programming c.f. e2k-spec.
Maybe the US military was doing something similar somewhere. Anyone?
There were many 16-bit Forth systems where the interpreter and (fairly primitive) OS layer were written in Forth.
The original Mac OS was written in a mix of 68k ASM and a slightly extended Pascal.
ADA has been used to write several OS's.
But I'd guess that the dominant language used for OS development prior to C was IBM 360 assembly language.
That depends. The Amiga OS for example was originally written to a certain extent in BCPL, and you would imagine that many ancient operating systems were written in pure assembly language.
CP/M (which is kind of MS-DOS' predecessor) was written in PL/M, but MS-DOS was written in assembly for performance reasons. Here is something on MS-DOS: http://www.patersontech.com/Dos/Byte/InsideDos.htm
(Edited, not sure where I picked up this Fortran garbage.)
Operating systems "want" to be written in assembler. If you're starting from scratch, once you have the interrupt routines done, you can just keep on going and not get around to a high-level language interface.
Furthermore, assemblers like to evolve. Once you've covered the specified instruction set, it's convenient to add alias names for instructions that serve multiple purposes. Next come pseudo-instructions that can alias a couple machine instructions. Then it's nice to have an extensible facility for writing macro subroutines, to generate arbitrary sections of code that look like instructions. (Unlike C macros, this often may allow flow control and script-like programming.) Then, there are scoping rules to ensure identifiers are only used in a particular context.
Bit by bit, languages evolve. C didn't pop out of thin air. It was preceded by a generation or two of languages (Algol, BCPL) that evolved from high-level assemblers. Many platform-specific assembly languages were in fact reasonably nice. IBM still makes a mean assembler. (Of course, before that were not-so-nice assemblers, and before that were punch cards and toggle switches.)
More recently, GNU as has given assembly a bit of a bad name by being relatively primitive. Don't believe the scare tactics, though.

What language to learn for microcontroller programming? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm getting into microcontroller programming and have been hearing contrasting views. What language is most used in the industry for microcontroller programming? Is this what you use in your own work? If not, why not?
P.S.: I'm hoping the answer is not assembly language.
In my experience, you absolutely must know C, and assembly language helps too.
Unless you are dealing with very bare-bones microcontrollers (like the RS08 series), C is by far the language of choice. Get to know C, understand functionality like volatile and const. Also understand the architecture - what is efficient, what isn't, what can the CPU do. These will differ wildly from a "desktop" environment. Learn to love stdint.h.
You will encounter C++ (or a restricted subset) as projects scale up.
However, you need to understand the CPU and how to read basic assembly as a debugging tool. You can't become an excellent embedded developer without this skillset.
What 'contrasting' views have you heard? To some extent it will depend on the microcontroller and the application. However C is available for almost all architectures (I hesitate to say all, but probably all that you will ever encounter); so on that point alone, learning C would give you the greatest coverage.
For all architectures, the availability of an assembler and a C compiler are pretty much a given. For 32-bit and most 16-bit architectures C++ will also be available. Notable exceptions I have encountered are Microchip's PIC24/dsPIC parts for which C++ is not supported by Microchip's own GNU based compiler (although 3rd party compilers may do so).
While there are C++ compilers for 8 bit microcontroller's C++ is not ubiquitous on such platforms, and often the compilers are subsets of the full language. For the types (or more specifically the size) of application for which 8-bit is usually employed, C++ may be useful but not to the extent that it is on much larger applications, so C is generally adequate.
There are lot of myths about C++ in embedded systems; while the language is larger than C and has constructs that may compromise the performance or capacity of your system, you only pay for what you use with C++. But of course if what you use is just the C subset, the C would be adequate in any case.
The point about C (and C++) is that it is a systems level language; it will run on your microprocessor with no additional support save a very simple runtime start-up to initialise the processor (and possibly external SDRAM), initialise static data, establish a stack, and in the case of C++ invoke static constructors. This is why along with target specific assembler, it is used to build operating systems and kernels - it needs no operating system or kernel itself to run.
One of the reasons I suggested that it may depend on the microcontroller is that if for example it is an ARM9 with a few Mb of external SDRAM, and at least say 4Mb Flash (also usually external - memory takes up a lot of die space), then you could run a 'heavyweight' OS on it such as Linux, WinCE, or Symbian, or even a large RTOS such as QNX or VxWorks. Then your choice of language (once you got the OS working), would be influenced by the OS, though for real-time applications C and C++ would still dominate, (or often Ada in military, avionics, and some transport applications).
For mid-size applications - a few hundred KBytes of code and data space - C# running on the .NET-Micro platform is possible; However I sat in a presentation of this at the Embedded Systems Show in the UK a few years ago, just after it was when it was launched; when I asked the question "but is it real-time", and was told, "no you need WinCE for that", there was a gasp and a groan from much of the audience, and some stopped wasting their time an left the presentation there and then (including me).
So I am still interested in the 'contrasting' opinions you have heard; because although it is possible to use other languages; the answer to your question:
What language is most used in the
industry for microcontoller
programming?
then the definitive answer is C; for the reasons I have given. For anyone who might choose to contest this assertion here are the statistics (note the different survey method after 2004 explained in the text). However just to add to the collection of alternatives, I once spent two years programming in Forth on embedded systems, and I know of people still using it, but it is a bit of a niche.
I've successfully used both C and C++ but in almost any microcontroller project you will need to be familiar with the assembly language of the target micro. If only for debugging low level hardware issues assembly will be indispensable, even if it is a cursory familiarity.
I think the hardest thing for me when moving from a desktop environment to a micro was that almost everything needs to be allocated statically. You won't often use malloc/new in a micro unless maybe it has external RAM.
I notice that you also tagged your question with FPGA and Verilog, take a look at Altium, they have a C to Hardware compiler that works really well with their integrated environment.
Regarding assembler:
Prefer C/C++ over assembler as much as possible. You'll get better productivity by writing as much as possible in C or C++. That includes being able to run some of your code on a PC, which can help developing the higher-level code (application-layer functions).
On many embedded platforms, it's good to have someone on the project who is comfortable with a little assembler. Mostly to get start-up code and interrupts going nicely, and perhaps functions for interrupt enable/disable. That's not the same as knowing it really thoroughly--just a basic working knowledge will be sufficient.
If you're porting an RTOS (e.g. µC/OS-II) to a new platform, then you'll have to know your assembler more. But hopefully your RTOS supports your platform well already.
If you're pushing up against CPU performance limits, you probably need to know assembler more thoroughly. But hopefully you're not pushing performance limits much, because that can be a drag on a project's viability.
If you're writing for a DSP, you probably need to know the DSP's assembler fairly thoroughly.
Microcontrollers were originally programmed only in assembly language, but various high-level programming languages are now also in common use to target microcontrollers. These languages are either designed specially for the purpose, or versions of general purpose languages such as the C programming language. Compilers for general purpose languages will typically have some restrictions as well as enhancements to better support the unique characteristics of microcontrollers. Some microcontrollers have environments to aid developing certain types of applications. Microcontroller vendors often make tools freely available to make it easier to adopt their hardware.
Many microcontrollers are so quirky that they effectively require their own non-standard dialects of C, such as SDCC for the 8051, which prevent using standard tools (such as code libraries or static analysis tools) even for code unrelated to hardware features. Interpreters are often used to hide such low level quirks.
Interpreter firmware is also available for some microcontrollers. For example, BASIC on the early microcontrollers Intel 8052[4]; BASIC and FORTH on the Zilog Z8[5] as well as some modern devices. Typically these interpreters support interactive programming.
Simulators are available for some microcontrollers, such as in Microchip's MPLAB environment. These allow a developer to analyze what the behavior of the microcontroller and their program should be if they were using the actual part. A simulator will show the internal processor state and also that of the outputs, as well as allowing input signals to be generated. While on the one hand most simulators will be limited from being unable to simulate much other hardware in a system, they can exercise conditions that may otherwise be hard to reproduce at will in the physical implementation, and can be the quickest way to debug and analyze problems.
You need to know assembly language programming.You need to have good knowledge in C and also C++ too.so work hard on thse things to get better expertize on micro controller programming.
And don't forget about VHDL.
For microcontrollers assembler comes before C. Before the ARMs started pushing into this market the compilers were horrible and the memory and ROM really tiny. There are not enough resources or commonality to port your code so writing in C for portability makes no sense.
Some microcontroller's assembler is less than desirable, and ARM is taking over that market. For less money, less power, and less footprint you can have a 32-bit processor with more resources. It just makes sense. Much if your code will still not port, but you can probably get by with C.
Bottom line, assembler and C. If they advertise BASIC or Java or something like that, mark that company on your blacklist and move on. Been there, done that, have the scars to prove it.
First Assembly. After C.
I think that who knows Assembly and C are better than who knows only C.

We have to use C "for performance reasons" [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
In this age of many languages, there seems to be a great language for just about every task and I find myself professionally struggling against a mantra of "nothing but C is fast", where fast is really intended to mean "fast enough". I work with very rational open-minded people, who like to compare numbers, and all I have are thoughts and opinions. Could you help me find my way past subjective opinions and into the "real world"?
Would you help me find research as to what if any other languages could be used for embedded and (Linux) systems programming? I very well could be pushing a false hypothesis and would greatly appreciate research to show me this. Could you please link or include good numbers so as to help keep the "that's just his/her opinion" comments to a minimum.
So these are my particular requirements
memory is not a serious constraint
portability is not a serious concern
this is not a real time system
In my experience, using C for embedded and systems programming isn't necessarily a performance issue - it's often a portability issue. C tends to be the most portable, well supported language on just about every platform, especially on embedded systems platforms.
If you wish to use something else in an embedded system, it's often a matter of figuring out what options are available, then determining whether the performance, memory consumption, library support, etc, are "good enough" for your situation.
"Nothing but C is fast [enough]" is an early optimisation and wrong for all the reasons that early optimisations are wrong. If your system has enough complexity that something other than C is desirable, then there will be parts of the system that must be "fast enough" and parts with lighter constraints. If writing your code, for example, in Python will get the project finished faster, with fewer bugs, then you can follow up with some C or assembly code to speed up the time-critical parts.
Even if it turns out that the entire code must be written in C or assembly to meet the performance requirements, prototyping in a language like Python can have real benefits. You can take your working Python prototype and gradually replace parts with C code until you reach the necessary performance.
So, use the tools that let you get the development work done most correctly and most quickly, then use real data to determine where you need to optimize. It could be that C is the most appropriate tool to start with sometimes, but certainly not always, even in embedded systems.
Using C for embedded systems has got some very good reasons, of which "performance" is only one of the minor. Embedded is very close to the hardware, you need manual memory adressing to communicate with hardware. All the APIs and SDKs are available for C mostly.
There are only a few platforms that can run a VM for Java or Mono which is partially due to the performance implications but also due to expensive implementation costs.
Apart from performance, there is another consideration: you'll most likely be dealing with low-level APIs that were designed to be used in C or C++.
If you cannot use some SDK, you'll only get yourself in trouble instead of saving time with developing using a higher level language. At the very least, you'll end up redoing a bunch of function declarations and constant definitions.
For C:
C is often the only language that is supported by compilers for a processors.
Most of the libraries and example code is probability also in C.
Most embedded developers have years of C experience but very little experience in anything else.
Allows direct hardware interfacing and manual memory management.
Easy integration with assembly language.
C is going to be around for many years to come. In embedded development its a monopoly that smothers any attempt at change. A language that need a VM like Java or Lua is never going to go mainstream in the embedded environment. A compiled language might stand a chance if it provide compelling new features over C.
There are several benchmarks on the web between different languages. Most of them you will find a C or C++ implementation at the top as they give you more control to really optimize things.
Example: The Computer Language Benchmarks Game.
It's hard to argue against C (or other procedure languages like Pascal, Modula-2, Ada) and assembly for embedded. There is a large history of success with those languages. Generally, you want to remove the risk of the unknown. Trying to use anything other than C or assembly, in my opinion, is an unknown. Having said that, there's nothing wrong with a mixed model where you use one of the Schemes that go to C, or Python or Lua or JavaScript as a scripting language.
What you want is the ability to quickly and easily go to C when you have to.
If you convince the team to go with something that is unproven to them, the project is your cookie. If it crumbles, it'll likely be seen as your fault.
This article (by Michael Barr) talks about the use of C, C++, assembler and other languages in embedded systems, and includes a graph showing the relative usage of each.
And here's another article, fittingly entitled, Poor reasons for rejecting C++.
Ada is a high-level programming language that was designed for embedded systems and mission critical systems.
It is a fast secure language that has data checking built in everywhere. It is what the auto pilots in airplanes are programmed in.
At this link you have a comparison between Ada and C.
There are situations where you need real-time performance, especially in embedded systems. You also have severe memory constraints. A language like C gives you greater control over execution time and execution space.
So, depending on what you are doing, C may very well be "better" or more appropriate.
Check out the following articles
http://theunixgeek.blogspot.com/2008/09/c-vs-python-speed.html
http://wiki.python.org/moin/PythonSpeed/PerformanceTips (especially see Python is not C section)
http://scienceblogs.com/goodmath/2006/11/the_c_is_efficient_language_fa.php
C is ubiquitous, available for almost any architecture, usually from day-one of a processor's availability. C++ is a close second. If your system can support C++ and you have the necessary expertise, use it in preference to C - it is all that C is, and more, so there are few reasons for not using it.
C++ is a larger language, and there are constructs and techniques supported that may consume resources or behave in unacceptable ways in an embedded system, but that is not a reason not to use the language, but rather how to use it appropriately.
Java and C# (on Micro.Net or WinCE) may be viable alternatives for non-real-time.
You may want to look at the D programming language. It could use some performance tuning, as there are some areas Python can outperform it. I can't really point you to benchmarking comparisons since haven't been keeping a list, but as pointed to by Peter Olsson, Benchmarks & Language Implementations has D Digital Mars.
You will probably also want to look at these lovely questions:
Getting Embedded with D (the programming language)
How would you approach using D in a embedded real-time environment?
I'm not really a systems/embedded programmer, but it seems to me that embedded programs generally need deterministic performance - that immediately rules out many garbage collected languages, because they are not deterministic in general. However, there has been work on deterministic garbage collection (for example, Metronome for Java: http://www.ibm.com/developerworks/java/library/j-rtj4/index.html)
The issue is one of constraints - do the languages/runtimes meet the deterministic, memory usage, etc requirements.
C really is your best choice.
There is a difference for writing portable C code and getting too deep into the ghee whiz features of a specific compiler or corner cases of the language (all of which should be avoided). But portability across compilers and compiler versions. The number of employees that will be capable of developing for or maintaining the code. The compilers are going to have an easier time with it and produce better, cleaner, and more reliable code.
C is not going anywhere, with all the new languages being designed to fix the flaws in all the prior languages. C, with all the flaws these new languages are trying to fix, still stands strong.
Here are a couple articles that compare C# to C++ :
http://systematicgaming.wordpress.com/2009/01/03/performance-c-vs-c/
http://journal.stuffwithstuff.com/2009/01/03/debunking-c-vs-c-performance/
Not exactly what you asked for as it doesn't have a focus on embedded C programming. But it's interesting nonetheless. The first one demonstrates the performance of C++ and the benefits of using "unsafe" code for processor intensive tasks. The second one somewhat debunks the first one and shows that if you write the C# code a little differently then the performance is almost the same.
So I will say that C or C++ can be the clear winner in terms of performance in many cases. But often times the margin is slim. Whether to use C or not is another topic altogether. In my opinion it really should depend on the task at hand. But in embedded systems you often don't have much of a choice.
A couple people have mentioned Lua. People I know who have worked with embedded systems have said Lua is useful, but it's not really its own language per se but more of a library that can be embedded in C. It is targetted towards use in embedded systems and generally you'll want to call Lua code from C. But pure C makes for simpler (though not necessarily easier) maintenance, since everyone knows it.
Depending on the embedded platform, if memory constraints are an issue, you'll most likely need to use a non-garbage collected programming language.
C in this respect is likely the most well-known by the team and the most widely supported with available libraries and tools.
The truth is - not always.
It seems .NET runtime (but any other runtime can be taken as an example) imposes several MBs of runtime overhead. If this is all you have (in RAM), then you are out of luck. JavaME seems to be more compact, but it still all depends on resources you have at your disposal.
C compilers are much faster even on desktop systems, because of how few langage features there are compared to C++, so I'd imagine the difference is non-trivial on embedded systems. This translates to faster iteration times, although OTOH you don't have the conveniences of C++ (such as collections) which may slow you down in the long run.

What sort of businesses still hire C programmers? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I'm starting a job search, ideally ending up at a C shop. So far, I'm coming up empty in my local ads, and am starting to think I need to broaden my search, targeting specific types of businesses.
So, what type of places typically use this language?
C is typically used for fairly low-level development. You'll see it used in embedded systems, frequently, which is often listed as a computer engineering position (rather than computer science, or software engineering.) C is also used frequently for device drivers and 'generic' low-level code like math utility code for larger projects.
Generally the sorts of jobs that -need- C are taken by developers who've been using it forever, and have likely been in that position a long time.
Just keep looking! C is a rarity in terms of seeing a job just listed as "C Developer" as you've seen - so obviously they'll just be hard to find.
But I'd just wonder why you're exclusively looking for a C job as opposed to a language like C++ or Objective C :)
Edit:
Just a little note also, not to mislead you with the answer; C is still used for a lot of different stuff. Browsers, instant messengers, server daemons, the network code for even some code written on other languages even. The problem is this is just inefficient in terms the amount of time spent doing the work when you easily write it in Python, on .NET, or any number of other technologies. As such, it just isn't common, but the work can exist.
I work primarily as a C (and Perl) developer, because the application is mature, with a fairly long history (i.e. originally developed in the early 90s). The application suite originally was developed for Unix based graphical workstations. My previous job was a similar situation, a mature distributed application that was developed on multiple Unix platforms, originally in the early 1990s, and due to the source code size and maturity, it would be difficult to justify simply throwing that code base away to move to a new development language or even migrating to C++.
I would imagine there are still a number of larger in-house (used for internal purposes, not sold as a product) applications written in C that are still being maintained. Not entirely unlike the massive COBOL applications that large companies (insurance, finance, banking) that are also still being maintained.
For new development in C, others have already mentioned the embedded systems market, where the development is often for software put into ROM or EEPROM / flash memory where it is referred to as firmware, for microcontrollers (Microchip PIC, Atmel AVR, 80C51, 68HC11, etc.), where object code size, RAM usage, and performance matters so the usage of a programming language with fewer high-level or generic abstractions or assumptions is desirable.
One critical thing about good to great C programmers, is that they are expected if not required to know more about data structures and algorithms. Priority Queues, Binary Trees, MergeSort, QuickSort, Knuth-Morris-Pratt, and Karp-Rabin should be at least vaguely familiar. This is because the C language lacks the STL, Boost, CPAN, and other standard libraries available in other languages. This is at least partly because most implementations are type-specific (due to lack of templates or dynamic typing or similar mechanism) to have generic enough routines to be useful in practise.
Knowing more than one programming language is not a bad thing, even if you don't feel comfortable enough to claim to be comptent enough to program in the additional langages professional. A "modern" scripting or "trendy" web development language might be a good match. Perl, Python, and Ruby are good potential candidates.
For programming experience, functional languages like LISP, Scheme, Prolog*, ML, Objective Caml, Haskell, and Scala are good candidates for making you "think different." Admittedly Prolog is actually a declarative logic programming language, but it is still programming experience expanding.
To add on to Anthony's excellent answer, C is still used extensively in the development of operating systems and firmware, so you may want to try looking in that direction as well.
Good luck in your search for a job.
Things that must run close to the metal, and be fast.
So in addition to what Anthony wrote -- networking protocols, storage device drivers, file systems, the core of operating systems, are still big on C.
Because the focus of interest has commonly moved to applied and web development where you can't do much with C.
Either extend your search geography to other cities/countries or follow the industry trend and learn something new.
Most C programming jobs are in "embedded systems" ... things like televisions, cars, phones, alarms, clocks, toys. Such applications are often memory-constrained by cost reasons, so higher-level languages (eg, Python) are not an option there.
At a time when C and C++ were the predominant coding environments, it was said that 90% of the C programming jobs were for embedded work. Stuff that isn't advertised as software, and for which there are rarely any famous names or faces associated. This is even more the case today.
Linux is completely in C. So any company that contributes to Linux is likely to employ C coders. I worked for an industrial automation company that developed in C. Though most automation shops run PLCs and ladder logic.
iPhone development shops online. Try craigslist as well.
Objective-C is a slim superset of C, so your C skills translate nicely.
Good luck!

Resources