How and Why LabVIEW Compiles Block Diagram Code

Since LabVIEW 2.0, LabVIEW has compiled block diagrams into machine code for the CPU where the block diagram is running. However, not everything having to do with a LabVIEW program is compiled. Many tasks, like updating a Boolean or a graph never change from one LabVIEW executable to another. LabVIEW reuses these from a library, much like C/C++.

An interpreter reads the symbols of a language and carries out a task immediately. A compiler translates the symbols into another, more efficient language, and carries out the task using that information.

For example, suppose you are given instructions written in a code that you do not understand, and you are given a cipher to decode them. One approach is to take the first code symbol, decode it, and carry out the first step of the task. Then you would repeat this process over and over again. Assuming that it is a complex code, you have to look up every symbol and you will not remember any of it as you proceed. This might not be an issue if you are deciphering the code only once, but if you are asked to do this again and again, decoding and acting on the instructions one at a time would be inefficient and time-consuming.

A second approach is to sit down at a desk, look up each symbol, translate it, and write it in your native language (such as English). After you finish the translation, you can read the English instructions and carry out the task. The first time you do this, it is not faster than the previous method, but for subsequent times you do not need to decode anything. You can just read the English and carry out the task.

The first approach works like an interpreter, where each execution involves interpreting the mysterious language. The second approach works like a compiler, where you interpret and translate once, and you carry out the executions more quickly because they are native.

C/C++ is a common programming language, but computers do not speak C natively and LabVIEW does not generate C code. In fact, C is a high-level language that no computer speaks natively. The CPU has a set of instructions known as machine instructions that instruct it to add, multiply, goto, and, not, and so on. The CPU is similar to a complex state machine, with the registers as the state information, and the next instruction as the object being switched on. A C compiler translates, or compiles the C code into a sequence of machine instructions. This is also what LabVIEW does. LabVIEW takes the block diagram nodes and produces machine instructions for the CPU to execute.

The LabVIEW Run-Time Engine contains functions for drawing, performing file I/O, string formatting, and the execution kernel. The kernel offers dataflow scheduling services, similar to what an OS offers, but the OS does not use dataflow to determine what to execute.

MFC is a set of libraries that many C/C++ programmers use and reuse inside their program. Their program will not run without the mfcrt.dll. The Macintosh OS has a similar toolbox. Almost every program assumes it is available and reuses that code. Therefore, the lvrt.dll is the equivalent of these support libraries, except for a different language and environment. Other libraries that are referenced are the drivers, which are shared between C and LabVIEW applications. Most executables (LabVIEW, C, and so on) require the OS and its exported libraries to open windows, draw text, and so on.

Compiling has nothing to do with making executables. Executables can in fact be interpreted or compiled. A C compiler usually is not responsible for making the executable; it creates .obj or .lib files, which the linker turns into an executable. For years, LabVIEW has had a compiler, but did not contain the capabilities to link files into an executable until more recent versions.

Reader Comments | Submit a comment »