size of interp.c
Andrew C. Greenberg
werdna at gate.net
Wed May 12 11:46:06 UTC 1999
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.
More information about the Squeak-dev
mailing list
|