Hi,
could someone explain me primitive 117? I know the primitive is responsible for loading some kind of modules. But where do I find these modules.
For example "Integer>>#bitAnd:" contains "<primitive: 'primDigitBitAnd' module:'LargeIntegers'>", which will load the 'primDigitBitAnd' method of module 'LargeIntegers'. Are these modules some kind of plug-ins outside the squeak image? Can I access these modules and check their implementation?
best regards, Helmut
Hi Helmut.
I am a rookie, but I will attempt an answer.
LargeIntegers is a plugin.
The Squeak source code is here: svn co http://www.squeakvm.org/svn/squeak/branches/Cog Pharo you have to checkout from git: git clone https://github.com/pharo-project/pharo-vm.git
I will only cover Squeak in the rest of this email.
LargeIntegers c source code is in Cog/src/plugins/LargeIntegers/
To get a sense of where the plugins are handled on the Squeak side, you will need VMMaker.oscog package from source.squeak.org. Pharo has different stuff in VMMaker-oscog. Note the difference is only a "dot" vs a "dash" in the package name.
Once you have VMMaker package loaded, Browse VMMaker-Plugins->InterpreterPlugin and its subclasses You will see LargeIntegerPlugin there.
Then do a message name search for "initializePrimitiveTable"
Different VM's implement different primitives (?) but browsing Interpreter class initialzePrimitveTable shows primitive 117 maps to primitiveExternalCall method.
You then look at the object side of Interpreter and look for method primitiveExternalCall. There you find the Squeak source code for that primitive.
That should get you started.
I am not at the level where I can explain how it all works as I have only done the "hello world" tutorial for plugins.
Cheers.
tty.
On 31.05.2014, at 15:48, Helmut Rohregger helmut.rohregger@gmail.com wrote:
Hi,
could someone explain me primitive 117? I know the primitive is responsible for loading some kind of modules.
Yes. We got tired of assigning a new number for each new primitive. In addition to indexed primitives the Squeak VM supports "named primitives". And primitive 117 is used to execute those named primitives. The module name and primitive name are stored in the CompiledMethod:
(Integer>>#bitAnd:) primitive ==> 117
(Integer>>#bitAnd:) literalAt: 1 ==> #(#LargeIntegers #primDigitBitAnd 0 25)
So when the VM executes primitive 117 it looks up that literal, loads the module, and executes the named primitive.
But where do I find these modules. For example "Integer>>#bitAnd:" contains "<primitive: 'primDigitBitAnd' module:'LargeIntegers'>", which will load the 'primDigitBitAnd' method of module 'LargeIntegers'. Are these modules some kind of plug-ins outside the squeak image? Can I access these modules and check their implementation?
They are mostly part of the VM. Many are bundled in the regular VMMaker package, but you can also find them elsewhere (e.g. the DBus plugin is at http://squeaksource.com/dbus.html )
The 'LargeIntegers' module is implemented by the class LargeIntegersPlugin in the VMMaker package.
These modules can be linked into the VM executable itself ("built-in modules") or distributed as separate files ("external modules"). In the latter case they are dynamic libraries (DLLs on Windows, *.so files on Linux etc.)
To see which modules are built into your VM:
Smalltalk listBuiltinModules
To see which external and built-in modules are currently in use:
Smalltalk listLoadedModules
There is no general way to list unloaded external modules because they are loaded on demand and can be installed in various places.
- Bert -
To expand a little -
On 31-05-2014, at 8:03 AM, Bert Freudenberg bert@freudenbergs.de wrote:
So when the VM executes primitive 117 it looks up that literal, loads the module, and executes the named primitive.
And before anyone starts complaining about how slow that is and why would we do that - the address is cached exactly as all the other primitive code addresses are. It’s possible there is an OS that requires some time-sucking intermediary but none of the ones Andreas & I originally developed the named prim stuff for had any problem.
These modules can be linked into the VM executable itself ("built-in modules") or distributed as separate files ("external modules"). In the latter case they are dynamic libraries (DLLs on Windows, *.so files on Linux etc.)
As an extreme example, RISC OS is built with all the plugins external and dynamically loaded. You can go from that extreme to the other - all built internal - and the end user will not notice any difference. One very useful trick that is (unless removed ?) there is that an external plugin trumps internal - so a buggy internally bound plugin is superseded by a suitable external one.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Military Intelligence
Am 31.05.2014 17:03, schrieb Bert Freudenberg:
The 'LargeIntegers' module is implemented by the class LargeIntegersPlugin in the VMMaker package.
These modules can be linked into the VM executable itself ("built-in modules") or distributed as separate files ("external modules"). In the latter case they are dynamic libraries (DLLs on Windows, *.so files on Linux etc.)
Are these modules written in Smalltalk and translated somehow to C code?
- Helmut
Hi Helmut.
Generally, yes. VMMaker does that.
The more experienced guys may have more to say on the matter.
cheers.
tty
---- On Sun, 01 Jun 2014 02:13:28 -0700 Helmut Rohregger<helmut.rohregger@gmail.com> wrote ----
Am 31.05.2014 17:03, schrieb Bert Freudenberg: > The 'LargeIntegers' module is implemented by the class LargeIntegersPlugin in the VMMaker package. > > These modules can be linked into the VM executable itself ("built-in modules") or distributed as separate files ("external modules"). In the latter case they are dynamic libraries (DLLs on Windows, *.so files on Linux etc.) >
Are these modules written in Smalltalk and translated somehow to C code?
- Helmut
On Sun, Jun 01, 2014 at 11:13:28AM +0200, Helmut Rohregger wrote:
Am 31.05.2014 17:03, schrieb Bert Freudenberg:
The 'LargeIntegers' module is implemented by the class LargeIntegersPlugin in the VMMaker package.
These modules can be linked into the VM executable itself ("built-in modules") or distributed as separate files ("external modules"). In the latter case they are dynamic libraries (DLLs on Windows, *.so files on Linux etc.)
Are these modules written in Smalltalk and translated somehow to C code?
Yes, that's right. In fact, some VM plugins are written entirely in Smalltalk that is tranlated to C to produce the compiled VM. LargeIntegersPlugin is an example of this.
Here are some links that will give you a better idea of how this works.
The "Back to the Future" paper by Dan Ingalls et al: http://ftp.squeak.org/docs/OOPSLA.Squeak.html
The VMMaker page on the swiki by Tim Rowledge: http://wiki.squeak.org/squeak/2105
"A Tour of the Squeak Object Engine" also by Tim: http://www.rowledge.org/resources/tim%27s-Home-page/Squeak/OE-Tour.pdf
The Cog Blog by Eliot Miranda: http://www.mirandabanda.org/cogblog/
General information about the Squeak VM: http://squeakvm.org/index.html
You should definitely start with the Back to the Future paper. I find that it is worth reading about once per year.
Dave
On 01-06-2014, at 6:47 AM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Jun 01, 2014 at 11:13:28AM +0200, Helmut Rohregger wrote:
Am 31.05.2014 17:03, schrieb Bert Freudenberg:
The 'LargeIntegers' module is implemented by the class LargeIntegersPlugin in the VMMaker package.
These modules can be linked into the VM executable itself ("built-in modules") or distributed as separate files ("external modules"). In the latter case they are dynamic libraries (DLLs on Windows, *.so files on Linux etc.)
Are these modules written in Smalltalk and translated somehow to C code?
Yes, that's right. In fact, some VM plugins are written entirely in Smalltalk that is tranlated to C to produce the compiled VM. LargeIntegersPlugin is an example of this.
You can also write the code all in C (or any other language with compatible calling rules) or any mix. Some of the bitbltplugin is written in ARM assembler, for example. Well, for the Raspberry Pi.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "How many Motie Warriors does it take to change a lightbulb?" "None. One of the dead ones will do it."
vm-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
David T. Lewis -
gettimothy -
Helmut Rohregger -
tim Rowledge