As we've already seen in part 1 and part 2 of this mini-series, programming languages like C and C++ are very different in nature to hardware description languages (HDLs) like Verilog and VHDL. In this column we're going to explore these differences in a little more detail.
Now, before we plunge headfirst into the fray with gusto and abandon, let's first set the scene by noting that -- if we wished -- on the software side of things we could simply create a single, honking big program. By this I mean a single file containing line after line of code that may include loops and IF-THEN-ELSE type statements, but that doesnít make any use of procedure or function calls.
A honking big program (left) and a honking big circuit (right).
Similarly, on the hardware side of the fence, we could use our HDL to describe a single, honking big circuit/design. In reality, of course, we tend not to do this sort of thing on either side of the fence, because it makes life difficult in so many ways.
Taking a walk on the software side
Just one more point before we start, which is that we are going to keep things as simple as possible. On this basis, we will consider only a single-threaded program running on a single processor core -- we are not going to worry about multi-core systems, threaded applications, operating systems time-sharing multiple programs, or any other weird and wonderful scenarios.
The term "subroutine" is used to refer to a small portion of code that performs a specific task and that is relatively independent of the main body of code. The main routine (program) calls the subroutine as and when it is required. These days, the term "subroutine" is now predominantly associated with assembly languages and languages like BASIC. In the case of languages like C and C++, it is more common to use the terms "procedure" and "function" (we donít need to worry about the differences between these constructs here). Older programmers often think "subroutine" but say "procedure" and "function," while younger programmers typically view the world only in terms of procedures and functions. Having said this... these days, for a number of folks, even the terms "procedure" and "function" are going by the wayside, being replaced by "object," but we digress...
Consider a program that makes use of four procedures that we will call "pA," "pB," "pC," and "pD." A very simplistic way of viewing things (ignoring loops and suchlike) is that the "arrow of time" -- by which I mean the order of program execution -- points from top to bottom as illustrated below:
A software program in C/C++ boasting four procedures.
Once again, we're keeping things simple here. In reality, the main program may call procedures and functions multiple times from different parts of the program, passing in different values each time. Also, procedures and functions can call other procedures and functions (sometimes they even call themselves recursively), but we really donít want to get sidetracked by any of these scenarios, because we have other fish to fry...
Next page >