A small idea how to get closer to hardware with small efforts :)

> 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.
>

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> On Mon, Apr 05, 2010 at 03:13:51PM +0300, Igor Stasenko wrote:
>> Here the proof of concept implementation.
>
>
>> So, here the questions, which i like to be answered:
>> 1. reserve a numbered primitive
>
> Probably a named primitive in the interpreter is best, see comment in
> John's new primitiveMicrosecondClock. I don't think that there is any
> performance implication once the primitive name has been resolved once.
>

>> 2. discuss the calling convention
>> 3. add a 'platform id' code to VMMaker, and let language side know ,
>> on which platform id VM currently runs on (through additional
>> primitive)
>
> I'm not sure how to handle #3, but there are a lot of different CPUs
> and operating systems out there, not to mention all the different modes
> of say an Intel CPU. So it may not be trivial to answer the question
> "can this snippet of compiled code be executed in my current runtime
> environment".
>

> Hi,
>
> I always liked how Smalltalk X did it... they have
>
>        -> an ivar in CompiledMethod that is the "native code pointer".
>        -> Primitive methods are just methods that have this pointer set
>             to the primitive in the vm.
>        -> Methods with embedded C-code are compiled and linked with
>             the Smtk->C cross-compiler, the pointer than points to that function
>        -> the JIT just put a pointer to the code it generates.
>
> So they merge primitives / static compiling(+embedded c-code) *and* the JIT
> into one not that ugly mechanism. In STX, the memory is managed by the VM, though (the
> code is not allocated in the GCed object memory by the JIT).
>
> So: Yes, I like this :-) and your mechanism is a nice way to get it easily integrated into the current
> system.
>
> Q: what happens when code is moved by the GC?
>

> --
> Marcus Denker  -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>