global variables as structure in VM.

John M McIntosh johnmci at smalltalkconsulting.com
Sat Apr 6 00:07:14 UTC 2002


To the List and Dean, and Ned

At 1:11 PM -0500 4/5/02, Swan, Dean wrote:
>John,
>
>	This would be *VERY* useful to me.  One of the odd limitations
>of the EPOC OS (on various Psion machines, and the Nokia 9200
>communicators) is that fully compliant applications must not use
>global variables (other than one pointer to a heap structure), so
>this is *exactly* what is necessary to get Squeak going on these
>machines.
>
>	There has been some discussion about doing this, but nobody
>has had the time to actually tackle it, so if you can make this
>available, I might allocate some time to finally getting Squeak
>running on my Series 5mx (36 MHz ARM7).
>
>					-Dean Swan

Alright I've attached the change set.

Note it's a bit dated. I see it zaps the current set of instance vars.
Therefore someone can take it and bring it up to the current level. So don't
just file it in because I'll bet you'll break things in a current image.

Two

It's not smart enough to deal with the issue of interp.c, versus other plugins.
That too can be fixed, but I don't have a *real* need for it, thus someone
who really needs it could make it so it's more intelligent.

Three

It has some exceptions coded. Why well the compiler whines about 
attempting to initialize variable within a structure. A bit of clever 
work could break out these initializations to be done at runtime.

Also one or two variables are lurking in hard coded C thingees in 
interpreter. These can be fixed by a bit of code adjustments, to 
interp.c, and or changes to interpreter to avoid doing that type of 
crime, the later choice is something someone should do anyways.

Four

I've a bit of a hack (really a large should never do hack) to figure 
out how many occurrences of a variable we have have and sort by that, 
versus alphabetical. For those with interest in cachelines etc, you 
can see where I'm going with this. Having highly used (of course 
judging what that is is an issue) variables on the same cache line 
only makes more sense... The first ten variables are
struct foo {
int stackPointer;
int lkupClass;
int instructionPointer;
int theHomeContext;
int successFlag;
int activeContext;
int specialObjectsOop;
int newMethod;
int messageSelector;
int method;

I've always doubted that we've cachelined highly used variables by 
alphabetic name anyways. This too could be made smarter, or allow for 
user input on the choice.

Five
have fun.

-- 
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================
-------------- next part --------------
Skipped content of type multipart/appledouble


More information about the Squeak-dev mailing list