(+vm-dev)
Esteban, thanks very much for your views. You write:
On 10/16/2015 07:53 AM, Esteban Lorenzano wrote:
So… my plan is:
- NB to FFI port (should be ready soon)
- spur32 bits (should be ready soon, we are just waiting the NB to FFI)
- spur64 bits (Eliot is working on the JIT, I need to manage the
migration of Pharo)
- FFI 64bits (0% done here… just some stubs waiting for effort). But
we want to move Pharo to 64bits… we are losing a train here...
- FFI MT
and of course you are buried in existing tasks, especially the transition to 64-bits. It is my humble opinion, without really knowing, that 64-bit would have to be redone after the MTVM completes. Kinda why I would desire MTVM before 64-bits, then I assume less work would be needed overall. But that's my uneducated guess.
Perhaps Eliot could shine some light for us on the progress of MTVM and what's needed.
Because of that assumption I've made and without the responsibilities you have, Esteban, but recognizing modernizing NB to FFI, my desired list is:
- NB to FFI port (should be ready soon) - spur32 bits (should be ready soon, we are just waiting the NB to FFI) - FFI MT - spur64 bits (Eliot is working on the JIT, I need to manage the migration of Pharo) - FFI 64bits (0% done here… just some stubs waiting for effort). But we want to move Pharo to 64bits… we are losing a train here...
If *anyone* wants to collaborate in any part of this list (is a
MASSIVE effort), I would be very happy and willing to provide as much assistance/guiding/peer programming as I can.
Yes, please, and I appreciate you willingness to mentor.
Best, Robert
On 10/16/2015 07:53 AM, Esteban Lorenzano wrote:
On 16 Oct 2015, at 13:22, Robert Withers robert.w.withers@gmail.com wrote:
Bonjour Stef,
I believe the change everyone would be waiting for is a Multi-threaded VM, that supports threaded callouts and callbacks. So I suppose the questions become:
multi thread ffi vm exists as a prototype, and according to its author (Eliot) needs no less than 4 months of someone skilled working on it to finish it.
- will existing NB syntax require change with the introduction of a MTVM?
nothing will be equal… why? because you will need to provide callbacks. There is no magic here, if you want something to happen while doing something else, you need to provide a way to be called back when that thing finishes.
now we have:
nbCall:module:
to call FFI (will change to a more generic ffiCall:module:, btw… but we’ll keep old notation some versions to provide backward compatibility)
So I can imagine an API like this:
ffiAsyncCall:callback:module:
So yes… you need change. But that’s inevitable… Of course you can do a fwk forking in image and starting a continuation, etc. But well, I will let you guys to think on that (also you still will need the fork) :)
- to what degree will NB syntax need to be extended to support threaded callouts.
as described, I suppose. No exact idea until we implement.
- what NB syntax changes are needed for callbacks.
NB used some magic there. Shadow classes and etc. We do not need/want that anymore.
now you have a new FFICallback api, where you can do:
FFICallback signature: #(int (int handle, int *pitch, int x, int y, int w, int h)) block: [ :handle :pitch :x :y :w :h | pitch signedLongAt: 1 put: (self get_stride: handle). self get_data: handle ]
(I extracted that example from my ongoing port of Athens)
- timing: when is MTVM expected and can we operate on the leading edge?
we are lacking resources: Is just me (in the Pharo part, of course… Eliot and some others work also in the exclusively VM part, but they have other agendas).
So… my plan is:
- NB to FFI port (should be ready soon)
- spur32 bits (should be ready soon, we are just waiting the NB to FFI)
- spur64 bits (Eliot is working on the JIT, I need to manage the migration of Pharo)
- FFI 64bits (0% done here… just some stubs waiting for effort). But we want to move Pharo to 64bits… we are losing a train here...
- FFI MT
So… not very hight priority. According as how I see things now, I *think* I can have that some point of 2017… yes, as far as that. Also because I have a lot other stuff to do, not just the lowlevel parts.
Of course this is not good and we have talked with some people to speed up this. We talked with Igor about taking the MT stuff (yes, we also believe is VERY important), but he fade in the blur… I didn’t hear from him since 3 months (I’m still waiting for some feedback on OSWindow work he did, he)… yes I’m a bit frustrated.
If *anyone* wants to collaborate in any part of this list (is a MASSIVE effort), I would be very happy and willing to provide as much assistance/guiding/peer programming as I can.
hope this helps
Esteban
Personally, in SqueakElib, I have my network and session layers working for encrypted connections, so I just have the presentation layer to go. Once done, I would be very interested in working in the VM with whomever is also interested with an eye towards threading (MTVM). I am no expert here so it will be a challenge I am looking forward to.
Regards, Robert
On 10/16/2015 06:59 AM, stepharo wrote:
In pharodays presentations we explictly mentioned our strategy: - we keep NB syntax - we change the assembly generation to be able to get Spur.
Stef
I can tell you that if I could get a lua kind of jit now I would sign immediately and also for having pharo as a dll. Now it takes time to do soemthing.
Le 15/10/15 17:35, Robert Withers a écrit :
I am reticent to invest in learning FFI that is changing without an idea of the direction of the change. So