Sign In
Forgot Password?
Sign In | | Create Account

Language extensions

Colin Walls

Colin Walls

Posted Jun 29, 2009
2 Comments

There is a paradox with programming languages. Everyone would agree that standardizing languages is a good thing, leading to portability of software and programming skills. But what if the resulting standard lacks features required by certain types of applications? One possible approach is to define a language specification that is so large that it encompasses every possible eventuality. In the late 1960s, IBM created the “ultimate” programming language, which had capabilities that accommodated numerous types of applications – it was called PL/1. Although it was widely used [on IBM mainframes] for some years, it had a fundamental problem: because the language was so large, each programmer would tend to learn and use just a sub-set of the available facilities, so they would not necessarily be able to understand one another’s code. This rather defeats the point of a standard. Another approach is to keep the specification quite lean, but complete enough for most applications and accept that language extensions may be necessary for specific specialized needs.

The most common languages for embedded applications are C and C++, neither of which were designed for embedded. Both of them lack a few key capabilities and this lack is addressed in three ways:

  1. language extensions – extra keywords
  2. inline compiler directives – #pragma
  3. linker capabilities

It is worth minimizing the number of new keywords to avoid compromising code portability too much. The important ones are: packed and unpacked [which override prevailing memory usage optimization strategy], interrupt and asm. These are quite specific to embedded developers, who need fine control over memory usage and want to minimize the use of assembly language. Maybe I will discuss these in more detail another time – I have covered them in a recent Webinar [slide #42].

Compiler directives are flexible, but result in very non-portable code, as they are quite specific to particular compilers.

Using the linker to address language shortcomings is a creative solution. Linkers are critical tools for embedded developers and their flexibility is valued by developers. Technology like Fine Grain Allocation, developed by the Mentor Graphics compiler team, is a good example of an approach to making C/C++ work well for embedded development. Again, I have covered this in a recent Webinar [slide #39].

More Blog Posts

About Colin Walls Follow on Twitter

Colin WallsI have over twenty-five years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, I am a member of the marketing team of the Mentor Graphics Embedded Systems Division, and am based in the UK. Away from work, I have a wide range of interests including photography and trying to point my two daughters in the right direction in life. Learn more about Colin, including his go-to karaoke song and the best parts of being British: http://go.mentor.com/3_acv Visit The Colin Walls Blog

More Posts by Colin Walls

Comments 2

Post a Comment
I cannot believe this will work!

Roulet
11:45 PM Aug 17, 2009

Roulet: What are you unable to believe?

Colin Walls
10:36 AM Aug 18, 2009

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)

Archives

Tags

 
Online Chat