True, true.  To compile in MPW, the Apple version of interp.c needs to be divided in two if the highest optimization options of MrC compiler are used.  (Compiles fresh and clean on ordinary settings).

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.

By the way, you can always produce a listing of procedure names using traditional tools (or use the regular expression plugin to fabricate your own 3-line grep) to perform all the tasks you are doing by hand.

To split it up, all you really need to do is to copy the preamble portion of the code, and then split up the sources at any procedure break.  If you are using global optimizations, you might want to take some care which procedures go in which portion, but that's another thing.

Now, all that being said, I see no reason why the Smalltalk Cgenerator cannot do this for us automatically, perhaps by having a 

	self file: 'filename.c'

which adds a new filename to a list and, upon translation writes preambles to all of the files on the list, but writes the translated procedure only to the specified files, or to the default.  This would permit rudimentary 'modularizing' for the purposes we describe here.

-----Original Message-----
From:	MIME :rlpcon at vermontel.net Sent:	Saturday, May 08, 1999 11:19 AM
To:	squeak at cs.uiuc.edu
Subject:	Re: size of interp.c

At 8:12 PM -0400 5/6/99, Andrew C. Greenberg wrote:
>Please understand that interp.c is NOT source code -- its OBJECT
>code, translated to C from the interpreter source codes.
>Accordingly, its no surprise that you would find the code unreadable
>-- in the form you are reading it, it has already had comments
>cleared, inlines inserted and details munged.
>
>The source code is written in Smalltalk, not C, and is available
>under Squeak in the several classes in category Squeak-Interpreter,
>and it is beautiful to behold.  Understanding this is fundamental to
>understanding Squeak's core design principles.  More can be gleaned
>on this point from the excellent "Back to the Future" article,
>available at the Squeak web site.

This is "ideally" good philosophy but in practice may not be helpful in
certain cases. In working on the BeOS port, I have found the need to check
interp.c for possilbe symbol name conflicts and the number of functions in
interp.c stresses even good tools like BBEdit. Additionally, I have just
run into a case where the size of interp.c exceed the compiler capabilities
forcing me to split interp.c.
--dick


=================================
R. L. Peskin,  Rutgers Univ.
;<peskin at caip.rutgers.edu>;<http://www.caip.rutgers.edu/~peskin>
RLP Consulting <rlpcon at sover.net>; <http://www.sover.net/~rlpcon>


 << File: ENVELOPE.TXT >>