[LLVMdev] Greetings & Javascript -> LLVM...

[Julian Klappenbach]

Thanks, I'll take a look.  If any are interested, please feel free to
contact me off list.

-jjk

On Sat, Aug 18, 2012 at 10:32 PM, Sean Silva <silvas at purdue.edu> wrote:

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