On Sun, Jul 3, 2011 at 9:07 AM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div style="word-wrap:break-word"><div><div>Hi Talin,</div><div><br></div><div>Interesting post,</div><div class="im"><div><br></div><div>On Jul 1, 2011, at 11:05 AM, Talin wrote:</div></div><div class="im"><blockquote type="cite">

<div><div><b>Garbage collection is still way too difficult</b>. The biggest problem is the inability to track SSA values - it requires the </div></div></blockquote><br></div><div class="im"><blockquote type="cite"><div><div>

<b>Light-weight coroutines</b> would be a "nice to have", as would better <b>concurrency primitives</b>. These are things I could </div></div></blockquote><br></div></div><div>Tackling the "still way too difficult" and "should be more batteries included" aspects of your post, I think that there is a lot of room for an LLVM subproject that provides a "language implementors toolbox" in the form of some really well documented and standardized runtime libraries that provide GC, synchronization, etc capabilities.  Having them available and reusable (and sub-settable!) would allow code sharing across a wide range of different llvm language implementation.</div>

<div><br></div></div></blockquote><div>Well, sort of. Things like GC tracing of SSA values can't really be done as a library, i'm assuming it requires changes to the code generator.</div><div><br></div><div>Things like iterating stack frames can be done as an add-on library, but I think they would work better as intrinsics - which again requires changes to the code generators.</div>

<div><br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8">Things like stack switching could go either way I guess.</div><div><br></div><div>Most of the things that *could* go in an add-on library I could write myself. The primary exception is cases where the library code has to be different for each target platform - in such cases what you'd really like is for each different platform-specific implementation to have a maintainer who is an expert on that platform.</div>

<div><br></div><div>This is not to say that such a library as you propose would not be useful and convenient.</div><div><br></div><div>Of course, I'm assuming that the typical language implementor has skills and needs similar to my own, which might not be true. In general, I try to be an expert on the first half of the dragon book, and leave the second half to experts who know far more than I do.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div></div><div>These are the capabilities that the JVM provides languages implemented on top of it, and are clearly useful.  Of course the power of LLVM is that it doesn't force you to use a *particular* set of synch primitives, a particular memory management scheme, etc.  However, that doesn't mean that we can't provide a toolbox of parts to choose from, just like we provide a standard optimization sequence which clients can choose to use or not.</div>

<div><br></div><font color="#888888"><div>-Chris</div></font></div></blockquote></div><br><br clear="all"><br>-- <br>-- Talin<br>