[UNIX]Re: VM generation problem (Linux)

Tim Rowledge tim at sumeru.stanford.edu
Mon Sep 18 22:47:12 UTC 2000


Mats Nygren <nygren at sics.se> is widely believed to have written:

> Tim Rowledge <tim at sumeru.stanford.edu> wrote:
> 
> > To generate a plugin as internal, simply add it to the list in 
> > 	Interpreter class>translate:doInlining:forBrowser
[snip]
> This can be slightly simplified for the beginning VM rebuilder. (And
> others).
> Have a class method in 
> Interpreter class>>directModules
[snip]
Yes, obviously that makes a start. I think you'll find some recent
submissions by Stephan rudlof and/or Rob Withers that are working in
that direction. I anticipate imminent release of a more up to date
version.

> In a slightly longer perspective I would like to separate the two roles of
> the Interpreter module,
> - it is a byte code interpreter
> - it is the main organizer of modules
> 
> One could start by having a new module (internal!) and move the handling
> of modules to it. Incuding primitive dispatch possibly?
Err, be very careful about infinite recursion here. If you have a module
to handle modules, just where are you going to handle the module handler
module when it needs handling? I suspect it's simpler just to make
it part of the basic code.

Swapping the interpreter whilst running would be fun, but I'm not sure
it would be terribly useful. Something  have been agitating for over
some considerable time now is a range of modules for different levels of
execution engine and memory handler. Simply being able to specify that
you want a safe execution engine (and you'll accept slow performance to
get it) and a ultra cautious, journalling and transaction object memory
for you payroll system, as opposed to a dead-simple object memory for
that script runner that will exit within a few seconds and all the
levels in between, would be very nice.

[snip]
> > There is one annoying complication with this flexibility and that is
> > that the files associated with each plugin need to be placed in the
> > right directory; if you move BlahPlugin from internal to external you
> > may have to also (manually for now) move the associated files foo.c and
> > foo.h across to the BlahPlugin directory. My claim is that a simple tool
> > should be able to handle all this for us, but it isn't written quite yet.
> 
> I dont follow but I have trouble enought to get a VM working with
> internal modules. But I agree this should be possible and should hope
> it will be done. Or perhaps the files can be left alone and the decisions
> about internal/external can be communicated some other way?
See above comment about Rudlof/Withers tool.
> 
[snip]
> There has been some extra complications recently,
> reorganized directories, bug in sqPlatformSpecific.h, FFI. Excellent
> timing to try to understand it all:) I'll get it soon (I hope). 
> 
> Then, since I'm getting deeper into this and it's not
> possible to ignore the module/plugin structure and naming, I will try to
> simplify this. In particular I wish to split the global table for
> primitive names/addresses so that the corresponding subtable occurs in
> each plugin instead. (Whether internal or external). Your considerations
> on that?
The internal module functions that are exported need to appear in a
table somewhere so that the function
sqNamedPrims.c>findInternalFunctionIn() can look them up. Using 'dlsym'
or whatever to look them up is a crime. Don't do it. Ever. If you really
want to split the 'internalPrimitiveNames' table I suppose you could but
it would serve no purpose whatsoever. Internal modules need their export
entries in this table, external modules do not even _have_ such a table
so nothing is gained by trying to unify anything here. Internal modules
are compiled into the main vm as simple .o (or .obj, whatever) files.

> 
> Furthermore I want to simplify the module naming so there is consistensy
> from module to module and between filenames and methodnames that
> contain them in the image. No one is opposing that?
Apart from such minor oddities as the large integer plugin being called
'LargeIntegers' rather than the more sensible 'LargeIntegerPlugin', what
it the problem? The plugin naming is as regular as plugin writers care
to make it, and the method names can be anything you want (aside from
the reserved names 'initialiseModule', 'getModuleName' and
'setInterpreter'.

> It would be fun to make it possible to switch plugins while running,
> as has been discussed in a recent thread. But I guess I'll have to
> be able to crawl first.
Already doable, and has been for about six months. Look at
sqnamedPrims.c>unloadModule and SystemDictionary>unloadModule: Works
perfectly well so long as the plugin follows the rules properly and
implements shutdownModule() if anything needs closing or freeing when it
is killed.

Please, folks that are having problems with this internal/external
module stuff, _read the code_ . It's actually quite well commented and
will explain most of the issues people keep complaining about.

Sheesh, Andreas, did I say that giving people the choice would cause
confusion, or what! :-)


tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- One pearl short of a necklace.





More information about the Squeak-dev mailing list