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

[Rob Gayvert]

Steven Swerling wrote:

> 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.

But it's not really a catch-22, it's just a matter of getting the stock 
objects initialized in time. As long as the associations are present in 
the constant dictionary, methods like #white should file in fine, and 
work properly once the wxWhite object is created. The current 
mega-filein works this way -- the stock objects aren't initialized until 
the very end of the filein. Or is there something different about using 
an mcz file here?

As for modularizing the stock object initialization, should this be a 
startup responsibility for each of the classes that have stock instances?

> 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.

This must be what's happening, since sqGnu.h indicates the "big win" for 
Intel machines comes from mapping the IP, SP, and CB pointers to 
specific registers. But there must be a fix for this, since the gnuify 
process is still used on the Mac VM, and it must be using gcc3.  You 
should check with John McIntosh. He has a related note in his release notes:

    3.8.5b1    Fix issue with gnuify. The offical gnu header file used a 
different #ifdef
    for the foo register than an altered gnu header file I was using for 
many years.
    This resulted in slower performance, which is fixed in 3.8.5

I don't know what this means, but it sounds like a similar issue.

> 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.

Going to a DLL is a valid goal for other reasons as well, so we'll have 
to try this at some point.