{"id":244,"date":"2009-06-29T08:51:32","date_gmt":"2009-06-29T07:51:32","guid":{"rendered":"https:\/\/blogs.mentor.com\/colinwalls\/?p=244"},"modified":"2009-06-29T08:51:32","modified_gmt":"2009-06-29T07:51:32","slug":"language-extensions","status":"publish","type":"post","link":"https:\/\/blogs.stage.sw.siemens.com\/embedded-software\/2009\/06\/29\/language-extensions\/","title":{"rendered":"Language extensions"},"content":{"rendered":"<p>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 &#8220;ultimate&#8221; programming language, which had capabilities that accommodated numerous types of applications &#8211; it was called <a href=\"http:\/\/en.wikipedia.org\/wiki\/PL\/I\" target=\"_blank\" rel=\"noopener noreferrer\">PL\/1<\/a>. 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&#8217;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.<\/p>\n<p><!--more-->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:<\/p>\n<ol>\n<li>language extensions &#8211; extra keywords<\/li>\n<li>inline compiler directives &#8211; <strong>#pragma<\/strong><\/li>\n<li>linker capabilities<\/li>\n<\/ol>\n<p>It is worth minimizing the number of new keywords to avoid compromising code portability too much. The important ones are: <strong>packed<\/strong> and <strong>unpacked<\/strong> [which override prevailing memory usage optimization strategy], <strong>interrupt<\/strong> and <strong>asm<\/strong>. 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 &#8211; I have covered them in a recent <a href=\"http:\/\/www.mentor.com\/products\/embedded_software\/multimedia\/embedded-desktop-compilers-web-seminar\" target=\"_blank\" rel=\"noopener noreferrer\">Webinar<\/a> [slide #42].<\/p>\n<p>Compiler directives are flexible, but result in very non-portable code, as they are quite specific to particular compilers.<\/p>\n<p>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 <a href=\"http:\/\/www.mentor.com\/products\/embedded_software\/edge-dev-suite\/compiler\/\" target=\"_blank\" rel=\"noopener noreferrer\">Fine Grain Allocation<\/a>, 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 <a href=\"http:\/\/www.mentor.com\/products\/embedded_software\/multimedia\/embedded-desktop-compilers-web-seminar\" target=\"_blank\" rel=\"noopener noreferrer\">Webinar<\/a> [slide #39].<\/p>\n","protected":false},"excerpt":{"rendered":"<p>There is a paradox with programming languages. Everyone would agree that standardizing languages is a good thing, leading to portability&#8230;<\/p>\n","protected":false},"author":71677,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spanish_translation":"","french_translation":"","german_translation":"","italian_translation":"","polish_translation":"","japanese_translation":"","chinese_translation":"","footnotes":""},"categories":[1],"tags":[312,313,300],"industry":[],"product":[],"coauthors":[],"class_list":["post-244","post","type-post","status-publish","format-standard","hentry","category-news","tag-assembly","tag-c","tag-embedded-software"],"_links":{"self":[{"href":"https:\/\/blogs.stage.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/posts\/244","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.stage.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.stage.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.stage.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/users\/71677"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.stage.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/comments?post=244"}],"version-history":[{"count":0,"href":"https:\/\/blogs.stage.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/posts\/244\/revisions"}],"wp:attachment":[{"href":"https:\/\/blogs.stage.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/media?parent=244"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.stage.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/categories?post=244"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.stage.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/tags?post=244"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/blogs.stage.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/industry?post=244"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/blogs.stage.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/product?post=244"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.stage.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/coauthors?post=244"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}