<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jul 10, 2013, at 2:30 PM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Wed, Jul 10, 2013 at 2:08 PM, Ramkumar Ramachandra<br><<a href="mailto:artagnon@gmail.com">artagnon@gmail.com</a>> wrote:<br><blockquote type="cite">Jim Grosbach wrote:<br><blockquote type="cite">To say that another way, is the assembler correctly diagnosing a previously<br>unnoticed problem in the project source code, or is the assembler not<br>behaving correctly according the the documented Intel assembly mnemonics?<br></blockquote><br>Where are the authoritative instruction set pages? If such a thing<br>were readily available, why are there gaps in the current<br>implementation? A quick Googling gets me [1], but I can't say it's<br>authoritative. What's important is that there certainly are<br>architectures where btr/bts are valid instructions, and they must be<br>supported. btr/bts are certainly not invalid instructions that we're<br>bending over backwards to support, because linux.git/gas works with<br>them.<br><br>[1]: <a href="http://web.itu.edu.tr/kesgin/mul06/intel/index.html">http://web.itu.edu.tr/kesgin/mul06/intel/index.html</a><br>_<br></blockquote><br>The correct answer here is "Vol 2a of the Intel Reference Manual<br>available off of the Intel website”.<br></div></blockquote><div><br></div><div>Yep, for Intel syntax that’s exactly right.</div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">As far as whether or not we should support the instructions with a<br>lack of length mnemonic, I'm going to step back away from the<br>discussion. The Intel manuals support Intel syntax (which we also<br>support) which necessarily doesn't have length encodings for most<br>instructions, but AT&T syntax which gas uses (and llvm supports as<br>well) often has length specifiers for instructions.<br></div></blockquote></div><br><div><br></div><div>The length specifier is, as I understand it, required when the instruction references memory but is optional (and inferred from the registers) for the register variants.</div><div><br></div><div>The best reference I know of for the AT&T syntax is: <a href="http://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf">http://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf</a></div><div><br></div><div>That does raise a clarifying question here. Is the code you’re interested in using Intel or AT&T syntax?</div><div><br></div><div>Also note that the question isn’t whether we should support the btr/bts instructions. We absolutely must (and do). The question is whether we are properly handling the un-suffixed mnemonic form of the assembly syntax.</div><div><br></div><div>Perhaps you can help by clarifying via explicit example what code you believe should work but does that. Descriptions are great, but specifics are better once we’re this deep into the details.</div><div><br></div><div>-Jim</div><div><br></div></body></html>