"official" VMs

Raab, Andreas Andreas.Raab at disney.com
Wed Aug 23 20:13:04 UTC 2000


Ian wrote:
> PPS: I hesitated to cc this to the list.  Does anyone beyond 
> the four or five people involved in this thread care in the slightest?

Because of the responses I'm posting this to the list too.

> (Aside: I'm still waiting for someone to explain to me why we need to
> keep an explicit table of primitive function addresses in the VM at
> all [which is the unique cause of all of these problems], when we
> could just use the "original" module mechanism to find any "internal"
> plugins by gazing into the navel of the executable itself [which it
> did already, to find the "intrinsics"].  Or did I miss a good logical
> argument against this?)

I haven't been following the entire discussion so I'm not sure what unique
cause of problems you're referring to but it should be the case that for any
'internal' plugin no OS specific code whatsoever is involved. The logical
argument for this is that we do have a number of platforms that do not
support looking up named primitives from the Squeak executable itself very
well.

The Mac VM, for instance, has problems when running as a plugin. It may
(depending on spelling and location of the plugin) start a new -
uninitialized - Squeak VM where calling primitives can fail in a very hard
and unexpected way. Another example is WinCE which does not support loading
named primitives from the running executable itself (although it does
support loading named prims from a dedicated shared library). This, in
addition to some stuff we want to do with some bare hardware machines or
machines like game consoles lead us to redefining the 'internal' lookup
mechanism so that no OS specific code whatsoever is involved.

Bert wrote:
> I'm afraid so. The explicit table is for looking up internal 
> primitives ONLY. These adresses may get overwritten at runtime
> if an external module is present.

Not quite. The lookup mechanism searches for an 'external' module first. If
that is found it is used. If the 'external' module is not found then the VM
looks for an internal module (as I said above with no OS mechanisms
involved). If any such internal module is found it is used. There is no
overriding of any addresses at runtime, simply because you may unload an
'external' module and then reload the builtin version. That's working quite
nicely.

> Oh, wait again. Did you actually notice all the module files are
> dependend on being generated for internal/external access?! Even the
> function names are different. For internal functions, it's
> "Modulename_Functionname" to prevent name clashes. For external
> modules, it's only "Functionname" which get's looked up in module 
> "Modulename". (IMHO we should change the generated code so it only 
> depends on one flag being defined.)

It's possible to do this but it's a bit tricky since it requires some
renaming magic and some magic in the module version string (which is
reporting an 'i' for a builtin and an 'e' for an external version). Also,
the variable declarations may need to be modified - right now, the builtins
declare all variables as static (again to prevent name conflicts).

Ian also wrote:
> One final point: the entire suite of configuration and build tools
> mentioned above knows (in theory) how to deal with Windows.  Maybe
> Andreas and I can figure out how to make it all work nicely both there
> and on Unix with a single, common build process.

Actually, I've just dumped a bunch of Win32 related code into your release
tree, adjusted the Makefile slightly, typed 'make' and watched a brand new
VM happening. Seems to be working quite nicely.

  - Andreas





More information about the Squeak-dev mailing list