Replace it wth an explicit opcode parameter that is passed around. That
is both slightly easier to reason about (to trace where it comes from)
and slightly faster, since it can be read from a register.
On my machine takes booting to "Welcome to Macintosh" being output in
a verbose boot of Mac OS X 10.2.8 from 31.8s to 30.6s (average of 5
runs, measured using deterministic mode and looking at when execution
reaches PC 0x90004a88).
Enterring a blank command continues the disassembly or stepping for one instruction. Erasing the prompt saves one line in the console so the disassembly doesn't appear double spaced. I don't know if the terminal control sequence works in Windows.
Shutdown will enter the debugger or quit depending on the execution mode.
Quit is different from shutdown since it is triggered outside the guest by using the host Quit menu item.
There are cases where when it's necessary (e.g. given uninitialized NVRAM,
the Beige G3 with the 10.2 install CD inserted will update the boot
device and restart to boot from it).
Restart support was done by wrapping the ppc_exec function in a loop and
checking for a restart power off reason. We also need to disconnect all
event listeners, since they will be recreated when the machine is
re-initialized.
Typing Control-C in Terminal app causes an interrupt signal that should enter the DPPC debugger but this only worked once since the signal handler never returned. Even if the signal handler reenabled the signal somehow, it calls enter_debugger recursively which is strange since the earlier calls to enter_debugger would never return.
Now the signal handler just sets a flag (power_on) which can be used to exit any loop (emulator loops, stepping loops, disassembly loops, dumping loops).
Main always calls enter_debugger now which calls the ppc_exec loop. The power_on flag will exit the ppc_exec loop to return to the debugger. Recursion of enter_debugger is eliminated except for calls to loguru's ABORT_F.
An enum power_off_reason is used to indicate why the power_on flag is set to false and to determine what happens next.
Entering a blank command causes the last command to repeat. This doesn't make sense for the following commands:
help, quit, regs, context, printenv, setenv, nvedit, amicint, viaint.
If debugging with Xcode using Terminal.app for the console, Terminal.app may send empty lines to the dingusppc debugger while resizing the Terminal.app window and it will do this forever.
As a workaround, use std::cin.clear() to clear the input buffer before getline and loop until the terminal window size is not changing or the input line is not empty.
Use explicit cast when converting large integer types to smaller integer types when it is known that the most significant bytes are not required.
For pcidevice, check the ROM file size before casting to int. We'll allow expansion ROM sizes up to 4MB but usually they are 64K, sometimes 128K, rarely 256K.
for machinefactory, change the type to size_t so that it can correctly get the size of files that are larger than 4GB; it already checks the file size is 4MB before we need to cast to uint32_t.
For floppyimg, check the image size before casting to int. For raw images, only allow files up to 2MB. For DiskCopy42 images, it already checks the file size, so do the cast after that.
setenv doesn't allow entering strings that include multiple lines which is useful for nvramrc.
nvedit uses CTRL-C to end editing, like Open Firmware. It does not support deleting characters from a line or editing previous lines or any other special keys. It doesn't have nvstore or nvquit or nvrecover commands. Basically, you should edit your nvramrc in a text editor, then copy and paste into the debugger.
