On Thu, 22 Mar 2007, Jeff Cohen wrote:> I'm confused. A MSIL front end I can understand, but a back end? How > will it be used? The GCC-based front ends that come with LLVM generate > bytecodes that have dependencies on the GCC runtime, which is not going > to be present in a .NET environment.Who said the input has to come through the GCC front-ends? Perhaps this is for Jolt -> .NET? :) -Chris -- http://nondot.org/sabre/ http://llvm.org/
Chris Lattner wrote:> On Thu, 22 Mar 2007, Jeff Cohen wrote: >> I'm confused. A MSIL front end I can understand, but a back end? How >> will it be used? The GCC-based front ends that come with LLVM generate >> bytecodes that have dependencies on the GCC runtime, which is not going >> to be present in a .NET environment. > > Who said the input has to come through the GCC front-ends? Perhaps > this is for Jolt -> .NET? :) > > -ChrisThen the problem is the converse: the .NET runtime won't be available if one of the other back ends is used. It will be very hard for a front end to support both MSIL and the other back ends. Yes, it is possible to write C++ that can be compiled to MSIL and use the .NET runtime, but only by using Microsoft's Managed C++ extensions (which basically provide C# semantics via ugly C++ syntax). It's safe to say llvm-gcc doesn't support these extensions :)
Chris Lattner wrote:> On Thu, 22 Mar 2007, Jeff Cohen wrote: >> I'm confused. A MSIL front end I can understand, but a back end? How >> will it be used? The GCC-based front ends that come with LLVM generate >> bytecodes that have dependencies on the GCC runtime, which is not going >> to be present in a .NET environment. > > Who said the input has to come through the GCC front-ends? Perhaps > this is for Jolt -> .NET? :) > > -ChrisThe problem is worse than I thought. MSIL, and .NET in general, defines a specific object model. This object model is explicitly part of MSIL semantics. LLVM is at a lower level; it does not have an object model. To do a virtual call, LLVM instructions must be generated to load a function pointer from a vtable and dereference it. But MSIL is at a higher level, where one simply uses the callvirt instruction to do a virtual call and no vtable is supplied or even present. There's no obvious way to reconstruct the higher level object semantics from LLVM IR, and sure enough the new MSIL back end never generates a callvirt instruction. In other words, it is incapable of using the .NET framework library or anything else relying on virtual method calls. What am I missing?
On Thu, 22 Mar 2007, Jeff Cohen wrote:> The problem is worse than I thought. > > MSIL, and .NET in general, defines a specific object model. This object > model is explicitly part of MSIL semantics. LLVM is at a lower level; > it does not have an object model. To do a virtual call, LLVM > instructions must be generated to load a function pointer from a vtableUnlike Java, MSIL support 'unsafe' operations, which include fully general pointer arithmetic, casting, etc. In this mode, you don't need to use its support for object models at all, -Chris -- http://nondot.org/sabre/ http://llvm.org/