Tight loop causes WinUAE to shoot up to 800% CPU usage

[Leffmann]

Not exactly common code, but a short "bra.l *" causes WinUAE in quickstart CE A1200 config to shoot up to 800%.

bra.w and bra.b makes it go up to 500% and 300% respectively, and jmp abs.l goes up to 150%. If I extend the loop with some bogus instructions like move.l a0,a0 then the CPU usage lowers for each new instruction I add, and if I insert just a single nop then the CPU usage stays perfectly normal at about 30%.

I tried several versions from 2.3.0 and up and it happens in all of them.

Also, is there any way to tell the debugger to break on op-code or on a full instruction? I've tried adding a memory op-code watchpoint but can't get it to work reliably, and usually it causes the debugger to freeze.

[StingRay]

Originally Posted by Leffmann

Also, is there any way to tell the debugger to break on op-code or on a full instruction?

You can use "fi" for that. E.g. fi 4e75 will break when the next rts instruction occurs.

[Leffmann]

Yeah I know about the fi command, but I need it to literally break on a specified op-code, so that I can close the debugger and have normal emulation until that op-code is in the instruction stream.

In any case the fi command doesn't work reliably, it either just triggers the Windows error sound and stops me from exiting the debugger, or it starts stepping one instruction at a time, and when I click the main window I lose the mouse pointer and I just can't find any way to get into the debugger or WinUAE config screen again.

[Toni Wilen]

Do not use GUI debugger (I don't use or care about it = unsupported). type xx and press return.

EDIT: CPU usage problem is normal, it is side-effect of 68020 CE instruction cache emulation hack that makes cache hits free and if loop has no data accesses. (=this problem happens only if loop is dummy loop = not that important).

CPU would be too slow if each instruction (or cache hit) adds 1 extra cycle, correct emulation would require full 68020 pipeline support which is very complex and not really documented either..

[Leffmann]

I actually get the same lockups and unreliable behavior with the console debugger and the fi command.

Is there any way at all I can make WinUAE emulate normally and break as soon as it hits a certain op-code or instruction? I'm just trying to avoid using anything that modifies registers or condition codes.

[Toni Wilen]

Debugger works fine here (and I use it very regularly).

Using windowed mode? (fullscreen + debugger = bad idea). It can also work strangely in JIT modes.

[Leffmann]

Windowed and quickstart best compatibility mode only. I take it there's no way to break on op-code then. It would be a great feature because you could insert almost non-intrusive breakpoints that way and it would all work with very little effort.

Is there a way to control the debugger from inside the emulated Amiga then? If so, can you explain the protocol? That way you could write a prologue to your program that registers breakpoint addresses with the debugger at least.

[Toni Wilen]

Originally Posted by Leffmann

Windowed and quickstart best compatibility mode only. I take it there's no way to break on op-code then. It would be a great feature because you could insert almost non-intrusive breakpoints that way and it would all work with very little effort.

fi is the command, you have some other problems if debugger hangs.

EDIT: what do you exactly do and what exactly happens?

Is there a way to control the debugger from inside the emulated Amiga then? If so, can you explain the protocol? That way you could write a prologue to your program that registers breakpoint addresses with the debugger at least.

There is none.

[Leffmann]

I'm using a quickstart A1200 best compatibility config, and I run a small program that executes op-code 0x2048 every 4 seconds. After I start the program I open the debugger and run "fi 0x2048", WinUAE then goes up from 20% to 150% CPU usage and stops responding. If I unlock the mouse pointer and close the debugger then WinUAE either continues to emulate as normal, or it shuts down. I've tried this with the same results on various versions from 2.3.0 and up on both Win XP 32-bit and Win 7 64-bit.

EDIT: just tried disabling CPU caches, and the CPU usage went up to 70% instead, and the 4 second loop took around 4 minutes to finish, and the program quit and WinUAE started to respond again, but the debugger never responded to the 0x2048 even though it did execute.

[Toni Wilen]

If it only hangs when using those kind of loops: don't use them, sorry.

[Leffmann]

Yeah I understand.. I'm not gonna bother you with it any more, but for the record the other problem with fi persists, it messes up the emulation session and never responds no matter how I use it. I hope the bug report is useful at least.

[Toni Wilen]

"works fine here"

[Leffmann]

You're welcome.