Andrew,

At 7:46 AM -0400 5/12/99, Andrew C. Greenberg wrote:
>>This is certainly do-able, but would require a bit more,
>>such as a generating a shared header file and a strategy
>>for dividing global variables among the various .c files.
>
>>I'm not sure why.  It seems to me that the header file for each of
>>the split "modules" would be the same.  Why would you need to
>>"divide global variables" among the various ".c" files?  Just define
>>the variables in one of the files, and declare them in the rest.
>>This isn't for beauty -- its simply to facilitate a compile for
>>compilers that can't handle the bloat.  Quick-and-dirty does it.

Good point.


>>It's doable, but adds clutter. However, it might be sufficient
>>to break the VM into files based on their class (ObjectMemory,
>>Interpreter, ...). Would this result in small enough files
>>to use Mr. C's optimizer, do you think?
>
>I divided the file into two small pieces and it worked.  You might
>contemplate dividing it optionally by class or by method category.

Thanks for the data point.


>>One thing you might try before doing anything else is
>>just increasing (substantially) the amount of memory you
>>give Mr. C. I found that this really helped CodeWarrior
>>handle certain tasks, such as disassembling the entire VM.
>>If this works for you, there may be no need to go further.
>
>Of course I did that.  I gave Mr.C and MPW the entire machine (not
>huge, a mere 64MB, less the memory allocated to the OS) -- no
>improvement.

Too bad that didn't work...


>Old habits die hard -- I have been using MPW since it came out (and
>Lisa Pascal before that) in doing my Mac development, and never moved
>to CodeWarrior.  Now, I may just have to hunker down and buy a copy,
>as I note the 2.4 VM codes are going back to inline assembly language.

Don't be hasty! We aren't generating any inline assembly language
in interp.c. At some point, Jitter II may use some inline assembly
macros in the C support code, but those will be done in as generic
and portable way as possible. My reference to disassembing above
refers to the fact that we've studied the disassembled VM code to see
how to improve it in certain critical places. However, we made
the improvements in the Smalltalk VM source code once we understood
what to do.

There's one more easy thing we might try as a way around
having to split interp.c to make MrC happy. Currently, the
original definitions of inlined functions are output by the ST-to-C
translator even though they are no longer called directly. It may
be that if we suppress those definitions, the code will be small
enough to make MrC's optimizer happy.

If you file in the enclosed change set and translate a new interp.c,
the resulting file will be about 280 kbytes smaller than before.
Let me know if MrC can compile this file using full optimizations.
Thanks!

	-- John

Attachment converted: Anon:pruneInlinedMeths-jhm.cs (TEXT/R*ch) (0000A682)