<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 15, 2013, at 6:24 PM, Stephen Checkoway <<a href="mailto:s@pahtak.org">s@pahtak.org</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;"><br>On Jul 13, 2013, at 12:43 PM, Tim Northover <<a href="mailto:t.p.northover@gmail.com">t.p.northover@gmail.com</a>> wrote:<br><br><blockquote type="cite">The problem is that behaviour seems to violate the intended design of<br>AT&T mnemonics.<br></blockquote><br>Is there an actual specification for AT&T syntax? The one Jim Grosbach posted to the list explicitly says that instructions without the size suffix default to l. I don't see any reason to take that as the definitive definition of AT&T syntax but then I don't see anything that would indicate that gas's behavior is incorrect.<br></div></blockquote><div dir="auto"><br></div>Yeah, that’s the best reference I found, but there may be better. If there is, I’d love to see it (and have a link to it on the <a href="http://llvm.org">llvm.org</a> pages somewhere).</div><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;"><br><blockquote type="cite">If we make btr default to btrl, shouldn't we do the same for every<br>other pair?<br></blockquote><br><br>Based on the Solaris doc, yes.<br><br>On Jul 15, 2013, at 7:18 PM, Jim Grosbach <<a href="mailto:grosbach@apple.com">grosbach@apple.com</a>> wrote:<br><br><blockquote type="cite">If adding aliases for these mnemonics is the right thing to do, then an argument can and should be made for that independent of gas’ current behavior.<br></blockquote><br>I think the best argument is the one Linus made (modulo being rude). If the assembler is a tool for humans, then all else being equal, it should operate on a principle of least surprise.<br></div></blockquote><div><br></div><div>Yes. I suspect there may be disagreement on what constitutes surprise, but that’s a more philosophical debate and tangential to the current discussion. </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;"><br>bt $n, mem becomes<br>1. btl $n, mem for n in [0, 31] and<br></div></blockquote><div><br></div><div>This seems totally reasonable.</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;">2a. btq $n, mem for n in [32, 63] or<br></div></blockquote><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;">2b. btl $(n-32), mem+4 for n in [32, 63]<br></div></blockquote><div><br></div><div>Personally, 2a is least surprising. 2b will result in an instruction in a disassembly that has both a different immediate and a different memory reference than the instruction I wrote, which would very much surprise me.</div><div><br></div><div>That said, I would tend to prefer this case simply generate a diagnostic saying the immediate is out of range for btl, perhaps with a fixit style notice to use btq or a btl w/ mem+4, but I can see the usability argument the other way. IIUC, a diagnostic is what that Solaris doc would get here since it uses an ‘l’ suffix by default.</div><div><br></div><div>Do you have a preference? From Linus’ description, the Linux kernel will always be in the (1) case due to their choice of constraint, so this is outside the scope of kernel expectations.</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;">Or even take the more general route discussed in the Intel manual<br>bt $n, mem becomes btl $(n % 32), mem + 4*(n / 32)<br></div></blockquote><div><br></div><div>This scares the crap out of me. :)</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;">bt, btr, and bts should probably operate in the same manner.<br></div></blockquote><div><br></div><div>Agreed. Probably btc also? Any others?</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;">It seems unlikely people would ever write an immediate value outside the allowed range and want/expect the compiler to blindly copy the one byte immediate even though the hardware only looks at the least significant 4 (resp. 5 or 6) bits for btw (resp. btl or btq).<br></div></blockquote></div><br><div>Also agreed. An out-of-range immediate is almost certainly either a) user error or b) user expecting the assembler to be clever. For a well-selected definition of a “reasonable range,” it’s probably safe to assume (b) and indeed be clever. Either [0,31] or [0,63] seem to fit the bill for that range.</div><div><br></div><div>-Jim</div></body></html>