At 2:43 PM -0400 5/8/99, agree at carltonfields.com wrote:
>But this has nothing to do with the point to which I have responded.  The question was whether interp.c was less understandable because of its size.  To massage interp.c is one thing -- its something you can do easily, by the way, particularly if you have read and understood the Smalltalk sources, but to try to read it for comprehension is another.

To me, it seems much preferable to read the VM source code within
Squeak itself, where you have the comments and can use the
tools of the Squeak environment to find senders and implementors
and so forth. In that context, the VM is broken into several
classes (ObjectMemory, Interpreter, BitBltSimulator) and within
those classes, methods are grouped into categories.

However, if you really want to read the VM as C code, it
may help to generate the code with inlining turned off.
This produces a much smaller source file factored into a
bunch of small, simpler to understand C functions. This
code would run more slowly, but if the goal is only to
understand the VM, this is much better, since there is
less code to wade through.

This trick might also help Richard Peskin or others who are
trying to work with the VM in a C developement environment.

Another thing you can do is to translate each VM class
separately. What you get won't directly compile, but you'll
have a rough modularization that may help you understand
each piece more easily.

I've actually been surprised that most C compilers can handle
our large interp.c file. I thought we'd be forced to break
it into seperate files at some point. But for now, it actually
makes our development task easier to keep it in one giant
file.

	-- John