sig writes:
 > On 14/07/07, tim Rowledge <tim at rowledge.org> 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