Dan writes:

>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.

>Another issue is that I'd rather not annotate
>every method in the VM with what file it should go into.

And I'm not sure you can -- many are inlined and will go into a 
plural number of files.

>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.

>A third issue is that the current "single interp.c" file
>is extremely convenient if it works with your compiler. Thus,
>separate VM file generation should be an option that can
>be turned off.

Absolutely agreed.  It is not too important for me, by the way -- 
splitting for MrC wasn't a big deal.  I was responding rather, to 
others who seemed to need to do a much more complex splitting.

>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.

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.