Notes on compiling w/ gcc3.XX and Notes on Cleaner File-in

[Steven Swerling]

Hi,

I spent the afternoon yesterday working on a couple projects: compiling 
w/ gcc3.XX and revisiting the problem of getting a simpler file-in of 
WxSqueak into a stock squeak image.

First the file-in:

I approached this by filing in a tiny WxBase class (about 20 methods) 
into a fresh squeak image and initializing all the constants. To do this 
there is a single method call "initializeFromMap:" that takes the 
filename of the constant map. After this, a WxSqueak mcz file can be 
installed. But there is still one problem: there is a catch-22 in 
initializing the stock objects dictionary. In order to file in code that 
uses, say, 'wxWhite', which normally holds a WxColour<255,255,255>, you 
first have to initialize the stock objects. But to initialize the stock 
objects, you first need to file in the classes that the stock objects 
use. There are about 40 of these classes, and some of the classes 
themselves use stock object constants. For instance, the WxColour class 
returns 'wxWhite' when you call the WxColour>>#white method. So when 
trying to startup the WxDemoFrame, the vm crashes at the moment the 
frame tries to initialize its background color to wxWhite, since wxWhite 
was nil at the time WxColour was filed in, and passing nil to 
setBackgroundColor: crashes the vm.

Compiling w/ GCC 3.XX

The version of GCC used by squeak to get it's performance boost on win32 
is 2.95.2. However, the compile notes for WxWidgets 2.5.3 indicate that 
henceforth you must use 2.95.3 or higher to compile wxWidgets.

I downloaded a variety of MingWs with various gcc 3.XX series compilers 
and compiled the stock squeak vm with them. The resulting VMs exhibit 
performance that is about the same as MSVC. I could find no compile 
incantation that would cause the performance spike that you see with gcc 
2.95.2. However, since I am by no means an expert, you must take this 
with a grain of salt. Suffice it to say I tried exactly one zillion 
different compiler flag combinations.

My theory (again, grain of salt) is that it has to do w/ the registers 
reserved by the gnuification of the interpreter. The notes for gcc 
indicate that register remapping was revamped for the 3.XX series. My 
guess is that the registers that are used by squeak were left alone by 
2.95.2, but are being used by gcc 3.XX.

There may be some sort of compiler flag that reverts gcc to old style 
register renaming, but I could not track such a flag down. Also, I have 
yet to try compiling squeak w/ gcc 2.95.3 since I could not find an 
archived version of MingW that uses that version of gcc (supposedly 
MingW 1.0 uses gcc 2.95.3, which can be used to compile wxWidgets 2.5.3).

I tried a different tack instead, which is to simply replace the vm 
source files w/ the slightly altered vm source files used by wxSqueak, 
and compiled them with the gcc 2.95.2. The performance spike is still 
there when you do this, as you might expect. Ok, there is a negligable 
drop in bytecode/sec, but basically it flies.

So the moral of all this: compiling the squeak vm to get the performance 
surge seen using gcc 2.95.2 is nontrivial. Gcc 3.XXX series compilers 
show the same performance as msvc (but grain of salt). Since WxWidgets 
no longer supports 2.95.2, this gives the WxSqueak project an incentive 
to implement the WxPlugin as a dll regardless of whether we will need an 
altered base squeak vm, for 2 reasons. First, so that we can benefit 
from any compiler magic used on the base squeak vm by other projects. 
And second, if the WxWidgets project discovers some esoteric combination 
of compiler and flags that juice up WxWidgets, we can use it without 
having to use the same compiler and flags on squeak. While this is no 
guarantee that the the performance boost of squeak will be retained when 
used in combination w/ WX, it helps our chances.