I'm just trying to get an overview of a greater picture, I'm currently not working on any compiler porting or CPU development, but could someone please tell, if there exists in LLVM or some other compiler a feature, where different CPU-vendors offer some standardized XML/JSON/YAML file that describes the CPU's parameters, registers, commands in some formal manner and compilers that support that CPU description format, can just import that CPU-description a bit like bookmarks are imported to web browsers and importing/loading of the formal CPU-description would be all that is needed to port the compiler to that CPU? The file would describe register names, register widths, what command works with what register, etc. Practically the CPU-description file would be written in some domain specific language even if the syntax is XML/JSON/YAML. Again, the idea is that if web browsers are able to configure the GUI according to HTML, then compilers might configure their back-ends according to the CPU-description file. The CPU description file might even be part of the internal test suite of the CPU-vendor during the development of the CPU. Why the duplication of effort at describing the programming interface specification of the CPU, first at the CPU-vendor side and later at the compiler side? After all, it is CERTAIN that at least SOME COMPILER is needed to make any CPU useful at all, with the exception of some really tiny micro-controllers that might be usable with ASM alone, but even among micro-controllers those are a rarity. I hope to be the most stupid person on this list, despite hoping that my current letter is smart enough to deserve an answer. :-/ Thank You for reading my letter. With curiosity, Martin.Vahi at softf1.com
> On 15 Jul 2016, at 16:33, Martin Vahi via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > I'm just trying to get an > overview of a greater picture, I'm > currently not working on any compiler > porting or CPU development, but could > someone please tell, if there exists in LLVM or > some other compiler a feature, where > different CPU-vendors offer some standardized > XML/JSON/YAML file that describes the CPU's > parameters, registers, commands in some formal > manner and compilers that support that CPU > description format, can just import that CPU-description > a bit like bookmarks are imported to web browsers > and importing/loading of the formal CPU-description > would be all that is needed to port the compiler > to that CPU? > > The file would describe register names, register > widths, what command works with what register, etc. > Practically the CPU-description file would be > written in some domain specific language even if the > syntax is XML/JSON/YAML. Again, the idea is that > if web browsers are able to configure the GUI > according to HTML, then compilers might configure > their back-ends according to the CPU-description file.I'm not aware of any such existing document/resource, but I think it would really be a nice resource to have just as a catalogue of what's out there. I suspect someone just hasn't done this, or if someone has then that it isn't that popular nor accessible. What I do know is that in LLVM you can look at the existing targets described in tablegen files scattered around. It's not exactly XML but I think you can probably come up with a generator that takes the tablegen inputs and generates an XSD (or equivalent) and an XML document according to that generated schema. The tutorials on tablegen should be helpful in that regard.> > The CPU description file might even be part of the > internal test suite of the CPU-vendor during the > development of the CPU. Why the duplication of effort > at describing the programming interface specification > of the CPU, first at the CPU-vendor side and later > at the compiler side? > After all, it is CERTAIN that at least SOME COMPILER > is needed to make any CPU useful at all, with the > exception of some really tiny micro-controllers that > might be usable with ASM alone, but even among > micro-controllers those are a rarity. >At least for what's in LLVM already, you should be able to do this if you're so inclined. :)> I hope to be the most stupid person on this list, > despite hoping that my current letter is smart enough > to deserve an answer. :-/ >I tried, hopefully that helps (also, note, I'm also a newbie here). :) Cheers
Hi Martin, If I'm reading your question correctly, there are really two aspects to what you're suggesting: 1. A compiler emits a CPU description in some standardized form 2. A compiler that takes such CPU descriptions as input to generate a back end As Dean suggested, I believe you can get reasonably good results for number 1. by writing a TblGen-like tool to interpret Target Description files. Number 2. on the other hand is probably not doable in general. I don't really think it is feasible to have a generic tool that will simply take a CPU description as input and emit a functioning back end to hook to a target-independent compiler. On Fri, Jul 15, 2016 at 4:46 PM, Dean Michael Berris via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > > On 15 Jul 2016, at 16:33, Martin Vahi via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > > > I'm just trying to get an > > overview of a greater picture, I'm > > currently not working on any compiler > > porting or CPU development, but could > > someone please tell, if there exists in LLVM or > > some other compiler a feature, where > > different CPU-vendors offer some standardized > > XML/JSON/YAML file that describes the CPU's > > parameters, registers, commands in some formal > > manner and compilers that support that CPU > > description format, can just import that CPU-description > > a bit like bookmarks are imported to web browsers > > and importing/loading of the formal CPU-description > > would be all that is needed to port the compiler > > to that CPU? > > > > The file would describe register names, register > > widths, what command works with what register, etc. > > Practically the CPU-description file would be > > written in some domain specific language even if the > > syntax is XML/JSON/YAML. Again, the idea is that > > if web browsers are able to configure the GUI > > according to HTML, then compilers might configure > > their back-ends according to the CPU-description file. > > I'm not aware of any such existing document/resource, but I think it would > really be a nice resource to have just as a catalogue of what's out there. > I suspect someone just hasn't done this, or if someone has then that it > isn't that popular nor accessible. > > What I do know is that in LLVM you can look at the existing targets > described in tablegen files scattered around. It's not exactly XML but I > think you can probably come up with a generator that takes the tablegen > inputs and generates an XSD (or equivalent) and an XML document according > to that generated schema. The tutorials on tablegen should be helpful in > that regard. > > > > > The CPU description file might even be part of the > > internal test suite of the CPU-vendor during the > > development of the CPU. Why the duplication of effort > > at describing the programming interface specification > > of the CPU, first at the CPU-vendor side and later > > at the compiler side? > > After all, it is CERTAIN that at least SOME COMPILER > > is needed to make any CPU useful at all, with the > > exception of some really tiny micro-controllers that > > might be usable with ASM alone, but even among > > micro-controllers those are a rarity. > > > > At least for what's in LLVM already, you should be able to do this if > you're so inclined. :) > > > I hope to be the most stupid person on this list, > > despite hoping that my current letter is smart enough > > to deserve an answer. :-/ > > > > I tried, hopefully that helps (also, note, I'm also a newbie here). :) > > Cheers > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160715/57a539fa/attachment.html>