On 24 October 2013 08:24, Norbert Hartl <norb...@hartl.name> wrote: > > > Am 23.10.2013 um 23:28 schrieb Igor Stasenko <siguc...@gmail.com>: > > > > > On 23 October 2013 23:13, Stéphane Ducasse <stephane.duca...@inria.fr>wrote: > >> >>> >> Well implementing ARM-FFI is largely orthogonal to Athens. >> Yes, i am happily using it for Cairo and it lets me customize /rethink >> things as they go >> without need to touch VM. Which means much faster development process and >> feedback etc. >> But since Athens API is settled down more or less, now it is quite >> possible to implement a plugin >> for different backend, knowing that it won't require huge changes later. >> >> >> Ok I was not aware you were thinking about that. So this is good to have >> this path in my radar. >> >> Yes, this is actually what we discussed recently with Esteban about > possible alternatives and > low-hanging fruits :) > > >> Concerning ARM: >> - Damien Pollet works on ARM assembler for ASMJit. >> as soon as it working, we can try doing something with it. >> >> But in addition, what i would like to do is to move more towards >> platform-neutral FFI implementation, >> using low-level assembler DSL which is platform neutral. There's a work >> started on it >> as part of Mate project, but it is yet far from finished. >> >> >> I would love that. >> Now I guess that I'm correct to say that even with it the fact that it >> would generate assembly on the fly >> would make it a no go for iPad and friends. >> >> I thought that esteban and you thought about generating the "assembly >> once for all for Ipda and putting it in file" >> so that we do not have the "assembly generation" problem? >> >> that's a big question, whether such idea fits into apple > technicians/politicans heads or not. > Do you think we have enough time/resources to waste on implementing such > mechanism > only to discover later that Apple says 'over my dead body'? > The point is that generating code, saving it to file, and then loading > that file as DLL, > is largely a hack. > You either allowed to run your own generated code or not.. because from > security perspective, > the fact that you first stored it into file and then load it back doesn't > changes a tiny bit. > > > You store the code in a file in order to rip off the code generation part > from your image. That would make it comply to apples policies. Same goes > for the compiler. You are also not allowed to download a library and use it > in your program. I think the plot is that apps get examined before they are > allowed to be in the appstore. Changing the runtime would break this > certification of the binary and apple would loose control because everybody > would add a clean binary to the examination process and then they would > load everything else when the user opens the app for the first time. So > there is some sense in this. It is just a different way of thinking that we > find annoying. > > The sense is that i'm not changing NativeBoost each time i using it, so i am not "changing the runtime". It is pure fallacy to consider code as something else than just simple data. Sure thing, if i mutate the codebase by loading external code from random source later (and this is what we regularly do with our images) then the contract is broken. But not in case when all my code and i'm not changing it in any way. The fact it using code generation doesn't means it will turn into something else if i don't want to.
> Norbert > > From design perspective, it is crutch, which don't really buys anything > (why on earth, anyone would want to deal with files > and OS, if he could just run code which already in memory?). > > -- Best regards, Igor Stasenko.
