On Tue, Oct 4, 2011 at 5:07 PM, 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 class="im"><br><div><div>On Oct 4, 2011, at 4:41 PM, Talin wrote:</div><br><blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div>
One thing you would need is the ability to assign names to struct members. Currently LLVM refers to struct members by numerical index, and I wouldn't want to change that. However, in order to be visible in the debugger, you also have to assign a name to each member. Note that this information doesn't need to take a lot of space in the module - names are highly compressible, especially fully qualified names (foo.bar.X.Y.Z) where you have a whole bunch of names that start with the same prefix. (In my own frontend, I sort names by frequency, so that the names that are used most often have the lowest assigned IDs. This allows the reference to the name to be stored in fewer bits.)</div>
</span></blockquote><br></div></div><div>Talin, if you're trying to produce a "C virtual machine" you basically need everything in a C AST. You're scratching the surface of the issues.</div><div><br></div>
</div></blockquote><div>I was trying to limit my response to just a few examples - I realize that there's a ton of things I've left out. I guess what I am describing is the same as Microsoft's "Managed C++" - the ability to compile C++ programs to the CLR. Note that Managed C++ doesn't give you every possible feature of C++, you can't take an arbitrary C++ program and expect to compile it in managed mode.</div>
</div></div></span></blockquote></div><br></div><div>Are you willing to give up the ability to interoperate with existing ABIs and code compiled by other compilers?</div><div><br></div></div></blockquote><div></div></div>
<div>For my own needs, I'd be willing to live with a system that requires extra effort on behalf of the programmer (in the form of __attributes or #pragmas or SWIG) when calling out to code produced by other compilers. In other words, I'd like for the kind of interoperability you describe to be *possible*, but I don't necessarily require or expect that it be *easy*.</div>
<br>-- Talin<br>