[Point of VIEW] Debugging and Demystifying Compilers With Grandma COBOL

Tuesday, July 21, 2015

Today’s post is part of a series exploring areas of focus and innovation for NI software.

Shelley headshot.jpg


Today’s Featured Author

Shelley Gretlein is a self-proclaimed software geek and robot aficionado. As NI’s director of software marketing, you can find Shelley championing LabVIEW from keynote stages to user forums to elevator conversations. You can follow her on Twitter at @LadyLabVIEW.




Grace Murray Hopper (1906–1992), computer scientist and US Navy rear admiral, is on record as the individual who invented the first compiler and popularized the concept of machine-independent programming languages, and her work led to the development of COBOL. Her influence earned her the nickname Grandma COBOL[1]


Hopper’s contributions led to the productivity through abstraction that engineers and scientists benefit from regularly. While her work was ahead of her time, compilers have advanced significantly since the Harvard Mark I computer Hopper used in 1944. Compiler design, even for a trivial programming language, can easily become complex, which makes compiler theory one of the most specialized fields among software professionals today. This complexity translates to either a frightening or magical trick for the majority of engineers.


However, all engineers can benefit from this art form of software mastery. From Python to LabVIEW, compilers are primarily used to translate source code from a high-level programming language (G, C#, and so on) to a lower level language (assembly or machine code). Even more beneficial are cross-compilers that can create code to execute on a computer where the target and development CPU or OS are different.


Modern LabVIEW provides a multiparadeigmatic language that embraces a wide variety of concepts including data flow, object orientation, event-driven programming, and, more recently, multirate data flow, which extends LabVIEW development by giving you the ability to implement multirate, streaming digital signal processing algorithms more intuitively. LabVIEW also supports cross compilation, a powerful language that offers flexibility to protect the investment in your code by developing on one platform and deploying to Windows, MacOS, NI Linux Real-Time, CPUs, and FPGAs. All of this to say, the LabVIEW compiler is a pretty awesome, sophisticated element of our platform.




Figure 1. LabVIEW has a cross-compiler and contains a multiparadeigmatic language that embraces a wide variety of concepts including data flow, object orientation, event-driven programming, and, more recently, a multirate diagram, which defines a synchronous multirate dataflow system (shown here).

For LabVIEW and most languages, the compiler is an area that is always reviewed, renewed, and improved. Major compiler investments (following the first huge transition from an interpreter to a compiler in LabVIEW 2.0) began in LabVIEW 2009 when we added 64-bit compilation and DataFlow Intermediate Representation (DFIR). Complementary to that investment was the adoption of a Low-Level Virtual Machine (LLVM) into the compiler chain in LabVIEW 2010. These significant improvements provided more advanced forms of loop-invariant code motion, constant folding, dead code elimination, and unreachable code elimination, as well as new compiler optimizations such as instruction scheduling, loop unswitching, instruction combining, conditional propagation, and a more sophisticated register allocator.


So aren’t other compilers amazing, too? Of course, anything that provides a valuable abstraction from machine code to encourage innovation and increase productivity is amazing. However, all compilers are not created equal. 


Python, for example, has a compiler that compiles to a byte code used by a virtual machine, similar to Java. This provides portability but keeps it very far from “the metal” or hardware creating noteworthy challenges if your application relies on timing or I/O. 


Why does this all matter? Why do you care about Grandma COBOL’s work? As a busy, practical engineer who programs to get an application built and trusts the compiler will just work, what’s in it for you? When done well, compilers can contribute significant value to your day-to-day development by increasing your executable code’s performance. Modern compilers can also contribute to your productivity if they are designed to be extensible so that partners can build on tools, languages, and integrated development environment features for more rapid innovation. This complex and critical element of every language provides a constant “green field” of innovation for computer scientists—an opportunity for continuous improvement in each release.


What’s your favorite compiler? Where should we invest next to improve LabVIEW compiler technology for you?



The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the mark on a worldwide basis.


[1] Hopper, well known for her lively style, is also credited for popularizing the term debugging, for solving small glitches with engineering problems, when her associates discovered a moth stuck in a relay (Dahlgren, Virginia 1947).