On Thu, Dec 06, 2001 at 05:20:42PM -0800, Travis Griggs wrote:
Don't know if I understand the context completely... ST/X doesn't have primitives. It just has inline C code. Want to see how integers added in the browser? You just browse to that method and there the C/Smalltalk/assembler is! Want to look at how Object>>basicNew works? Go for it. What's more (and not even Squeak can do this one). Want to change the way basicNew work (say, add an extra byte to every object header and printf the address of each new object). Make the change and hit accept button. Realtime, right there, it happens.
Hi Travis!
Yes, you are right: the current version does not have primitives. The primitives are "normal" Smaltalk-To-C statically compiled methods (with inlined C-code).
But: The problem is that the image is not portable across architectures anymore. You can even run into problemes simply by re-compiling the VM using a different compiler. (There are pointers in the saved image to code generated by the C-compiler, these won't be the same on an other architecture) There are some hacks to prevent running such an image, and it tries hard to fix the refences, but according to Claus this never really worked in all cases. So he decided that the new VM (I think for version 5?) will have "real" primitives. (As an execution-mechanism, it will look the same for the programmer. You won't see <primitive 224> but the code of the primitive...) He talked a little bit about the new vm some time ago, the following is what I understood from his description (My understanding might not be entirely correct...):
The "primitive" methods are like "normal", not-yet-jitted Smalltalk methods (*codeptr is nil), but they have the "primitive" bit set. If such a method is called the first time, the vm looks up the right adress for the primitive and sets the *codeptr.
If the codeptr is nil and we have a non-primitive method, the jitter is called to produce native code. The code is held in a cache outside the image, and the adress of the code is stored in the codeptr.
If we compile a Method with the Smtlk-To-C Compiler, stc produces a C-source-file, gcc compiles this to an dll (.so), it's loaded at runtime (dlopen()), and the *codeptr is updated to point to the right function.
If the codeptr is not-nil, run the code at that adress.
Tim asked:
Mmm, is it just the one pointer?
Yep. In the prototype-interpreter claus re-used the codeptr to store the primitive-number. So a one-bit flag for primitives is sufficient.
What happens with a primitive _and_ translated Smalltalk backup code? Or is that not allowed?
I don't now... but the simplest thing would be to make that method a non-primitive-method, and than translate it with the Smlt-To-native-compiler, update the codeptr to that new method. (That image would not be platform-independend anymore).
There might be even more intelligent ways to do this, like checking the the dlls for certain names and patching the primitive table or something like that... actually the question is if you'd need a real primitive table with numbered primitives at all: searching by name should be fast enough if it's only done once.
Marcus