summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/118/none/1888165
blob: 2d3a6798497123de3601abf9ed067b20274816f0 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
virtual: 0.596
device: 0.594
ppc: 0.473
graphic: 0.445
architecture: 0.441
semantic: 0.425
x86: 0.417
network: 0.402
vnc: 0.336
debug: 0.319
mistranslation: 0.311
performance: 0.281
socket: 0.247
files: 0.240
kernel: 0.220
permissions: 0.206
user-level: 0.203
boot: 0.185
arm: 0.184
register: 0.168
TCG: 0.122
PID: 0.118
risc-v: 0.116
VMM: 0.110
peripherals: 0.110
hypervisor: 0.095
assembly: 0.089
KVM: 0.051
i386: 0.020

loopz/loopnz clearing previous instruction's modified flags on cx -> 0

If you run QBasic in qemu, printing a double-type single-digit number will print an extra decimal point (e.g. PRINT CDBL(3) prints "3.") that does not appear when running on a real CPU (or on qemu with -enable-kvm). I tracked this down to the state of the status flags after a loopnz instruction.

After executing a sequence like this in qemu:

	mov bx,1
	mov cx,1
	dec bx    ; sets Z bit in flags
A:	loopnz A  ; should not modify flags

Z is incorrectly clear afterwards. loopz does the same thing (but not plain loop). Interestingly, inserting pushf+popf after dec results in Z set, so loopnz/loopz does not always clear Z itself but is rather interfering with the previous instruction's flag setting.

Version 5.1.0-rc0, x86-64 host.





https://git.qemu.org/?p=qemu.git;a=commitdiff;h=3cb3a7720b01830abd5