On 5 April 2010 16:49, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
igor
I'm confused. Do you want to write C code in our smalltalk editor? (as in Smalltalk/X)
err.. no. why i would want that, if i can just generate native code directly? We could use Exupery for generating it, with slight modifications. Or implement different native code generator.
Where the native code is coming? Who compiles it? Can I edit it?
There is no any implications where the native code comes from. It could be from compiler, implemented in smalltalk, or may be stored in some file.. not really matters. And yes, you can edit the code and generate it dynamically. If you look at example of how i did run a native code routine, it creates a native code on the fly, code := #(184 85 0 0 0 195) asByteArray. trailer nativeCode: code platformId: 1. method := (self class methodDict at: #theStub) copyWithTrailerBytes: trailer. and then runs it, by invokind a generated method. Here, the #(184 85 0 0 0 195) is an x86 instructions: mov eax, (42 << 1 +1) ret so, when you run it, a native routine returns a 42 smallinteger.
Do you have a scenario in mind to help understanding what is your vision behind your suggestion? Stef
On Apr 5, 2010, at 10:13 AM, Igor Stasenko wrote:
Hello again,
it is about running a native code , stored in compiled methods.
All we need is:
a) allow code execution for object memory. On most platforms this is trivial - just pass additional flags to virtual memory allocation functions. b) add a single primitive 'call a native code' c) use a special compiled method trailer, which will store the native code inside itself
Then we could place any native code inside a compiled method and use a single primitive to run this code. This is quite simple thing, given that both pharo and squeak adopted method trailers, so a primitive, before running the code, needs few checks: - a method's trailer format is valid (we could reserve a terminal byte value for that) - a native code, placed inside a method trailer is targeted for same platform as currently running on
if not, then primitive will simply fail, and interpreter will run the method's bytecode, which , depending on a situation, can check if it can recompile the code (if platform doesn't match) or use a workaround. The only limitation of such approach, that native code, placed in compiled method should be relocate-agnostic, i.e. never use absolute jumps, only relative ones and so on.
Also, we could force, that code using a specific calling convention, so it will be easy to fetch values from stack and other useful stuff from interpreter/object memory (like passing an interpreterProxy pointer). This could be a good answer in generating a trampoline code for FFI/Alien on the fly.
What you think?
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.