[llvm-dev] Tablegen backend for emulator core?

[Min-Yih Hsu via llvm-dev]

This is a cool idea and AFAIK there isn’t any project that has done similar thing.

However IMO a potential problem is: In this story, LLVM only eases the efforts of writing a disassembler from scratch (and parsing object file formats for you). But we already can use the implementation of MCDisassembler provided by each target as a normal library to perform disassembly. Same for parsing object file formats.
In other words, it’s already easy to use LLVM’s disassembler in an emulator project.

It is, however, an attractive option to _directly_ generate part of the emulator code. We can even provide handler code for each instruction in the TG description as you have suggested. It would be a cool out-of-tree project for sure, but I see little chance to go upstream because it’s pretty far away from LLVM’s original goal.

Best,
-Min

> On Mar 17, 2021, at 2:58 PM, John Byrd via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Howdy llvm-dev,
> 
> Low priority question.  This doesn't really meet the requirements for an RFC, because it's probably merely a half-baked idea at this point.
> 
> As I was working with some tablegen internals on an 8-bit processor backend, it struck me that I would need at some point to write an emulator for that processor.
> 
> And I realized that, although I could write an emulator in the traditional manner, tablegen already has most of the information it needs to automatically generate the guts of an emulator.
> 
> Tablegen's already generating a disassembler (-gen-disassembler). 
> 
> At the least, tablegen could be given an additional backend that says, "given this instruction, do this emulation step."  Such a step could be pure code copied from the .td files, or it could be compositionally constructed based on the classes that an object is composed from.
> 
> You'd have to write your own code to deal with emulated machine state, but hey, instruction parsing would be an item off the to-do list.
> 
> I would have a hard time believing that this concept is novel.  Has anyone else taken a crack at this?
> 
> Sincerely,
> 
> -- 
> ---
> 
> John Byrd
> Gigantic Software
> 2321 E 4th Street
> Suite C #429
> Santa Ana, CA  92705-3862
> http://www.giganticsoftware.com <http://www.giganticsoftware.com/>
> T: (949) 892-3526 F: (206) 309-0850
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20210317/665ba6c4/attachment.html>