>John,
>
>>  versus with jumptable pointer logic
>
>What do you mean with "jumptable pointer logic"?! Using labeled goto's
>from GCC for the case/switch statements?! (this has been in the Windows
>VM for ages and probably in the Linux x86 version as well) Or is there
>something else to it?!
>
>Cheers,
>   - Andreas

The change is to use a pointer to the GCC jumptable, versus the GCC 
jumptable array itself. It removes for the powerpc 2 instructions per 
jump, usually it would load the local address of the jumptable then 
the index offset, now it just loads the index offset. However it does 
something for intel under gcc.

Look at Ian's current sqGnu.h and gnuify awk script
change the jumptableptr logic to

   print "#ifdef JP_REG";
   print "    register void **jumpTablePtr JP_REG= jumpTable;";
   print "#else";
   print "    void **jumpTablePtr = jumpTable;"
   print "#endif";

Awk your interp.c and see what happens.


using Ian's standard build environment and his compiler options I saw
as shipped from Ian. These are the numbers people see today.
29962546 bytecodes/sec; 952275 sends/sec
29962546 bytecodes/sec; 965687 sends/sec
29962546 bytecodes/sec; 961174 sends/sec
29906542 bytecodes/sec; 962073 sends/sec
29143897 bytecodes/sec; 938373 sends/sec
29962546 bytecodes/sec; 963877 sends/sec
29990627 bytecodes/sec; 935811 sends/sec
29602220 bytecodes/sec; 965687 sends/sec
29629629 bytecodes/sec; 937517 sends/sec
29170464 bytecodes/sec; 963877 sends/sec

with jumptable pointer logic on  you can see how the number change, 
so it must be doing something? Only someone who wants to dump the 
assembler can tell for sure.

34725990 bytecodes/sec; 1002394 sends/sec
34953577 bytecodes/sec; 996566 sends/sec
35049288 bytecodes/sec; 981352 sends/sec
34594594 bytecodes/sec; 989852 sends/sec
34896401 bytecodes/sec; 988900 sends/sec
34725990 bytecodes/sec; 990806 sends/sec
35010940 bytecodes/sec; 991761 sends/sec
35030103 bytecodes/sec; 990806 sends/sec
35049288 bytecodes/sec; 989852 sends/sec
35049288 bytecodes/sec; 970242 sends/sec

The other change is for global structure for non-initialized, and 
non-array variables. This removes on average one instruction for each 
each global reference for powerpc. Also seems to do something for 
intel under GCC, again the numbers change.

with global structure logic.
26644462 bytecodes/sec; 1014257 sends/sec
31158714 bytecodes/sec; 1026404 sends/sec
31158714 bytecodes/sec; 1015258 sends/sec
31128404 bytecodes/sec; 1025380 sends/sec
31158714 bytecodes/sec; 987002 sends/sec
31158714 bytecodes/sec; 1041351 sends/sec
31037827 bytecodes/sec; 1015258 sends/sec
31158714 bytecodes/sec; 1027429 sends/sec
31128404 bytecodes/sec; 1012260 sends/sec
31128404 bytecodes/sec; 1026404 sends/sec

This change is in the mac vm directory special change sets. Mostly 
because the original untested thought was it would only do something 
for RISC based machines, but that seems untrue?

with jumptable pointer logic and global structure logic and the 
CGeneratorEnhancements-ajh I got...

38231780 bytecodes/sec; 1113841 sends/sec
38670694 bytecodes/sec; 1102769 sends/sec
38670694 bytecodes/sec; 1129720 sends/sec
38600723 bytecodes/sec; 1102769 sends/sec
38670694 bytecodes/sec; 1119084 sends/sec
38647342 bytecodes/sec; 1102769 sends/sec
38670694 bytecodes/sec; 1119084 sends/sec
38624019 bytecodes/sec; 1103500 sends/sec
38647342 bytecodes/sec; 1118332 sends/sec
38049940 bytecodes/sec; 1103500 sends/sec

Forthe  powerpc optimizer the CGeneratorEnhancements-ajh change 
enables gcc to do register colorization better, and for intel it 
seems to be doing something? But I don't know what, since I wouldn't 
know what good i386 assembler is...

I didn't test the CGeneratorEnhancements-ajh separately,
or the case of jumptable pointer logic and global structure together.

I'll leave that upto the intel folks to decide what the best combo is?


-- 
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================