There are a great many programming languages in use today and many more that have fallen into disuse over the years. A challenge has always been standardization. Just about everyone would concur that standards are a Good Thing, but nobody can agree on how to apply the idea to programming languages.
One approach is to design a very complete language that addresses every programmer’s needs. This was attempted about 50 years ago by IBM. In those days, there were a number of widely used languages for different purposes. COBOL dominated the world of data processing, whereas the language of choice for engineers and scientists was generally Fortran. IBM created PL/1, which was an enormous language, with a very wide range of capabilities. It was quite widely used (on IBM mainframes), as programmers mostly found that it did indeed have the functionality that they required. The problem was that every user learned a different subset of the language, depending on their needs. It was thus quite possible for two PL/1 programmers to be unable to understand one another’s code.
The alternative tactic is to create a very lean language specification and accept that the language will be adapted to specific needs. This is what happens in the world of embedded software, where the dominant languages are C and C++. Neither of these languages were designed for embedded programming, but fit the needs of developers quite well. Their shortcomings are addressed in three ways:
Language extensions – extra keywords
An obvious way to enhance the usability of a language is to extend the range of keywords. Obviously, this practice should be minimized to avoid straying too far from the standard. For embedded developers, four extra keywords are favored: interrupt (which enables interrupt service routines to be coded in C), asm (which enables lines of assembly language to be inserted) and packed and unpacked (which override the prevailing memory usage optimization policy).
Inline compiler directives – #pragma
Although such directives are quite flexible, they do result in compiler-specific code, which may be inconvenient.
A major concern for embedded software developers may be the location of code/data in memory, where being able to map on to custom hardware configurations is essential. As a result, the linker is an invaluable tool, as it addresses this matter, which is largely ignored by the programming languages.