Thanks John! I'll save this for when I actually start looking at, even though I said I already was. I am reading Tim's chapter to get familiar with it all. I'm going to need to add a word to the object header, I think.
cheers, Rob
On Oct 18, 2007, at 9:49 AM, John M McIntosh wrote:
I am currently trying to understand what to do with all of the global variables used in the interp loop, so I can have multiple threads running that code.
Ah, well my intent was to ensure there was no globals, however there are a few because.
sqInt extraVMMemory; /* Historical reasons for mac os-9 setup, not needed as a global now*/ sqInt (*compilerHooks[16])(); /* earlier versions of the code warrior compiler had issues when you stuck this in a structure, should be fixed now usqInt memory; /* There where some usage of memory in ccode: constructs in the in interp, I think these might be gone now void* showSurfaceFn; /* not sure about this one
struct VirtualMachine* interpreterProxy; /* This points to the interpreterProxy, It's there historically to allow direct linking from support code, but really you should use an accessor.
The rest are set to values which you can't do in a struct, however somewhere in or before the readImageFromFileHeapSizeStartingAt you could allocate the foo structure and initialize these values. There of course is some messy setup code in the VM that might refer to procedures in interp.c before an image is loaded of course, that is poor practice, you would need to root that out.
char* obsoleteIndexedPrimitiveTable[][3] = { const char* obsoleteNamedPrimitiveTable[][3] = { void *primitiveTable[577] = { const char *interpreterVersion =
--
===== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com ====================================================================== =====