John,

Here are versions that work with 3.6 latest. I hadn't noticed that some
things changed in VMMaker itself. This also makes the Interpreter changes
work right.

Cheers,
  - Andreas

PS. What kind of variable name is "globalStructureBuildMethodHasFoo"??? ;-)


> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of John M McIntosh
> Sent: Monday, July 07, 2003 11:16 AM
> To: The general-purpose Squeak developers list
> Subject: ENH][VM] Improved code generation (hopefully ;) 
> 
> 
> > From:   "Andreas Raab" < andreas.raab at g... >
> > Hi Guys,
> >
> > I was always suspicious about the way CCodeGenerator handled  
> > #interpret with
> > respect to temps (e.g., inlining all temps into interpret 
> and randomly
> > renaming them t1 ... tN) as it completely spoils life-time 
> analysis  
> > for the
> > C compiler (which has to assume that temps may be read in other code
> > branches and may even "optimize" them into wasting unneeded 
> registers  
> > across
> > code branches).
> >
> 
> First I was using
> Change Set:		CGeneratorEnhancements-ajh
> Date:			12 February 2002
> Author:			Anthony Hannan (ajh18 at cornell.edu)
> 
> which localized the variables in interpret(), but your change 
> set is a  
> cleaner solution.
> 
> I downloaded and setup a new image with SM & loaded the 
> latest VMMaker  
> (or so I thing/thought/believe).
> 
> Ran into some issues with the version of VMMaker you used and the  
> current one.
> Tim and you can sort out what's happening.
> 
> TMethod lost an instance variable 
> globalStructureBuildMethodHasFoo and  
> an overwrote a change in
> TMethod>>setSelector: args: locals: block: primitive:
> 
> 
> These two I'm unsure about who's at fault.
> a) Interpreter lost the class variable BlockMethodIndex
> b) and the method isUnwindMarked: is missing
> {Isn't that the block closure stuff?}
> 
> Also the two variables in interpret()
> localReturnContext & localReturnValue end up with no declaration.
> 
> Well now because I was using Hannan changeset in earlier work, since  
> 3.2.7b1, the difference is too small/difficult to measure.
> For the GCC flavor I don't think there was any difference in 
> the code  
> size. (40 bytes smaller for the entire VM, but I was missing the  
> UnwindMarked method, so I think that accounts for the 40 bytes).
> 
> For CodeWarrior OS9 there was a 46 byte difference for the 
> interpret()  
> function but any improvement is
> lost in measurement noise.  In the past the reason I used Hannan  
> changeset because it was obvious that codewarrior
> just gave up doing any useful local variable analyses and stuck the  
> first couple of vars into registers and was stupid...
> Also this made great improvements in how the 68K version worked with  
> GCC on OpenBSD 3.x
> 
>  From a note of mine to the list on April 9th, 2002 talking 
> about this:
>  >on a 68k BSD box with GCC the new numbers are {Hannan changeset }
>  >1,614,205 bytecodes/sec and 57,652 sends/sec
>  >versus my previous one using the jumptable modification
>  >1,550,387 bytecodes/sec and 55,080 sends/sec
>  >versus what I started with
>  >1,439,884 bytecodes/sec and 51,098 sends/sec
> 
> So yes the change is good.
> 
> ----------
> PS Another topic  In my measurements of the macrobenchmark I see
> 55.9% is interpret()
> 4.5% is sweepPhase
> 5.0% is markPhase
> 3.0% UpdatePointers (spelling?)
> 0.9% is incCompMove
> 
> Thus 10% lurks in the mark/sweep phase of the GC.
> 
> Fidding with ObjectMemory>>startField can be measured in the  
> tinybenchmarks.
> I'm considering check for type 0, else type = 2, otherwise 
> it's a small  
> Integer.  That becomes a load with set condition, a branch
> on condition, a check against 2 and a branch on condition. This  
> improves macrobenchbenchmark by 2%, but degrades then tinybenchmark  
> because of the integers it creates. MMM a case statement! might be  
> useful here...
> 
> 
> --
> ==============================================================
> ========== 
> ===
> John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
> Corporate Smalltalk Consulting Ltd.  
> http://www.smalltalkconsulting.com
> 
> ==============================================================
> ========== 
> ===
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: InterpreterFixes-3Point6.1.cs
Type: application/octet-stream
Size: 10712 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030707/2b765d15/InterpreterFixes-3Point6.1.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CodeGenEnh-3Point6.2.cs
Type: application/octet-stream
Size: 17717 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030707/2b765d15/CodeGenEnh-3Point6.2.obj