Free primitive indexes
Locked
 
|
Hello, squeak-dev,
I found, that numeric primitive table in squeak have many gaps, filled with 'primitiveFail', and with comments like 'no longer used' and other.. Id like to use one of the slots, but have no idea, what number is really safe for use? Any suggestions/reasoning? |
|
|
On 13-Jul-07, at 4:42 PM, sig wrote: > Hello, squeak-dev, > > I found, that numeric primitive table in squeak have many gaps, filled > with 'primitiveFail', and with comments like 'no longer used' and > other.. > Id like to use one of the slots, but have no idea, what number is > really safe for use? > Any suggestions/reasoning? You don't get to use numbered primitives. That is reserved for those of us with god-like powers. Seriously, unless you are doing something quite extraordinary, don't even think about using numbered primitives. Write a simple named primitive and put it in a plugin if at all possible. If you really can't manage that, write a named primitive that will get left in the vm core. See, for example - Interpreter>primitiveDisablePowerManager "Pass in a non-negative value to disable the architectures powermanager if any, zero to enable. This is a named (not numbered) primitive in the null module (ie the VM)" | integer | self export: true. integer := self stackIntegerValue: 0. successFlag ifTrue: [ self ioDisablePowerManager: integer. self pop: 1]. "integer; leave rcvr on stack" and usage- PowerManagement class>disablePowerManager: aInteger "Disable/Enable the architectures power manager by passing in nonzero or zero" <primitive: 'primitiveDisablePowerManager'> "primitiveExternalCall" ^ self There is no advantage to numbered primitives. Once the method lookup has been done the primitive function's address is stored in the cache so any primitive gets exactly the same treatment at that level. IF I had the time to spare I would have had a go at removing numbered prims altogether. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Do files get embarrassed when they get unzipped? |
|
|
Thanks for fast response.
Maybe i need to explain, what i want to achieve, so you can guide me, what is the best way for doing that. I need only single primitive, which appear only in methods, compiled by my special :) Compiler subclass. The goal is to create a special compiled methods, which will invoke any native code as primitive based on info object, which will be encoded in method literal. This is the same way as FFI does - it encodes FFI call in method's literal and then puts a #120 primitive in method header. When interpreter enters the method, it calls primitive 120, which decodes info in method's literal and know what to do next, based on this info. I'd like to do in same fashion as FFI does, but providing own ways what to invoke and where to get code/pointers i need to call. The simplest way i found is to copy-paste FFI code, where it generates compiled method and simply change primitive number, and object to put in method literals. For this reason i need a free indexed primitive slot. On 14/07/07, tim Rowledge <[hidden email]> wrote: > > On 13-Jul-07, at 4:42 PM, sig wrote: > > > Hello, squeak-dev, > > > > I found, that numeric primitive table in squeak have many gaps, filled > > with 'primitiveFail', and with comments like 'no longer used' and > > other.. > > Id like to use one of the slots, but have no idea, what number is > > really safe for use? > > Any suggestions/reasoning? > > You don't get to use numbered primitives. That is reserved for those > of us with god-like powers. > > Seriously, unless you are doing something quite extraordinary, don't > even think about using numbered primitives. Write a simple named > primitive and put it in a plugin if at all possible. If you really > can't manage that, write a named primitive that will get left in the > vm core. > > See, for example - > Interpreter>primitiveDisablePowerManager > "Pass in a non-negative value to disable the architectures > powermanager if any, zero to enable. This is a named (not numbered) > primitive in the null module (ie the VM)" > > | integer | > self export: true. > integer := self stackIntegerValue: 0. > successFlag ifTrue: [ > self ioDisablePowerManager: integer. > self pop: 1]. "integer; leave rcvr on stack" > and usage- > PowerManagement class>disablePowerManager: aInteger > "Disable/Enable the architectures power manager by passing in nonzero > or zero" > <primitive: 'primitiveDisablePowerManager'> "primitiveExternalCall" > ^ self > > There is no advantage to numbered primitives. Once the method lookup > has been done the primitive function's address is stored in the cache > so any primitive gets exactly the same treatment at that level. IF I > had the time to spare I would have had a go at removing numbered > prims altogether. > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Do files get embarrassed when they get unzipped? > > > > |
|
|
OK, you got me there. That's probably the only good reason you could
possibly have a need for a prim number! I suggest using 169, next to primitiveCopyObject - at least for now. You will, of course, be making your design so nicely factored and intelligible that it could be changed at any time without causing a problem, won't you :-) tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: HALT: No-Op |
|
|
On 14/07/07, tim Rowledge <[hidden email]> wrote:
> OK, you got me there. That's probably the only good reason you could > possibly have a need for a prim number! > > I suggest using 169, next to primitiveCopyObject - at least for now. > You will, of course, be making your design so nicely factored and > intelligible that it could be changed at any time without causing a > problem, won't you :-) > Thanks for advice. I making awful hacks ;) to be able directly execute code, compiled by Exupery, as primitive. The trick is, whenever compiler founds <assembler> pragma in method code, it generates call to my primitive, and puts in method literal info on what should be called. The bytecode of method is replaced with error-handling, when primitive failed. > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Strange OpCodes: HALT: No-Op > > > > |
|
|
sig writes:
> On 14/07/07, tim Rowledge <[hidden email]> wrote: > > OK, you got me there. That's probably the only good reason you could > > possibly have a need for a prim number! > > > > I suggest using 169, next to primitiveCopyObject - at least for now. > > You will, of course, be making your design so nicely factored and > > intelligible that it could be changed at any time without causing a > > problem, won't you :-) > > > Thanks for advice. I making awful hacks ;) to be able directly execute > code, compiled by Exupery, as primitive. > The trick is, whenever compiler founds <assembler> pragma in method > code, it generates call to my primitive, and puts in method literal > info on what should be called. The bytecode of method is replaced with > error-handling, when primitive failed. If you're running in a VM that supports Exupery then you could just register a compiled method with Exupery's runtime so that it gets executed instead of the interpreted method. Look at what Exupery does when it compiles a primitive, say Array>>#at:. It'll generate code that will be called by the interpreter (or another compiled method) and it will get the primitives arguments from the senders context. Only if the compiled version of the primitive fails will it then create a context just like the interpreter. In your case, if you only want this for native code the using Exupery's current method is probably easier and definately more flexible. Exupery can over-ride any method with compiled code. It has to as it's a native Smalltalk compiler. Bryce |
|
|
On 14/07/07, [hidden email] <[hidden email]> wrote:
> sig writes: > > On 14/07/07, tim Rowledge <[hidden email]> wrote: > > > OK, you got me there. That's probably the only good reason you could > > > possibly have a need for a prim number! > > > > > > I suggest using 169, next to primitiveCopyObject - at least for now. > > > You will, of course, be making your design so nicely factored and > > > intelligible that it could be changed at any time without causing a > > > problem, won't you :-) > > > > > Thanks for advice. I making awful hacks ;) to be able directly execute > > code, compiled by Exupery, as primitive. > > The trick is, whenever compiler founds <assembler> pragma in method > > code, it generates call to my primitive, and puts in method literal > > info on what should be called. The bytecode of method is replaced with > > error-handling, when primitive failed. > > If you're running in a VM that supports Exupery then you could just > register a compiled method with Exupery's runtime so that it gets > executed instead of the interpreted method. > > Look at what Exupery does when it compiles a primitive, say > Array>>#at:. It'll generate code that will be called by the > interpreter (or another compiled method) and it will get the > primitives arguments from the senders context. Only if the compiled > version of the primitive fails will it then create a context just like > the interpreter. > > In your case, if you only want this for native code the using > Exupery's current method is probably easier and definately more > flexible. Exupery can over-ride any method with compiled code. It has > to as it's a native Smalltalk compiler. > But i want to support different use cases: - use generated code as native method. In this case i think registering native method with exupery is most appropriate. - use generated code as primitive function The compiled code will be registered in VM as named primitive, and can be used in other methods by writing <primitive ... blabla> In this case i need not to register native code with exupery. All i need is just to place stub bytecode in CompiledMethod which will complain about executing this method directly. - use generated native code elsewhere (cdecl functions, callbacks e.t.c) A compiled native code, will be registered in separate code repository. And result of compiling this method will be just a stub CompiledMethod to complain about direct execution this method by Interpreter. > Bryce > > |
|
|
In reply to this post by Igor Stasenko
On Sat, Jul 14, 2007 at 02:42:07AM +0300, sig wrote:
> Hello, squeak-dev, > > I found, that numeric primitive table in squeak have many gaps, filled > with 'primitiveFail', and with comments like 'no longer used' and > other.. > Id like to use one of the slots, but have no idea, what number is > really safe for use? You should follow Tim's advice, but to answer your question directly: Recent Squeak versions have lost all of the version history associated with the interpreter and object memory (and lots of other things as well). Nevertheless, you can still download an older version of Squeak and simply compare the #initializePrimitiveTable method to a current one and see what has changed. That will give you a good idea of what primitive numbers have actually be used over the course of the last eight years or so. For example, I just downloaded Squeak 2.4c (a good solid release from 1999) from ftp.squeak.org. I ran it under a new VM (64 bit Linux VM on AMD actually). Not everything works properly, but it's easily good enough for browsing the old image and seeing what's different. The files I looked at are here: http://ftp.squeak.org/2.4/Squeak2.4c.image.gz http://ftp.squeak.org/2.4/Squeak2.4c.changes.gz http://ftp.squeak.org/2.0/SqueakV2.sources.gz The #initializePrimitiveTable in Squeak 2.4c contains an initial version (from John Malony, April 1999) plus one update by Andreas Raab (May 1999). If you want more version history that this, you can try downloading a more recent Squeak and find something that still has the VM in the image (i.e. prior to VMMaker being split off as a separate package). After that point, you would need to look at the VMMaker versions to see what changes have occurred. Dave |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |