Am 24.10.2013 um 12:51 schrieb Igor Stasenko <[email protected]>:

> 
> 
> 
> On 24 October 2013 08:24, Norbert Hartl <[email protected]> wrote:
> 
> 
> Am 23.10.2013 um 23:28 schrieb Igor Stasenko <[email protected]>:
> 
>> 
>> 
>> 
>> On 23 October 2013 23:13, Stéphane Ducasse <[email protected]> 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.
> 
It is all about if you have the possibility to change the runtime at runtime or 
not. If you put native code into a file and remove everything that might change 
it you have the runtime apple wants. For me this is not philosophical debate so 
I don’t go into details. I don’t even like coming close to defend the way apple 
does it. Coming from the system side I just have two hearts beating in my 
chest. The old one (the security/dark side) tells me you have to restrict 
everything to be safe. The other/new one tells me: Screw the dark side. We’ll 
get nowhere with this attitude, let us invent stuff instead of fear stuff. 

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

Reply via email to