<div dir="ltr">believe it or not that code runs on coreboot simulator, hardware, and qemu, and gets a different answer on each.<div><br></div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 29, 2018 at 12:54 PM Nico Huber <<a href="mailto:nico.h@gmx.de" target="_blank">nico.h@gmx.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 29.03.2018 20:25, ron minnich wrote:<br>
> I have the following code:<br>
><br>
> movl $0x12345678, %eax<br>
> movl $0xaaaabbbb, %ebx<br>
> movb $0x10, %cl<br>
> shrdw %ebx, %eax<br>
<br>
If I had to assemble it, I would have refuse it... *w with 32-bit<br>
registers? how should that work?<br>
<br>
Though, after reading a little about AT&T, I found this:<br>
<br>
  "In AT&T syntax, the size of memory operands is determined from<br>
   the last character of the opcode name." [1]<br>
<br>
Memory operands, heh, no memory operands here... but the GNU as<br>
manual talks about operands in general and that it may infer the<br>
suffix from register operands, hmmm, no word about what happens<br>
if register operands don't match the suffix.<br>
<br>
I've also tried to find a quote about the third operand. Is it<br>
%cl implicitly? I would think so, but is it written anywhere?<br>
Could also be implicitly $0, ok that would never make sense.<br>
<br>
> quiz: what's the value of %ax after this instruction?<br>
<br>
I guess it depends on the assembler you use. non-zero?<br>
<br>
TIL, you can't shift by 32 bits this way.<br>
<br>
Nico<br>
<br>
[1]<br>
<a href="https://web.archive.org/web/20131003180256/http://www.ibm.com/developerworks/linux/library/l-gas-nasm/index.html" rel="noreferrer" target="_blank">https://web.archive.org/web/20131003180256/http://www.ibm.com/developerworks/linux/library/l-gas-nasm/index.html</a><br>
</blockquote></div></div>