On 19-Apr-08, at 7:22 AM, Riccardo Lucchese wrote:
>>
>> AFAIK the interp.c is generated with VMMaker, so for a new vm, you  
>> have to
>> run your script again. A pure Squeak solution might be better.
> I don't understand what you mean. I just patched the c file and
> rebuild squeak (interp.c doesn't get generated
> at every build.)

The VM code exists in two parts
a) the handwritten C (or C++ in some places) that implements the  
platform specific bits of the system such as  the interface to the OS  
filing system, the IO etc. There are also some VM plugins with  
handwritten parts.
b) the Slang code implemented in Smalltalk that get translated into C  
by the VMMaker tool.

VMMaker is discussed at http://wiki.squeak.org/squeak/VMMaker and  
related links. It translates the relevant classes, writes the  
translated code to files, copies some of the handwritten files to suit  
the platform make setup and creates some config files. Each platform  
then has its own idiosyncratic (not to mention frequently idiotic)  
process to follow to compile and link that bunch into a working VM and  
(possibly, depending on details not relevant here) plugins.

The central VM file is interp.c and you really shouldn't waste your  
time playing with it. It is barely readable, poorly structured and  
should be considered a temporary intermediate file; would you bother  
trying to read the intermediate language file(s) some compilers  
produce? The exception to this is when you have some really simple  
problem in the compiler - like complaints about a type mismatch for  
example - that you can very quickly edit in interp.c to see if it can  
be made to compile, after which you have to make the proper fix in the  
Slang code. Again, interp.c is a temporary file that should never ever  
be saved in any source control system. And yes, I know that it  
frequently is, and that is just plain bugfuck stupid.


With regard to your original message about the bytecode dispatch  
'switch' statement - well I don't think I've seen a compiler do  
something that dumb in a long time. A jump or branch table is the  
normal case and as has been mentioned the 'gnuify' step in the  
makefiles of most platforms even improves upon that when possible. One  
could consider building a table of function pointers and indexing into  
it with the bytecode - but that would put the table outside the run of  
the code and would require bytecode routines to be functions etc etc.  
In the current system the bytecode 'functions' are textually inlined  
into the main interpret() function as you would see by examing the  
VMMaker related code. It is distressingly easy to come up with  
'optimisations' that completely ruin performance. Further, the  
bytecode dispatch time is unlikely to figure anywhere in typical  
performance profiles. Would anyone really characterise the performance  
of a system on the basis of how fast it can do trivial loops? Or is it  
more sensible to have decent benchmarks that reflect real usage?

It is important to measure the right things the right way under the  
right circumstances if you want to uncover meaningful facts. In the  
early days of RISC development the designers would explain about how  
they ran benchmarks to find out what a cpu really spent its time doing  
and then they designed the architecture to optimise for those  
activities - no Test Left, Shift Mask and  Dim the Lights instruction  
for us! - so that all would be wonderful. It was rather slyly pointed  
out that this could only result in a cpu that could run diagnostics  
and Eratosthenes Sieve *really* fast and left everything else to  
exception handling

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Futuristic: It will only run on a next generation supercomputer.