DOCSLIB.ORG

SIPB's IAP Programming in C

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
SIPB's IAP Programming in C SIPB’s IAP Programming in C C was developed at AT&T Bell Labs between 1971 and 1973, by Dennis Ritchie. It was derived from an experimental language called B, which itself was a stripped-down version of BCPL. All of these are derivatives of the ALGOL family of languages, dating from the 1950s. This work was done on a PDP-11, a machine with a 16 bit address bus. While a PDP-11 should be able to address up to 64K of memory, these machines only had 24K. The C compiler was written in C, and was able to compile itself on these machines, running under the nascent Unix operating system. #include <stdio.h> main() The classic { printf("hello, world\n"); } /* * %% - a percent sign * %s - a string * %d - 32-bit integer, base 10 * %lld - 64-bit integer, base 10 * %x - 32-bit integer, base 16 * %llx - 64-bit integer, base 16 * %f, %e, %g - double precision * floating point number */ /* * the following should produce: A word on printf() * * printf() test: * string: 'string test' * number: 22 * float: 18.19 */ printf("printf() test:\n" " string: '%s'\n" " number: %d\n" " float: %g\n", "string test", 22, 18.19); Language Structure char i_8; There are five different /* -128 to 127 */ kinds of integer: unsigned char ui_8; /* 0 to 255 */ - char short i_16; - short /* -32768 to 32767 */ unsigned short ui_16; - int /* 0 to 65536 */ int i_32; - long /* -2147483648 to 2147483647 */ unsigned int ui_32; - long long /* 0 to 4294967295U */ long i_arch; unsigned ui_arch; Each of these can be /* architecture either: * dependent */ long long i64; - signed (the default) /* -9223372036854775808LL to * 9223372036854775807LL */ - unsigned unsigned long long ui64; /* 0 to 18446744073709551615ULL */ There are at least four float f_32; /* single precision: * +/- 1.1x10^-38 to 3.4x10^38, different kinds of * roughly 7 digits precision */ floating point value: double f_64; /* double precision: * +/- 2.2x10^-308 to 1.7x10^308 - float * roughly 16 digits precision */ long double f_80; - double /* extended precision: * +/- 1.1x10^-4932 to 1.1x10^4932, - long double * roughly 19 digits precision */ __float128 f_128; /* quadruple precision: * +/- 1.2x10^-4932 to 1.2x10^4932, - __float128 * roughly 34 digits precision */ Additionally, C char zero = '0'; understands strings char *one_as_string = "One"; char *stuff = "I think I see " and characters: "Bob Marley " "in my cornflakes!\n"; There are a number of /* * \a Bell (alert) backslash escapes * \b Backspace * \f Formfeed available, to encode * \n New line * \r Carriage return commonly used but * \t Horizontal tab * \v Vertical tab unprintable (or * \' Single quotation mark * \" Double quotation mark reserved) characters in * \\ Backslash * \? Literal question mark strings: */ /* * 000 NUL '\0' * 001 SOH (start of heading) * 002 STX (start of text) * 003 ETX (end of text) * 004 EOT (end of transmission) * 005 ENQ (enquiry) * 006 ACK (acknowledge) * 007 BEL '\a' (bell) * 010 BS '\b' (backspace) * 011 HT '\t' (horizontal tab) * 012 LF '\n' (new line) * 013 VT '\v' (vertical tab) * 014 FF '\f' (form feed) Backslash escapes can * 015 CR '\r' (carriage ret) * 016 SO (shift out) * 017 SI (shift in) * 020 DLE (data link escape) also be composed with * 021 DC1 (device control 1) * 022 DC2 (device control 2) * 023 DC3 (device control 3) * 024 DC4 (device control 4) octal values, to specify * 025 NAK (negative ack.) * 025 NAK (negative ack.) * 026 SYN (synchronous idle) ASCII coded * 027 ETB (end of trans. blk) * 030 CAN (cancel) * 031 EM (end of medium) * 032 SUB (substitute) characters in a general * 033 ESC (escape) * 034 FS (file separator) * 035 GS (group separator) * 036 RS (record separator) fashion: \NNN * 037 US (unit separator) * * * 40 50 60 70 100 110 120 130 140 150 160 170 * -------------------------------------------- * 0: ( 0 8 @ H P X ` h p x * 1: ! ) 1 9 A I Q Y a i q y * 2: " * 2 : B J R Z b j r z * 3: # + 3 ; C K S [ c k s { * 4: $ , 4 < D L T \ d l t | * 5: % - 5 = E M U ] e m u } * 6: & . 6 > F N V ^ f n v ~ * 7: ' / 7 ? G O W _ g o w DEL */ int ten_integers[10]; Arrays double five_doubles[5]; unsigned long long guess[22]; struct NameOfStructure { int integer_field; double floating_point_field; unsigned short an_array[15]; Structs }; struct AnotherStructure { int a; char b; struct NameOfStructure nos; }; struct NameOfStructure { int one_bit:1; Bitfields int two_bits:2; int many_bits:22; }; union NameOfUnion { int integer_field; Unions double floating_point_field; unsigned short an_array[15]; }; enum NameGoesHere { Gives, Each, Enums An, Integer, Value }; typedef unsigned long long my_uint64_t; struct Example { Typedefs my_uint64_t a; my_uint64_t b; }; typedef struct Example Example_t; struct One { int a; int b; double c; char *string; }; struct Two { These composite data char *name; char *desc; types can be init- struct One data; ialized, too, which is }; struct Two values[] = { handy for working with "slug", "squooshy, gross", 1, 2, large sets of constant, 3.0, "four", "bat", "blood thirsty", { 7, 14, complex data 21.0, "rump roast" }, /* ... etc ... */ { "chicken", "walking gizzard", { 9, 7, 5, "boombox" }}, NULL, NULL, 0, 0, 0, NULL }; /* start by declaring: * - the return type * - the function name * - the types and names of the * function parameters */ int sum_of_squares(int a, The building block of int b) { computation in C is the /* first come variable * declarations */ function; all int c; computation must /* then statements; each * statement should end with occur inside one * a semicolon */ c = (a * a) + (b * b); /* return a value, if we said * we would */ return c; } int sum_of_squares(int a, int b) { int c; c = (a * a) + (b * b); return c; } int pythagorean_p(int a, int b, Functions can call int c) { other functions int v1,v2; /* a function call looks * like this */ v1 = sum_of_squares(a,b); v2 = c * c; if(v1 == v2) return(1); else return(0); } The top level function is main(); that gets called when your program runs int sum_of_squares(int a, int b) { int c; /* notice we don't even use argc and * argv; not a big deal! */ c = (a * a) + (b * b); int main(int argc, return c; char *argv[]) } { if(pythagorean_p(3,4,5)) int pythagorean_p(int a, printf("3:4:5 is a " int b, "pythagorean triple\n"); int c) else { printf("3:4:5 is NOT " int v1,v2; "a pythagorean triple\n"); v1 = sum_of_squares(a,b); return(0); } v2 = c * c; if(v1 == v2) return(1); else return(0); } /* func1() will return nothing, A C function can which is called 'void' in c. */ void func1(int a) return nothing. { printf("a = %d\n",a); } /* func2() will return a Or a function can * single integer value */ int func2(int a) return a single value. { return(a ^ (a << 2)); } /* func3() will return multiple * integers values, by way of a * struct. we'll learn other * approaches later! */ /* this holds our results: */ struct Func3Results { Or, a function can int v1; int v2; wrap multiple values }; into one return result. struct Func3Results func3(int a) { struct Func3Restults back; back.v1 = a * 2; back.v2 = a * 4; return(back); } #include <stdio.h> #include <stdarg.h> /* sum_integers() accepts first a * count of integers to sum, then * those integers themselves. it C functions can accept * returns their integer sum. */ int sum_integers(int count, variable numbers of ...) { parameters. These are int i,sum; va_list list; called variadic va_start(list,count); for(i=0,sum=0;i<count;i++) functions, and they are sum += va_arg(list,int); declared with the ’...’ va_end(list); return(sum); token. } int main(int argc, char *argv[]) { printf("sum = %d\n", sum(4, 1,2,3,4)); } /* * arithmetic operators: * +, - * : add, subtract Types can be operated * *, /, % * : multiply, divide, mod with: * ++a, --a * : increment/decrement and * : evaluate as new value * a++, a-- - Arithmetic * : increment/decrement and * : evaluate as old value operators * * bitwise operators: * &, |, ^, ! - Bitwise operators * : and, or, xor, not * >>, << * : bitshift right, left * */ /* * boolean operators: * >, >= * : greater than, greater than * : or equal to And also with: * <, <= * : less than, less than or * : equal to - Boolean operators * ==, != * : equal, not equal * &&, ||, ^^ * : and, or, xor - Assignment * * assignment operators: operators * = * : assignment * +=, -=, *=, /= * : add, sub, mul, div, * : and then assign */ /* * Do first Order of operations is * * 1 () Grouping * 2 ! ~ - ++x --x Unary ops as commonly used in * 3 * / % Mul, div, mod * 4 + - Add, sub mathematics, though * 5 << >> Bit shifts * 6 < <= > >= Comparisons interactions between * 7 == != Equality tests * 8 & Bitwise and e.g. subtract and * 9 ^ Bitwise xor * 10 | Bitwise or bitwise xor may not be * 11 && Logical and * 12 || Logical or * 13 = += -= *= /= Assignments intuitive. * * Do last */ if(a > b) { /* only case */ } Flow control is if(a > b) { achieved with: /* first case */ } else { - if contructs /* alternative case */ } - if/else contructs if(a > b) { /* first case */ - if/else if/else } else if(b > c) { /* second case */ contructs } else { /* default case */ } for(i=0;i<count;i++) { Some looping contructs /* do something with i here */ are available: } while(predicate()) { - for /* do something here */ - while } - do ... while do { /* get stuff done here */ } while(predicate()); for(i=0;i<count;i++) { if(weird_case(i)) Looping action can be continue; regulated with: /* do much important work here */ } - break do { - continue if(bored_p()) break; } while(predicate()); for(y=0;y<height;y++) { goto is wrongly feared! for(x=0;x<width;x++) { if(super_badness_p(x,y)) It is great for getting goto eject;
Load more

