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
|