size of interp.c

agree at carltonfields.com agree at carltonfields.com
Tue May 11 20:48:17 UTC 1999


This was, of course, the point I was trying to make.  Reading for comprehension should be done solely from within Smalltalk.  The suggestion that the code generation routines be modified as I described was not to facilitate reading, but to make it unnecessary to manually split interp.c for compilers incapable of handling 1MB or larger files.  For example, MPW's MrC cannot compile interp.c at the higher levels of optimization unless the files are first split.  Doing the splitting is relatively easy to do manually, but it is a pain, somewhat error-prone, and one that could be automated without much effort.

The idea was that the code can be written into "component" files for separate compilation, each with an identical preamble, so that the compiler can compile the files separately, and the linker can do the work of binding things together later on.

-----Original Message-----
From:	MIME :John.Maloney at disney.com Sent:	Tuesday, May 11, 1999 4:40 PM
To:	squeak at cs.uiuc.edu
Subject:	RE: size of interp.c

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



 << File: ENVELOPE.TXT >> 





More information about the Squeak-dev mailing list