[LLVMdev] Adding a Yasm ASM printer

[Jim Grosbach]

Hi Matthew,

Whether this is the right approach depends on the details of the problem. If it's mainly directives that are the issue, then a new variant is huge overkill. If, on the other hand, most/many of the instructions themselves need different syntax, then it's exactly the right approach. From your description, in particular, "Yasm's format is very close to that of intel," I suspect you may be able to get away with some custom handling in the current streamers and maybe a few tweaks to problematic instructions. For example, the current streamers conditionally use CFI directives based on whether the target environment supports them. You may be able to do something similar.

A new streamer (or customized behavior on the current one) and a new variant are somewhat orthogonal. I suggest solving the issues for each independently to avoid having too many moving parts at once.

-Jim



On Apr 2, 2012, at 1:46 PM, Matthew Huck <matthew.huck at gmail.com> wrote:

> Hi,
>   I'm in the process of adding a X86 ASM Printer for outputting the asm in a style that Yasm can take without any post processing. Yasm's format is very close to that of intel.  I was wondering if my approach is correct:
> 
> I've made a custom MCAsmStreamer to remove some of the COFF symbol directives that yasm doesn't understand.
> 
> I've made a X86YasmInstPrinter, and added it to the x86.td, as a new variant, and due to it having a new Variant number, I'm having to edit all the X86*.td files and add the extra variant's descriptions in the { | } blocks.
> 
> I've also added a new ASMInfo class with the required changes for yasm.
> 
> 
> Now what is worrying me is the number of .td files I'm having to touch, and most of the changes are adding a variant with exactly the same code as the intel variant, there are just a few cases that a slightly different.
> 
> I'm about 1/4 way through the .td files, and already the asm is starting to look close to something yasm could handle, so I must be at least on the right track, but that size of the changes to the .td files is alarming.
> 
> Any pointers, or suggestions welcome :-)
> 
> Cheers
> 
> Matthew.
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120403/65dbb211/attachment.html>