Blueprint for an Embedded Systems Programming Language

Blueprint for an Embedded Systems Programming Language Paul Soulier Depeng Li Dept. of Information and Computer Sciences Dept. of Information and Computer Sciences University of Hawaii, Manoa University of Hawaii, Manoa Honolulu, Hawaii 96822 Honolulu, Hawaii 96822 Email: [email protected] Email: [email protected] Abstract Given the significant role embedded systems have, the implications of faulty software is clearly evident. Embedded systems have become ubiquitous and are However, software logic errors are not the only manner found in numerous application domains such as sen- in which a system can malfunction. The Stuxnet virus sor networks, medical devices, and smart appliances. [14] is an example of a failure caused by a malicious Software flaws in such systems can range from minor software attack that ultimately caused an industrial nuisances to critical security failures and malfunc- control system to destroy itself. As Internet connectiv- tions. Additionally, the computational power found in ity becomes increasingly common in embedded sys- these devices has seen tremendous growth and will tems, they too will be susceptible to software-based likely continue to advance. With increasingly powerful security exploits. hardware, the ability to express complex ideas and Many areas of software development have benefitted concepts in code becomes more important. Given the from the improvements made to programming lan- importance of developing safe and secure software guages. Modern languages are more capable of detect- for these applications, it is interesting to observe that ing errors at compile-time through their type system the vast majority of software for these devices is and many of the low-level and error prone aspects of written in the C programming language —an inher- programming have been abstracted away. This enables ently unsafe language as compared to other modern the development of more reliable and complex applica- languages. This paper examines the characteristics tions. Embedded systems are an exception to this. The and requirements that uniquely differentiate embedded vast majority of embedded systems are still developed systems from other application domains. The result using the decades-old C programming language —an is a blueprint for a modern, high-level programming inherently unsafe language with only the basic features language specifically designed for embedded systems. of the imperative paradigm. Despite its flaws, C has stubbornly remained the de facto standard for embedded system development. 1. Introduction The reasons for this are difficult to identify (al- though a massive existing code base and the lack Embedded systems exist in a multitude of appli- of a compelling replacement could be factors). Vari- cations and advances in hardware technology will ous language-based approaches have been created to continue to make them capable of greater degrees of address many of the shortcomings of C —all with sophistication and intelligent functionality. While often varying degrees of success as they apply to low- unnoticed and unseen, these systems are responsible level programming. These solutions tend to focus only for properly controlling medical devices, automobile on a subset of all the issues involved with low- braking systems, industrial control systems, and nu- level software development while not considering other merous other cyber-physical systems that interact with critical aspects. What is missing is a cohesive and the world in profound ways. The growing fields of sen- practical language that effectively incorporates all of sor networks and the Internet of Things combined with these methods and techniques in a manner consistent ubiquitous Internet connectivity will further expand the with the needs of embedded systems. use of embedded systems. On language design Landin [9] remarks in the paper “The Next 700 Programming Languages” that with potentially thousands of vehicles being recalled. “...we must systematize their design so that With these strict requirements, the need to successfully a new language is a point chosen from a develop and release error-free software very important. well-mapped space, rather than a laboriously devised construction.” 2.2. Data Layout and Representation To design a compelling language to replace C, we must first identify what the language needs to look like. In most applications, developers are really just con- With this in mind, the contribution of this paper is a cerned with what data needs to be stored in a structure; description of the features and constructs necessary in where the data goes and how much room it takes a language designed to implement secure and reliable is generally unimportant. Embedded systems, on the embedded systems software. other hand, care a lot about where data is located in a This paper is structured as follows. Section 2 de- structure and how much space it consumes. scribes the characteristics that differentiate embedded The ability to specify the size and location of data systems from other programming disciplines. Section is necessary when defining language-based structures 3 presents the blueprint of a programming language that must match hardware structures or standardized designed to produce secure and reliable embedded protocols. Data layout is also an important tool for tun- software. Section 4 highlights related research that has ing. Organizing a structure to improve memory locality attempted to address the shortcomings of programming based on knowledge of the CPU cache architecture languages for embedded systems, and finally, section or runtime access can have a significant performance 5 concludes. impact. The ability to represent and manipulate data in arbitrary ways is a fundamental aspect of writing 2. Characteristics of Embedded Systems embedded systems code. Embedded systems have a number of characteristics that differentiate them from other application domains. 2.3. Hardware Interaction These particularities make most programming languages ill-suited for this type of software development. Embedded systems interact directly with hardware High-level languages generally attempt to provide through memory-mapped IO or low-level CPU instruc- helpful abstractions for tasks that can be automated tions. In the case of memory-mapped IO, hardware by the compiler or those that are error-prone. While registers appear as normal memory, but may behave these abstractions can improve development efficiency in ways that are not entirely consistent with regular and reduce errors, they have the unfortunate side memory. Consider, for example, a hardware device that effect of obscuring the low-level details that embedded accepts a 32-bit value from the host through a 16-bit systems must deal with. The necessity to interact memory-mapped register. Listing 1 shows pseudocode directly with hardware, specify the organization of data that could be used to send this value to the device. within a structure, operate with limited resources, and The host writes the most significant 16-bit value to performance requirements are all elements that bring the register followed by the least significant value. a unique set of challenges to developing this type of software. This section examines the various aspects of u16 *reg = device->input_reg; embedded systems that necessitates a domain-specific language. *reg = val >> 16; *reg = (val & 0xffff) 2.1. Safety and Reliability Listing 1. “Interfacing with Hardware” As mentioned in the introduction, embedded systems are often found in devices that can have a major The compiler, unaware that the memory location is impact to the physical world. It is frequently required different from others, may eliminate the first assign- that these systems operate without error and with no ment upon seeing the same memory address is im- down-time. Furthermore, if a problem is found and a mediately overwritten by another value. Idiosyncrasies software fix is identified, upgrades can be difficult and such as this are common in embedded systems where sometimes impossible. Consider faulty software in an unique hardware properties do not always match the automobile component —the implications are massive abstract machine of the programming language. 2.4. Transparent Expression can have a profound impact to a programs ability to achieve its goals. These small performance gains Transparency is a trait of language expression that often come from specific knowledge of a system and is particularly import to embedded systems. One of the the programmer’s ability to generate appropriate code strengths of the C programming language is that it is rather than a compiler’s optimizer. Performance can be easy for the programmer to conceptualize how source a major influence in the overall design of an embedded code will translate into machine instructions and data system. structures. This ability becomes very important when attempting to fit code or data into resource-limited 3. Language Blueprint hardware, gaining additional performance, or interface with hardware. Expressiveness can be described as the property of a language that allows a programmer to effectively trans- 2.5. Constrained Environment late concepts and ideas into code. The more expressive a language is, the easier it is for a programmer to Embedded systems are almost always constrained in realize a solution to a problem. This trait is domain some fashion. The most common limitations encoun- specific; what constitutes an expressive language in tered are computational power (memory and

Load more