Thanks, I'll take a look. If any are interested, please feel free to contact me off list.<div><br></div><div>-jjk<br><br><div class="gmail_quote">On Sat, Aug 18, 2012 at 10:32 PM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think a good starting point for you would be the work that has gone<br>
into Native Client.<br>
<br>
On Sat, Aug 18, 2012 at 11:22 PM, Julian Klappenbach<br>
<div class="HOEnZb"><div class="h5"><<a href="mailto:jklappenbach@gmail.com">jklappenbach@gmail.com</a>> wrote:<br>
> Not necessarily looking for performance gains from LLVM. Instead, the value<br>
> comes from having a common base platform which can gain language<br>
> independence, address security concerns, support common tooling (debugging,<br>
> editing, etc), and perhaps even introduce common language features<br>
> (annotations / AOP).<br>
><br>
> I'm envisioning a use case where browsers would utilize this runtime to<br>
> execute not only javascript, but also python, ruby, etc. Language specific<br>
> interpreters could be downloaded on the fly to support scripts, and security<br>
> would be ensured due to the fact that it would be based within the LLVM<br>
> layer. The LLVM layer would also provide the access point for common<br>
> browser APIs like access to the DOM and HTML nodes, XSLT, and XHR<br>
> invocations. This would open up both the browser and current HTML5<br>
> application platforms to a wide variety of languages. Some may be quite<br>
> happy with Javascript, but I'm sure others would be excited to see that<br>
> stranglehold broken.<br>
><br>
> And for this purpose, I think LLVM would be well suited. It really depends<br>
> on how much existing work can be leveraged, and how much interest exists<br>
> within the community to see this happen.<br>
><br>
> -jjk<br>
><br>
> On Sat, Aug 18, 2012 at 9:56 PM, Sean Silva <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> wrote:<br>
>><br>
>> Most of the performance wins for dynamic languages are not from the<br>
>> kinds of optimizations that LLVM does; you basically gain performance<br>
>> by doing run-time specialization of dynamic language constructs to<br>
>> become static, which is something that LLVM really won't help you do,<br>
>> and which practically speaking is extremely language-specific.<br>
>><br>
>> For example, in JavaScript, all numbers are officially doubles, but in<br>
>> many cases it is profitable to runtime-specialize them to be integers,<br>
>> on the other hand, Python distinguishes between floats and integers,<br>
>> but Python integers overflow into arbitrary-precision integers<br>
>> on-demand.<br>
>><br>
>> For another example, in Python, dictionaries can have any hashable<br>
>> type as their key, but in JavaScript, "objects" (which double as<br>
>> hashtables) can only have strings as their keys (although numbers get<br>
>> implicitly converted to strings which is another big language-specific<br>
>> optimization opportunity). Oh, and in JavaScript "objects" have a<br>
>> number of additional semantics which prevent them from being actually<br>
>> used as pure hashtables!<br>
>><br>
>> --Sean Silva<br>
>><br>
>> On Sat, Aug 18, 2012 at 4:39 PM, Julian Klappenbach<br>
>> <<a href="mailto:jklappenbach@gmail.com">jklappenbach@gmail.com</a>> wrote:<br>
>> > I have a concept for which I'm conducting an initial analysis. The<br>
>> > broader<br>
>> > idea is to create an LLVM, JIT based runtime that would create a<br>
>> > platform<br>
>> > amenable to scripting languages, but do so while enforcing an optional<br>
>> > sandbox environment when dictated by security concerns (browsers, user<br>
>> > preferences). With this approach, the community would gain language<br>
>> > independence for browsers, as well as enabling much needed<br>
>> > standardization<br>
>> > over tooling support for debugging, refactoring, and even general<br>
>> > editing<br>
>> > concerns.<br>
>> ><br>
>> > The first language I'd like to tackle is ECMAScript / Javascript.<br>
>> ><br>
>> > So, aside from all the issues with the strategy (getting buy-in from<br>
>> > browser<br>
>> > / tooling teams, development community), my first concern is that it is<br>
>> > even<br>
>> > possible. Theoretically, it should be possible to express Javascript in<br>
>> > LLVM. But a quick review of existing projects indicates that, while<br>
>> > LLVM -><br>
>> > Javascript has been taken on, what I'm seeking has not been done to<br>
>> > date.<br>
>> ><br>
>> > Have I missed anything, or is there any reason not to attempt a project<br>
>> > like<br>
>> > this?<br>
>> ><br>
>> > Regards,<br>
>> ><br>
>> > Julian Klappenbach<br>
>> ><br>
>> > _______________________________________________<br>
>> > LLVM Developers mailing list<br>
>> > <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div>