<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt"><div dir="ltr"><div class="gmail_default" style>On Tue, Dec 18, 2012 at 3:36 PM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank" class="cremed">t.p.northover@gmail.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> > Maybe it's naive, but I would expect it to be easy for each backend to<br>

> > expose a constant N which is the length of the longest mnemonic, and then<br>
> > for the printer to pad to N+1 or N+2….<br>
><br>
> That would probably work for X86, but other targets (ARM in particular)<br>
> often have operands which are printed/parsed as suffices on the mnemonic<br>
> itself.  Because of these, the backend does not statically know the longest<br>
> potential string-of-stuff-before-the-tab.<br>
<br>
</div>Are you thinking of something beyond the ".F32.I16" suffixes (for<br>
example)? If not, the result may not be TableGeneratable, but is<br>
probably conservatively known as "8 + natural mnemonic length" for<br>
these purposes.<br></blockquote><div><br></div><div style>The great thing is, if its close enough, it doesn't matter if there exist corner cases that are formatted less well.</div></div></div></div></div>