On 29.03.2018 23:58, ron minnich wrote:
believe it or not that code runs on coreboot simulator, hardware, and qemu,
What is `coreboot simulator`?
and gets a different answer on each.
Same binary and same processor (e.g. 32-bit protected) mode?
Without knowing what your assembler translated it to, anything seems possible.
Nico
On Thu, Mar 29, 2018 at 3:16 PM Nico Huber nico.h@gmx.de wrote:
On 29.03.2018 23:58, ron minnich wrote:
believe it or not that code runs on coreboot simulator, hardware, and
qemu,
What is `coreboot simulator`?
the 8086 one in yabel.
So here's what I think is going on.
you're doing a shrdw with a 64-bit number in ebx,eax, target is %ax.
In one intel architecture manual, it says, on 8086, that shifts of 16 bits or greater will happen, with the result of 0. On 386 and later, according to some docs, "if the count is greater than the operand size, the result is undefined." According to another intel ref manual, if the shift count is greater than the operand size, the instruction is not executed.
Other docs say only the lower 5 bits of the count are used.
qemu, yabel, and real hardware don't really agree on the result.
No big deal, I thought people would find it amusing.
It only came up because I ported the yabel x86 simulator to Go, and I'm doing verification with the qemu verification tests, and this is one small difference that has come up.
For the record, with eax=12345678 ebx=aaaa5555 cl=0x10 qemu believes the right answer for shrdw is eax=12345555
i.e. ax gets bx. which surprised me. ron
-
Nico Huber -
ron minnich