Recommended publications
  • C Programming Language Review
    C Programming Language Review Embedded Systems 1 C: A High-Level Language Gives symbolic names to values – don’t need to know which register or memory location Provides abstraction of underlying hardware – operations do not depend on instruction set – example: can write “a = b * c”, even if CPU doesn’t have a multiply instruction Provides expressiveness – use meaningful symbols that convey meaning – simple expressions for common control patterns (if-then-else) Enhances code readability Safeguards against bugs – can enforce rules or conditions at compile-time or run-time Embedded Systems 2 A C Code “Project” • You will use an “Integrated Development Environment” (IDE) to develop, compile, load, and debug your code. • Your entire code package is called a project. Often you create several files to spilt the functionality: – Several C files – Several include (.h) files – Maybe some assembly language (.a30) files – Maybe some assembly language include (.inc) files • A lab, like “Lab7”, will be your project. You may have three .c, three .h, one .a30, and one .inc files. • More will be discussed in a later set of notes. Embedded Systems 3 Compiling a C Program C Source and Entire mechanism is usually called Header Files the “compiler” Preprocessor – macro substitution C Preprocessor – conditional compilation – “source-level” transformations • output is still C Compiler Source Code Compiler Analysis – generates object file Symbol Table Target Code • machine instructions Synthesis Linker – combine object files Library (including libraries) Linker into executable image Object Files Executable Image Embedded Systems 4 Compiler Source Code Analysis – “front end” – parses programs to identify its pieces • variables, expressions, statements, functions, etc.
    [Show full text]
  • Section “Common Predefined Macros” in the C Preprocessor
    The C Preprocessor For gcc version 12.0.0 (pre-release) (GCC) Richard M. Stallman, Zachary Weinberg Copyright c 1987-2021 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation. A copy of the license is included in the section entitled \GNU Free Documentation License". This manual contains no Invariant Sections. The Front-Cover Texts are (a) (see below), and the Back-Cover Texts are (b) (see below). (a) The FSF's Front-Cover Text is: A GNU Manual (b) The FSF's Back-Cover Text is: You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development. i Table of Contents 1 Overview :::::::::::::::::::::::::::::::::::::::: 1 1.1 Character sets:::::::::::::::::::::::::::::::::::::::::::::::::: 1 1.2 Initial processing ::::::::::::::::::::::::::::::::::::::::::::::: 2 1.3 Tokenization ::::::::::::::::::::::::::::::::::::::::::::::::::: 4 1.4 The preprocessing language :::::::::::::::::::::::::::::::::::: 6 2 Header Files::::::::::::::::::::::::::::::::::::: 7 2.1 Include Syntax ::::::::::::::::::::::::::::::::::::::::::::::::: 7 2.2 Include Operation :::::::::::::::::::::::::::::::::::::::::::::: 8 2.3 Search Path :::::::::::::::::::::::::::::::::::::::::::::::::::: 9 2.4 Once-Only Headers::::::::::::::::::::::::::::::::::::::::::::: 9 2.5 Alternatives to Wrapper #ifndef ::::::::::::::::::::::::::::::
    [Show full text]
  • Tinyos Programming Philip Levis and David Gay Frontmatter More Information
    Cambridge University Press 978-0-521-89606-1 - TinyOS Programming Philip Levis and David Gay Frontmatter More information TinyOS Programming Do you need to know how to write systems, services, and applications using the TinyOS operating system? Learn how to write nesC code and efficient applications with this indispensable guide to TinyOS programming. Detailed examples show you how to write TinyOS code in full, from basic applications right up to new low-level systems and high-performance applications. Two leading figures in the development of TinyOS also explain the reasons behind many of the design decisions made and explain for the first time how nesC relates to and differs from other C dialects. Handy features such as a library of software design patterns, programming hints and tips, end-of-chapter exercises, and an appendix summarizing the basic application-level TinyOS APIs make this the ultimate guide to TinyOS for embedded systems programmers, developers, designers, and graduate students. Philip Levis is Assistant Professor of Computer Science and Electrical Engineering at Stanford University. A Fellow of the Microsoft Research Faculty, he is also Chair of the TinyOS Core Working Group and a Member of the TinyOS Network Protocol (net2), Simulation (sim), and Documentation (doc) Working Groups. David Gay joined Intel Research in Berkeley in 2001, where he has been a designer and the principal implementer of the nesC language, the C dialect used to implement the TinyOS sensor network operating system, and its applications. He has a diploma in Computer Science from the Swiss Federal Institute of Technology in Lausanne and a Ph.D.
    [Show full text]
  • A Type-Checking Preprocessor for Cilk 2, a Multithreaded C Language
    A Typechecking Prepro cessor for Cilk a Multithreaded C Language by Rob ert C Miller Submitted to the Department of Electrical Engineering and Computer Science in partial fulllment of the requirements for the degrees of Bachelor of Science in Computer Science and Engineering and Master of Engineering in Electrical Engineering and Computer Science at the Massachusetts Institute of Technology May Copyright Massachusetts Institute of Technology All rights reserved Author ::::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::: Department of Electrical Engineering and Computer Science May Certied by ::::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::: Charles E Leiserson Thesis Sup ervisor Accepted by ::::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::: F R Morgenthaler Chairman Department Committee on Graduate Theses A Typechecking Prepro cessor for Cilk a Multithreaded C Language by Rob ert C Miller Submitted to the Department of Electrical Engineering and Computer Science on May in partial fulllment of the requirements for the degrees of Bachelor of Science in Computer Science and Engineering and Master of Engineering in Electrical Engineering and Computer Science Abstract This thesis describ es the typechecking optimizing translator that translates Cilk a C ex tension language for multithreaded parallel programming into C The CilktoC translator is based on CtoC a to ol I developed that parses type checks analyzes and regenerates a C program With a translator based on CtoC
    [Show full text]
  • Nesc 1.2 Language Reference Manual
    nesC 1.2 Language Reference Manual David Gay, Philip Levis, David Culler, Eric Brewer August 2005 1 Introduction nesC is an extension to C [3] designed to embody the structuring concepts and execution model of TinyOS [2]. TinyOS is an event-driven operating system designed for sensor network nodes that have very limited resources (e.g., 8K bytes of program memory, 512 bytes of RAM). TinyOS has been reimplemented in nesC. This manual describes v1.2 of nesC, changes from v1.0 and v1.1 are summarised in Section 2. The basic concepts behind nesC are: • Separation of construction and composition: programs are built out of components, which are assembled (“wired”) to form whole programs. Components define two scopes, one for their specification (containing the names of their interfaces) and one for their implementation. Components have internal concurrency in the form of tasks. Threads of control may pass into a component through its interfaces. These threads are rooted either in a task or a hardware interrupt. • Specification of component behaviour in terms of set of interfaces. Interfaces may be provided or used by the component. The provided interfaces are intended to represent the functionality that the component provides to its user, the used interfaces represent the functionality the component needs to perform its job. • Interfaces are bidirectional: they specify a set of functions to be implemented by the inter- face’s provider (commands) and a set to be implemented by the interface’s user (events). This allows a single interface to represent a complex interaction between components (e.g., registration of interest in some event, followed by a callback when that event happens).
    [Show full text]
  • C Programming
    C PROGRAMMING 6996 Columbia Gateway Drive Suite 100 Columbia, MD 21046 Tel: 443-692-6600 http://www.umbctraining.com C PROGRAMMING Course # TCPRG3000 Rev. 10/14/2016 ©2016 UMBC Training Centers 1 C PROGRAMMING This Page Intentionally Left Blank ©2016 UMBC Training Centers 2 C PROGRAMMING Course Objectives ● At the conclusion of this course, students will be able to: ⏵ Write non-trivial C programs. ⏵ Use data types appropriate to specific programming problems. ⏵ Utilize the modular features of the C languages. ⏵ Demonstrate efficiency and readability. ⏵ Use the various control flow constructs. ⏵ Create and traverse arrays. ⏵ Utilize pointers to efficiently solve problems. ⏵ Create and use structures to implement new data types. ⏵ Use functions from the C runtime library. ©2016 UMBC Training Centers 3 C PROGRAMMING This Page Intentionally Left Blank ©2016 UMBC Training Centers 4 C PROGRAMMING Table of Contents Chapter 1: Getting Started..............................................................................................9 What is C?..................................................................................................................10 Sample Program.........................................................................................................11 Components of a C Program......................................................................................13 Data Types.................................................................................................................14 Variables.....................................................................................................................16
    [Show full text]
  • Tinyos Programming
    TinyOS Programming Philip Levis and David Gay July 16, 2009 ii Acknolwedgements We’d like to thank several people for their contributions to this book. First is Mike Horton, of Crossbow, Inc., who first proposed writing it. Second is Pablo Guerrero, who gave detailed comments and corrections. Third is Joe Polastre of Moteiv, who gave valable feedback on how to better introduce generic components. Fourth, we’d like to thank Phil’s father, who although he doesn’t program, read the entire thing! Fifth, John Regehr, Ben Greenstein and David Culler provided valuable feedback on this expanded edition. Last but not least, we would like to thank the TinyOS community and its developers. Many of the concepts in this book – power locks, tree routing, and interface type checking – are the work and ideas of others, which we merely present. Chapter 10 of this book is based on: Software design patterns for TinyOS, in ACM Transactions on Embedded Computing Systems (TECS), Volume 6, Issue 4 (September 2007), c ACM, 2007. http://doi.acm.org/10.1145/1274858.1274860 Contents I TinyOS and nesC 1 1 Introduction 3 1.1 Networked, Embedded Sensors . 3 1.1.1 Anatomy of a Sensor Node (Mote) . 4 1.2 TinyOS . 5 1.2.1 What TinyOS provides . 5 1.3 Example Application . 6 1.4 Compiling and Installing Applications . 7 1.5 The rest of this book . 7 2 Names and Program Structure 9 2.1 Hello World! . 9 2.2 Essential Differences: Components, Interfaces and Wiring . 12 2.3 Wiring and Callbacks . 13 2.4 Summary .
    [Show full text]
  • Systems Supplement for COP 3601
    Systems Guide for COP 3601: Introduction to Systems Software Charles N. Winton Department of Computer and Information Sciences University of North Florida 2010 Chapter 1 A Basic Guide for the Unix Operating System 1. 1 Using the Unix On-line Manual Pages Facility The following are some of the Unix commands for which you may display manual pages: cal cat cd chmod cp cut date echo egrep ex fgrep file find gcc gdb grep kill less ln locate ls mail make man mesg mkdir mv nohup nl passwd pr ps pwd rm rmdir set sleep sort stty tail tee time touch tr tty uname umask unset vim wall wc which who whoami write For example, to display the manual pages for the command "cp" enter man cp Note that you may also enter man man to find out more about the "man" command. In addition there may be commands unique to the local environment with manual pages; e.g., man turnin accesses a manual page for a project submission utility named Aturnin@ that has been added to the system. If you enter a command from the Unix prompt that requires an argument, the system will recognize that the command is incomplete and respond with an error message. For example, if the command "cp" had been entered at the Unix prompt the system would respond with the information such as shown below: cp: missing file arguments Try `cp --help' for more information. The "cp" command is a copy command. If the arguments which tell the command which file to copy and where to locate the copied file are missing, then the usage error message is generated.
    [Show full text]
  • Research Statement
    Research Statement Paul Gazzillo Fall 2017 1 Introduction My goal is to make it easier to create safe and secure programs. As computing technology becomes further integrated with our daily lives, we are subjected to increasingly severe security and privacy risks. The recent Equifax breach put 143 million people at risk, and it was due to a vulnerability that lived in source code for nearly a decade [8]. Minor concurrency errors by developers using the Ethereum cryptocurrency cost users millions of dollars in the Parity Wallet attacks [18]. Internet- enabled devices have made cars, medical devices, and even guns susceptible to potentially life- threatening takeovers by remote hackers [9, 10]. Security guru Bruce Schneier puts it eloquently: \As everything turns into a computer, computer security becomes everything security" [20]. How can we protect software systems from these risks? Auditing software manually is expensive and must to be repeated for new versions. Antivirus software and intrusion detection systems do not stop as-yet-unknown vulnerabilities. A complete solution requires developing far more secure software from the start. To do so, developers need automated software tools for security analysis, bug finding, verification, and more. Automating these tasks makes development of secure software easier, cheaper, and less error-prone. Moreover, automated tools can be applied to legacy software built without a focus on security. My research solves problems in security, systems, and software engineering with techniques from programming languages and compilers. I have co-developed an analysis that automates finding side channels [2]. This enables automated security auditing for leaks of secret data such as passwords and encryption keys.
    [Show full text]
  • Introduction
    HISTORY, BASIC SYNTAX Introduction 1 2 What is C? Why C? C is a general-purpose programming It’s still popular and widely used language initially developed by Dennis – Available on almost all platforms Ritchie between 1969 and 1973 at – Lots of libraries for different tasks AT&T Bell Labs Provides a relatively low-level (or mid-level) access to the It is an imperative procedural language operating system and hardware intended for system software – System-level programming, embedded systems – Strong ties with UNIX operating system – Can lead to better performance It has influenced many other programming languages – C++, C#, ObjC, Java, JavaScript, Go, csh, ... 3 4 Standards Look and feel First standard by ANSI in 1989, known as “ANSI C” or C89 /* Computing the factorial of an specified (by the user) number */ #include <stdio.h> – Still the best choice when portability is important! int fact(int n); int main(void){ – ISO adopted the same standard in 1990 (C90) int current; printf("Enter some POSITIVE integer (non-positive to finish): "); Next revision in 1999, C99 scanf("%d", &current); – New datatypes, complex numbers, variable length arrays,... while (current > 0) { printf("Factorial of %d is %d\n", current, fact(current)); – Not fully backwards compatible with C90 printf("Enter a POSITIVE integer (non-positive to finish): "); scanf("%d", &current); Current standard is C11 } return 0; – Improved Unicode support, atomic operations, multi-threading, } bounds-checked functions, ... /* This function returns the factorial of the specified integer (n) */ int fact(int n) { ... 5 6 Basic syntax Formatting Code is case sensitive /* example function */ Free format Statements terminate with ; float foo(int bar) { int i, c = 0; – Whitespace, newlines, layout etc.
    [Show full text]
  • Nesc Overview (And Summary of Changes)
    NesC Overview (and Summary of Changes) Eric Brewer, David Gay, Phil Levis, and Rob von Behren June 17, 2002 Version 0.6 Overview The NesC language has two goals: first, to be a pragmatic low-level language for programming the motes, and second to be the intermediate language for future higher-level languages. Here we will only deal with the first goal. As a programming language, this first version of NesC has a few modest goals: • Get rid of the awful macros for frame variables, commands and events. • Eliminate wiring error through type checking. • Simplify wiring by grouping logically related “wires” into interfaces. • Increase modularity through the separation of interfaces and modules. • Clean up the code base through better use of types and more compile time checking. • Better performance by enabling whole program optimization. Other positive side effects: • Reduced the number of files per module. • Reduced compilation time (and removed a lot of shaky perl code) • Reduced code size by 25% • Better looking code • Easier to debug code Files In general, we have moved from three files per module to one plus some interfaces. The main file, the .td file, defines a component, which is either a configuration or a module. Both configura- tions and modules have a specification of the required and provided interfaces. A configuration also lists the components used and the internal wiring. A module provides code that implements the provided interfaces (and may use the required interfaces). We keep these two separate in the belief that it makes it easier to understand the wiring and to have multiple implementations of a submodule (that use the same wiring).
    [Show full text]
  • Nait: a Source Analysis and Instrumentation Framework for Nesc
    nAIT: A Source Analysis and Instrumentation Framework for nesC Andrew R. Dalton Department of Mathematics and Computer Science, Western Carolina University Cullowhee, North Carolina, 28723 USA and Jason O. Hallstrom School of Computing, Clemson University Clemson, South Carolina, 29634 USA Abstract Automated software engineering methods support the construction, maintenance, and analysis of both new and legacy systems. Their application is commonplace in desktop- and enterprise-class systems due to the productivity and reliability bene- fits they afford. The contribution of this article is to present an applied foundation for extending the use of such methods to the flourishing domain of wireless sensor networks. The objective is to enable developers to construct tools that aid in under- standing both the static and dynamic properties of reactive, event-based systems. We present a static analysis and instrumentation toolkit for the nesC language, the defacto standard for sensor network development. We highlight the novel aspects of the toolkit, analyze its performance, and provide representative case-studies that illustrate its use. Key words: Wireless sensor networks, nesC, static analysis, instrumentation 1 Introduction For desktop- and enterprise-class system developers, automated software en- gineering methods have become important elements of the standard devel- Email addresses: [email protected] (Andrew R. Dalton), [email protected] (Jason O. Hallstrom). Preprint submitted to Elsevier 12 December 2008 opment arsenal. Automation tools increase developer productivity, improve the reliability of new systems, and safeguard the reliability of legacy systems undergoing maintenance and evolution. The focus of this article is restricted to automated analysis and instrumentation methods. Even limited to this subset, however, automation benefits span a disparate range of tasks.
    [Show full text]