There is an aura of magic around Delphi packages. Packages allow you to share Delphi code at a much higher level than is possible with plain old DLLs. Writing a DLL-based library API involves writing flat non-OOP global routines and avoiding any data types more advanced than integers, doubles, static arrays, PChar and records. You cannot share or exchange classes, objects, global variables or let alone strings (unless the client is a Delphi app and both the DLL and client use ShareMem).
Delphi Package Magic
Enter the magic of Delphi packages. Now you no longer have to worry about what you can share between module boundaries, because you can share everything! Packages is just a way of dividing up the logical code into physical deployment modules. Everything just works - somehow. The somehow is the (mainly undocumented) magic.
We're going to look at a small part of that magic - how global variables can be accessed across the application/package boundary. Lets start with the simplest possible case first .
Lets say we have a Unit1 that defines a GlobalVar: integer and some code in the same unit that sets it. Here is the generated assembly and machine code.
Unit1.GlobalVar := 13;
That is a single assembly instruction with no indirections or pointer access going on. Notice that both the address of the global variable and the immediate value 13 (encoded as a 16-bit shortint, $000D) is encoded directly inside the machine code instruction. When I evaluate the address of the global variable in the Ctrl+F7 evaluator, @GlobalVar, I get $409298. This is the big-endian value I have highlighted in yellow above.
Then let's look at the package magic situation. If we have a PackageA containing a Unit1 that defines a GlobalVar: integer and a DemoApplication that links to PackageA and with code that access the GlobalVar, the compiler will compile the code into something like this:
Unit1.GlobalVar := 42;
Notice the indirection there? Global variables are accessed through a pointer that is fixed up to point to the right address inside the package when the package is loaded. That is cool and a good thing. The global variable itself resides inside the package/DLL module, while the application has a magic, "invisible" global pointer variable that points to the actual package variable. This pointer is fixed up during the magic static loading of packages (it's value is probably set to the result of a GetProcAddress API call).
Global variables in standalone apps
Now lets step back a little and look at another common situation. We have looked at the intra-unit situation and the inter-module situation - the two most extreme conditions. But what happens when you access a global variable between units inside the same application? Surely, then the indirection should not be needed? Lets test it.
We write a simple console application consisting of two units, Unit1 and Unit2, and the main program.
unit Unit1;
interface
var
GlobalVar: integer = 42;
procedure SetGlobalLocally;
implementation
procedure SetGlobalLocally;
begin
asm int 3 end;
Unit1.GlobalVar := 13;
end;
end.
unit Unit2;
interface
procedure SetGlobalIndirect;
implementation
uses Unit1;
procedure SetGlobalIndirect;
begin
asm int 3 end;
Unit1.GlobalVar := 42;
end;
end.
program TestImportedData;
{$APPTYPE CONSOLE}
uses
Unit1 in 'Unit1.pas',
Unit2 in 'Unit2.pas';
begin
SetGlobalLocally;
SetGlobalInDirect;
end.
Notice the cute little hand-coded breakpoints? Debugger breakpoints are actually implemented by overwriting a byte of your code with the software breakpoint instruction (int 3) which is encoded in a machine code byte $CC. When you run this program with debugging enabled from the IDE, it will break on the two int 3 instructions. Neat, huh? ;)
The first breakpoint is inside Unit1 just above the code that modifies the global variable. This is the case we showed first above. If you run it and follow the instructions to look at the code in the CPU view, you will see that there is no indirection.
Unit1.GlobalVar := 13;
The second breakpoint is in Unit2 where we are modifying the global variable from an "external" unit (from a different unit than were the global was declared). Notice that we are still in a single EXE file here, so there should be no need for indirection, as it was in the package case. Run the code again and when it hits the second breakpoint, look at the machine code in the CPU again.
Unit1.GlobalVar := 42;
Looks like we still have indirection here...! What is going on? The reason for this (small) inefficiency is that a unit can be moved into or out of a package without being recompiled. So the compiler has to be conservative and generate the unit's code to support the "worst" case that it will be exported for use from a package. The important thing to learn from this is:
By default, all cross-unit global variable access is performed indirectly via a pointer
The implication is that if you have performance critical code that access a global variable, you should cache it in a local variable inside the loop. You can only do this if you do not need to "see" updates to the global variable while the loop is running (think multithreaded code).
For standalone applications that do not use packages at all, it is a bit irritating to know that the compiler generates sub-optimal code for global variable access. While both the performance and size overhead of the indirection should be negligible in most situations, it would still be nice to force the compiler to get rid of this indirection.
$ImportedData Off
And as it happens there is a compiler directive that does exactly this. Enter the $ImportedData (aka $G) directive. This is what the Delphi help file has to say:
"Type Switch
Syntax {$G+} or {$G-}
{$IMPORTEDDATA ON} or {$IMPORTEDDATA OFF}
Default {$G+} {$IMPORTEDDATA ON}
Scope Local
Remarks
The {$G-} directive disables creation of imported data references. Using {$G-} increases memory-access efficiency, but prevents a packaged unit where it occurs from referencing variables in other packages."
By default the setting is {$ImportedData On} - this enables the pointer indirection in code that access unit-external global variables. By using the {$ImportedData On} directive in a unit, you turn off this indirection, resulting in tighter faster code for global variable access. Notice that you have to use it in every unit referencing global variables, not just in the unit declaring it.
Lets add a third unit to our test bench program.
unit Unit3;
interface
procedure SetGlobalDirect;
implementation
uses Unit1;
{$IMPORTEDDATA OFF}
procedure SetGlobalDirect;
begin
asm int 3 end;
Unit1.GlobalVar := 42;
end;
end.
The code here is identical to the code in Unit2, but now we have included the $ImportedData Off directive to tell the compiler generate optimized code for globals. Run the program again and when it stops at the breakpoint in Unit3, look in the CPU view.
Unit1.GlobalVar := 42;
Hurrah! We got rid of the indirection.
The {$ImportedData Off} compiler directive forces the compiler to generate efficient global variable access
This works fine in Delphi 6 and 7. As it happens it no longer works in Delphi 2006 (and probably not 2005). Looks like a bug has sneaked into the compiler here. The directive is effectively ignored, still producing the indirection as we saw for Unit2 above. Hopefully Borland/DevCo will be able to fix this little issue in a future version of the compiler[1].
IDE Compiler Options
Knowing that $ImportedData Off generates better code for global variable access in a standalone application, we would of course like to set it for all the units in the application as a whole. Unfortunately that is not so easy to do. You see the Project | Options | Compiler Options dialog page does not give access to this option... :(.
Because of this issue you have to use one of the following solutions:
- Manually insert {$IMPORTEDDATA OFF} at the top of all units in the project
- Manually insert an {$ MyAppSettings.Inc} file in all units. The .inc file would contain settings such as {$IMPORTEDDATA OFF}
- Compile using Dcc32.exe setting the option from the command-line
In other words it is a bit awkward to enable this for a given application.
It is hard to set {$ImportedData Off} from the IDE.
I hope that they will be able to make this option available from the compiler options in the IDE in a future version. In fact, I went ahead and reported this as a enhancement request in QC - (please vote for it!):
"Can we please have the $G switch (AKA $IMPORTEDDATA) promoted to appear in the Project Options | Compiler dialog? It makes it easier to switch it off globally for those of us who never use run-time packages."
While it can be argued that introducing this IDE option runs the danger of users producing unusable packages, I don't think this is reason to deny the large number of people writing standalone applications easy access to this option.
The solution could be to only enable this option for projects that are compiled with run-time packages turned off (on the Project Options, Packages page).
Still, if a unit is compiled with IMPORTEDDATA OFF and then moved to a package, it has to be recompiled (i.e. the package project must be rebuilt).
To get around this problem you could:
a) Have the compiler detect this case and recompile all units with the wrong IMPROTEDDATA setting
b) Document the issue and require the user to rebuild himself
c) Combined with b) make the option less obvious and make the IDE compiler options future proof by adding a free-text field for additional compiler options. The user must manually type IMPORTEDDATA OFF in this field, supposedly this makes him qualified to know what he is doing.
The following Dcc32.exe compiler options are currently unavailable from the IDE Compiler Options:
G+ Use imported data references
M- Runtime type info
W- Generate stack frames
Z1 Minimum size of enum types"
If you think this is worthwhile to implement, please vote on QC#34650 here!
Score: Delphi 7 vs. Delphi 2006: 1-1 ;)
[1] I found that this issue has indeed been discovered independently and reported by Frederic Vanmol in Quality Central:
Report No: 33464 Status: Open
{$IMPORTEDDATA OFF} does not seem to work
http://qc.borland.com/wc/qcmain.aspx?d=33464
PS. Just as I had finished this piece, I started experimenting some more...;) In Delphi 7 it is actually possible (but still awkward) to compile an application with $ImportedData Off for all units without messing with each unit or the command line compiler.
You only need to
- close the project
- manually edit the project's .dof file
- change "-G+" to "-G-"
- save and close the .dof file
- reopen the project
- rebuild the application
If you compile from the command line you can update the .cfg file in a similar manner.
It is probably possible to do the same in Delphi 2006 by manually editing the XML in the .bdsproj file, changing
<Compiler Name="G">1</Compiler>
to
<Compiler Name="G">0</Compiler>
But it is a little hard to check, because of the Delphi 2006 bug of ignoring the directive. In both cases, the manually set compiler options are preserved even when changing compiler options from the IDE.
