Does Excel do "just-in-time" compilation?

[Rob Nicholson]

Sort of associated with my last question, but how does Excel execute a VBA
application:

o Is it interpreted or does it compile the VBA code into either native
assembler or some kind of p-code?
o If compiling, does it recompile everything at the start (e.g. auto_open)
or as classes, forms etc. are initiated

I'm suspecting it's not purely interpreted.

Thanks, Rob.

 

[Jim Rech]

Is it interpreted or does it compile the VBA code into either native
assembler or some kind of p-code?

FYI, an assembler is a program that compiles assembly language source code
to machine language.

I don't know that MS has documented exactly what happens to our VBA source
code. Clearly it's converted to something when we save a file because the
code is not literally visible in the file when viewed with a text editor.
Obviously it's not compiled to machine language since the code runs on PCs
and Macs.

It's pretty clear I think that the code is interpreted at run-time. If you
have a programming error, like setting a range variable to a string, it is
not caught until VB tries to run that line of code. It seems to me that the
"Compile" command on the Debug menu just checks that all referenced subs and
functions can be found, and that variables are declared if Option Explicit
is used. It probably does other things too, since a file bloats after
issuing the command, but it doesn't compile code in traditional sense of
producing code a processor can directly execute.

--
Jim Rech
Excel MVP
| Sort of associated with my last question, but how does Excel execute a VBA
| application:
|
| o Is it interpreted or does it compile the VBA code into either native
| assembler or some kind of p-code?
| o If compiling, does it recompile everything at the start (e.g. auto_open)
| or as classes, forms etc. are initiated
|
| I'm suspecting it's not purely interpreted.
|
| Thanks, Rob.
|
|

 

[Rob Nicholson]

FYI, an assembler is a program that compiles assembly language source code

to machine language.

Okay, to be entirely accurate machine code or native instructions I come
from the old Z80/6502 programming days when we programmed in assembler.

I don't know that MS has documented exactly what happens to our VBA source
code. Clearly it's converted to something when we save a file because the
code is not literally visible in the file when viewed with a text editor.
Obviously it's not compiled to machine language since the code runs on PCs
and Macs.

True - you can see the comments (in Unicode) but not a lot else. Basic has
been tokenised since the early days so Exit Sub is stored as a number.

issuing the command, but it doesn't compile code in traditional sense of
producing code a processor can directly execute.

Sounds it's something akin to p-code or the stuff used in the .NET
languages.

Would be nice to know, just for interest

Cheers, Rob.

 

[Tom Ogilvy]

From post(s) by Chip Pearson:

"Storing P-Code" refers to the way in which VBA code is stored and
executed. VBA code is never compiled into actual machine executable
code (as is C/C++). Instead, it is stored as special codes which are
then read in as data by the VBA run time libraries, which translate
then execute the actual machine level instructions. There's an
interesting "White Paper", "VBA - Maximum Performance vs. File Size"
on the Baarns Group archive site
(http://archive.baarns.com/IE4/index_devonly.asp) which describes
this. Here's a quick summary... VBA is stored in workbooks as
"Opcodes" which are platform-independent (the same for 16 and 32 bit
Excel, for Windows and Mac) translation of the actual VBA text that
you type in and see in the editor. VBA never actually stores your
code as ascii text, although if you open an Excel file in a hex editor
you can see your VBA code as a mix of ascii strings and unreadable
gibberish. When you execute or "compile" a VBA procedure, the Opcodes
are translated to Excodes, which are specific to the platform (e.g.,
32-bit Excel on Windows).


The Java language and Tandem's S-COBOL work in a similar manner --
binary codes which are read as data by the "virtual machine", which
executes actual machine code on their behalf.


Cordially,
Chip Pearson
http://home.gvi.net/~cpearson/excel


-------------< >-----------------

Martin,


Actually, just to get the terminology right, "Compiling" a VBA project
creates excodes, not opcodes. VBA always exists as opcodes -- it is never
stored as "text". Any conversion to text that you see on the screen is done
"on the fly" as you view the code.


Opcodes are how VBA is stored -- this is the version and platform
independent state of VBA, and no references are resolved (e.g., the code is
neither "early" nor "late" bound -- it is "unbound"). When you "compile"
the project, the "compiler" creates "excodes" which are specific to the
version and platform, and "early binds" whatever it can.


When you run VBA code which has not been "compiled", the "compilation" is
done on an as-needed basis, I believe module-by-module, rather than at the
project level (not sure about this point, though).


In the Developer Edition of Excel2000, you actually do have the ability to
create DLL files, for creating Com Add-Ins. These are totally different
form XLA Add-Ins, and are supported only in Office2000 applications, not
Office97. However, they provide all the speed (and code security) of
"normal" DLL files. Moreover, actual Application object is passed in during
the connection process (when the user goes to Tools, Com Add-Ins, and choose
your application), so you get the application's reference automatically, as
well as an event when the user terminates the add-in. If you haven't
started learning about Com Add-Ins, they are quite interesting. If you
want a VB6 sample file, send me an email, and I'll be happy to send you an
example project (it doesn't really do much, but it does illustrate the
general concepts).

 

[Rob Nicholson]

From post(s) by Chip Pearson:

Thanks for that - interesting reading.

Cheers, Rob.