On 5/7/14, 6:52 PM, Paolo Bonzini wrote:
Il 07/05/2014 14:32, Nadav Amit ha scritto:
32-bit operations are zero extended in 64-bit mode. Currently, the
code does
not handle them correctly and keeps the high bits. In 16-bit mode, the
high
32-bits are kept intact.
In addition, although it is not
On 5/7/14, 5:50 PM, Bandan Das wrote:
Nadav Amit writes:
32-bit operations are zero extended in 64-bit mode. Currently, the code does
not handle them correctly and keeps the high bits. In 16-bit mode, the high
32-bits are kept intact.
In addition, although it is not well-documented, when addr
Il 07/05/2014 14:32, Nadav Amit ha scritto:
32-bit operations are zero extended in 64-bit mode. Currently, the code does
not handle them correctly and keeps the high bits. In 16-bit mode, the high
32-bits are kept intact.
In addition, although it is not well-documented, when address override pre
Il 07/05/2014 16:50, Bandan Das ha scritto:
> +static void assign_masked(ulong *dest, ulong src, int bytes)
> {
> - *dest = (*dest & ~mask) | (src & mask);
> + switch (bytes) {
> + case 2:
> + *dest = (u16)src | (*dest & ~0xul);
> + break;
> + case 4:
> + *dest
Nadav Amit writes:
> 32-bit operations are zero extended in 64-bit mode. Currently, the code does
> not handle them correctly and keeps the high bits. In 16-bit mode, the high
> 32-bits are kept intact.
>
> In addition, although it is not well-documented, when address override prefix
It would be
32-bit operations are zero extended in 64-bit mode. Currently, the code does
not handle them correctly and keeps the high bits. In 16-bit mode, the high
32-bits are kept intact.
In addition, although it is not well-documented, when address override prefix
is used with REP-string instruction, RCX h
