On Tue, Jul 5, 2011 at 11:35 AM, Talin <span dir="ltr"><<a href="mailto:viridia@gmail.com">viridia@gmail.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 class="im">On Sun, Jul 3, 2011 at 9:07 AM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br></div><div class="gmail_quote"><div class="im">

<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><div><br></div><div>On Jul 1, 2011, at 11:05 AM, Talin wrote:</div></div><div><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><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><div>A few additional thoughts: The language implementer's library that you propose would include a whole bunch of stuff that I didn't mention in the original post because it's stuff that I already have, but which might be useful to other language implementers. Some examples:</div>


<div><ul><li>DWARF exception table decoding functions, useful for writing personality functions.</li><li>Other functions for accessing DWARF data at runtime - useful for generating stack dumps.</li><li>Aligned memory allocators. It's useful for some garbage collection algorithms to be able to allocate heap blocks that are aligned on a large power-of-two boundary (like 64K boundary) so that you can quickly determine which memory pool an address belongs to by looking at the upper bits of the address. (Mainly this would just be a standardized interface around the platform's C library functions that do this, such as posix_memalign.)</li>


<li>An efficient map class for mapping function return addresses to a pointer. This map would be initialized on program start from a table of tuples and would be immutable after that. One use of this is finding the stack map for a given function return address.</li>


<li>Integer/float parsing and printing functions for building your language's equivalent of 'printf'.</li><li>Helper functions for finding and running static constructors.</li><li>Getting and setting thread-local data in a way that uses the __thread attribute if available, and pthreads if not. (I notice that pthread_getspecific is extremely efficient on OS X.)</li>


<li>Low-level debugging support. </li></ul></div><div>One requirement is that all of these functions should be written in such as way as to not require the C++ runtime libraries, only C libs.</div><div class="im"><div><br>

</div></div></div></blockquote><div>Oh, and also:</div><div><br></div><div>1) I'd be happy to donate whatever code I have to this effort;</div><div><br></div><div>2) However, I don't think we should do this unless we can identify at least one other customer other than myself - mainly because I don't want the design decisions to be too tailored to my specific use cases.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im"><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>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></div><br><br clear="all"><br>-- <br><font color="#888888">-- Talin<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>-- Talin<br>