May 23 06 3:54 PM

Tags : :

Article Summary:
Compiling - the "why"s and 'Wherefore"s, Machine/Assembly and higher-level languages

Machine Language:
Machine language is the computers native tongue, and it's written as a series of digital numbers. This makes it very difficult for us humans – more used to the decimal number system - to even get started with machine language.

For instance, a bit is the smallest unit recognized by a computer, it is the basic building block of every other computer language and represents the single on/off or 0/1 state. There are 8 bits to a byte, so, using binary numbers, any one of 255 states can be represented in a byte.

Now it’s possible to manipulate all these binary numbers so that the computer actually does something, but, although this is extremely fast in execution, coding in machine language is also extremely time-consuming.

To speed up the coding process, libraries of the series of numbers that are known to do things in machine language have been created, for example, the 6502 machine language has 56 instructions (commands) that are readily available for use.

Assembly Language:
To speed up the actual coding process even further, the next logical step is to create an interface that allows us to type in logical operators or expressions as NAMES that can then be interpreted and translated into the appropriate machine language numbers for the machine to act on. This is assembly language, for which an assembler is required.

Higher-Level Languages:
Programs written in higher-level languages such as C, Fortran, Pascal, VB, VBA, etc. are translated into either assembly language or machine language by what is called a “compiler

A compiler does a little more than merely translate. Before translation, the compiler first analyzes and checks the entire code procedure to see if it’s at all executable.

In this sense, a compiler differs from an interpreter (e.g. Javascript), which merely analyzes and executes each line of code in succession, without looking at the entire procedure.

The advantage of interpreters is that they can execute a program immediately, while compilers require some time before an executable program emerges. However, programs produced by compilers run much faster than the same programs executed by an interpreter

Every High-Level programming language (except strictly interpretive languages) comes with a compiler. In effect, the compiler is the language, because it defines which instructions are acceptable. (n.b. Any compiled programs that first access/require an assembly language program are then translated into machine language by the assembler program before execution).

Compiling in Excel (Or Any Other VBA Application)
In Excel - at the risk of over-simplifying – compiling is thus essentially a translation and checking process.

Before Excel can execute your code, It reads what you've written down for what you think you want it to do, it then reads your code as what IT thinks you want it to do.

If the codes' syntax etc. all check out ok and appears executable, Excel then writes your code down as what it thinks it can do in a form that it can more easily understand and translates this into code that any allied processes understand (usually written in C, C+, C++, Java, or other such languages) before it’s eventually sent down the line as machine language that is then acted upon...

This entire process is (the same as any other high-level language) in Excel called compiling and the process may take some time when you have a lot of code. The major difference between VBA compiling and other computer language compiling is that with any new compilation a stand-alone EXE or DLL file is not generated after the compilation.

So How Does This Compiling Take Place?
If a procedure has not already been compiled, or, if you have made any changes to previously compiled code, compiling takes place automatically when you click 'Run', if there's no problems with the code at the compilation phase, it is then executed.

So I Really Don't Need to Compile the Code Myself?
Generally speaking... NO! Unlike most other codes that have purpose-built compilers requiring you to do a manual compile before running, Excel has its own inbuilt compiler that does all this for you automatically when you click ‘Run’.

If the code for your procedure compiles ok, it’s then executed. If it runs ok and you're happy with the result, you will then usually save the file and the code compilation for that procedure is saved along with everything else that you’ve done.

However, there's a small risk that if you have a large project with very many procedures, you may only run a couple of those procedures when testing, the procedures that haven't yet been run are not compiled and will take longer to get up and go. So if you then quit this file without saving, these same procedures will have to be compiled every time they're executed - at least until you decide to save the file after running them.

Compiling Manually:
You can eliminate any possibility of slow-running code due to such cases by clicking Debug/Compile VBA project and then Save when your project has been completed and is ready for distribution. (Note: If ‘Compile VBA project’ is greyed-out it’s already been compiled – but not necessarily saved)

VBA Compile Settings (Options):
These settings can be found in the VBE window under Tools/Options/General.

Compile On Demand: When compile on demand is the only option checked, procedures are fully compiled before they start.

Background Compile: Background compile uses idle time during run time to finish compiling in the background. This setting requires that Compile On Demand also be checked. (Note: When background compile is checked, VBA could very well resemble an interpretive language).

A Further Option:

Auto Syntax Check: This is not a compile setting, it's an option found under Tools/Options/Editor that is almost like a partial compile. When this option is checked, incorrect syntax will, even though it's not compiled, generate a compile error message virtually as you type it, allowing you to clean it up before it even gets to the compile stage.

Auto syntax check is a very handy option as you then know that at least there will be no compilation errors due to syntax. But note that this only checks syntax, other things (such as undeclared variables) won't appear as a compile error until the code’s actually being compiled.

If I irradiate my cat will that give it eighteen half-lives?

The major part of getting the right answer lies in asking the right question...