Multy-core CPUs

Robert Withers reefedjib at yahoo.com
Thu Oct 18 17:57:19 UTC 2007


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 at smalltalkconsulting.com>
> Corporate Smalltalk Consulting Ltd.  http:// 
> www.smalltalkconsulting.com
> ====================================================================== 
> =====
>
>
>




More information about the Squeak-dev mailing list