On May 5, 2010, at 5:22 PM, Nathan Jeffords wrote:> > The logic to handle this has to go somewhere, putting it in the MCStreamer *implementation* that needs it is the most logical place. We also aim to implement an assembler, it doesn't make sense to duplicate this logic in the compiler and the assembler parser. > > > Assembly language has often been *the* intermediate form for between compilers and object files/executables, but I don't think its the most effective form. That said I have limited experience writing code generators so my opinions do not bear the wisdom of you and other developers of this library on this topic.I completely agree, but it is a very important and effective form of communication :) One nice fallout of the MCStreamer design is that once the COFF writer is available, we'll have a stand-alone coff assembler mostly "for free". In fact, developing this as a coff assembler (which can be accessed with 'llvm-mc foo.s -o foo.obj -filetype=obj') is easier in a lot of ways than dealing with the compiler!> > Yes somewhat. Currently, the COFF implementation of the assembler backend should maintain a DenseMap from MCSymbol* to whatever data you need to associate with a symbol. This is equivalent to embedding per-symbol stuff in the MCSymbol itself. MCSection should be subclassed and you should put COFF specific stuff in MCSectionCOFF. > >> > > I think this is an important detail I was missing. I can already see how this will help with COMDAT sections. Is there any reason for the difference between symbol and section in this respect?You'd have to ask Daniel about this. I don't recall if this is a short term thing that he'd like to fix or if this is an important design decision.> > As others have pointed out, this is one of the many horrors of C :) > > > Another reason why I am attempting to develop my own language. :) > > p.s. I posted my coff backend patch to llvm-commit, but that apears to be the wrong place, where should I have posted it?llvm-commits is a great place for it! -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100505/b3168959/attachment.html>
On Wed, May 5, 2010 at 5:53 PM, Chris Lattner <clattner at apple.com> wrote:> > On May 5, 2010, at 5:22 PM, Nathan Jeffords wrote: >> >> The logic to handle this has to go somewhere, putting it in the MCStreamer >> *implementation* that needs it is the most logical place. We also aim to >> implement an assembler, it doesn't make sense to duplicate this logic in the >> compiler and the assembler parser. > > Assembly language has often been *the* intermediate form for between > compilers and object files/executables, but I don't think its the most > effective form. That said I have limited experience writing code > generators so my opinions do not bear the wisdom of you and other developers > of this library on this topic. > > I completely agree, but it is a very important and effective form of > communication :) > One nice fallout of the MCStreamer design is that once the COFF writer is > available, we'll have a stand-alone coff assembler mostly "for free". In > fact, developing this as a coff assembler (which can be accessed with > 'llvm-mc foo.s -o foo.obj -filetype=obj') is easier in a lot of ways than > dealing with the compiler! >> >> Yes somewhat. Currently, the COFF implementation of the assembler backend >> should maintain a DenseMap from MCSymbol* to whatever data you need to >> associate with a symbol. This is equivalent to embedding per-symbol stuff >> in the MCSymbol itself. MCSection should be subclassed and you should put >> COFF specific stuff in MCSectionCOFF. > > I think this is an important detail I was missing. I can already see how > this will help with COMDAT sections. Is there any reason for the difference > between symbol and section in this respect? > > You'd have to ask Daniel about this. I don't recall if this is a short term > thing that he'd like to fix or if this is an important design decision.The reason for MCSectionCOFF etc., is that they are shared between the MC and CodeGen interfaces. They have semantics that apply to both .s files and object files, and even the frontend has some interest in them. OTOH, things like MCSymbolData, MCSectionData, are private to the assembler backend, and so only the assembler and object writer need to know about them (they are unused when writing to a .s file, for example). MCAssembler already maintains its own association of these data structures, and there are a few bits available for the object file backends inside MCSymbolData. I would be fine adding a few more for use by specific object writers, if it simplifies your implementation. I'm sorry I have had time to be very present on this thread, but please feel free to mail me / ping me if there is a something about the assembler backend you have questions on. I'm very excited to see COFF support coming up! - Daniel>> As others have pointed out, this is one of the many horrors of C :) > > Another reason why I am attempting to develop my own language. :) > p.s. I posted my coff backend patch to llvm-commit, but that apears to be > the wrong place, where should I have posted it? > > llvm-commits is a great place for it! > -Chris > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >
> > > The reason for MCSectionCOFF etc., is that they are shared between the > MC and CodeGen interfaces. They have semantics that apply to both .s > files and object files, and even the frontend has some interest in > them. > > OTOH, things like MCSymbolData, MCSectionData, are private to the > assembler backend, and so only the assembler and object writer need to > know about them (they are unused when writing to a .s file, for > example). > > MCAssembler already maintains its own association of these data > structures, and there are a few bits available for the object file > backends inside MCSymbolData. I would be fine adding a few more for > use by specific object writers, if it simplifies your implementation. > >would it make sense to allow the object file streamer/writer code to provide custom derivations of MCSymbolData/MCSectionData so that its is free to define and interpret that data without other object file formats being aware of it? something like struct MCAssemblyDataFactory { virtual MCSymbolData * createSectionData (MCSection* Symbol) = 0; virtual MCSymbolData * createSymbolData (MCSymbol* Symbol) = 0; }; which would then me given to the assembler when created. I had started down a different road, that if acceptable, might provide a more general solution. I have added some API's to MCContext to allow me to associate arbitrary data with section's & symbol's. template <value_type> void setSectionData (MCSection const * Section, value_type const & Value); template <value_type> bool getSectionData (MCSection const * Section, value_type & Value) const; template <value_type> void setSymbolData (MCSymbol const * Symbol, value_type const & Value); template <value_type> bool getSymbolData (MCSymbol const * Symbol, value_type & Value) const; I can implement these with in a completely type safe manner without using virtual functions or virtual function tables and no dynamic runtime type information. With some extra work, they can use a single allocation per data item, currently their is two. I do rely on the typeid to return a typeinfo object for value_type, but I do this at compile time, not runtime. I'm sorry I have had time to be very present on this thread, but> please feel free to mail me / ping me if there is a something about > the assembler backend you have questions on. I'm very excited to see > COFF support coming up! >Hopefully, I will have something people can look at pretty soon here. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100507/b16cc2fd/attachment.html>