The first option is a flag that enables MPC601 (POWER) instructions for CPUs that are not MPC601.
This can be useful for the following reasons:
1) To produce results similar to classic Mac OS which emulates MPC601 instructions on CPUs that don't implement MPC601 instructions. This option is used to compare the risu traces produced in Mac OS 9 on a G3 or G4 with DPPC.
2) May increase performance in apps that use POWER instructions on emulated machines with CPUs that are not MPC601. It is not known if any such apps exist but there could be since Apple included MPC601 emulation in classic Mac OS.
Use "logical" since the functions deal with multiple bits instead of a single boolean value and because the 601 manual calls them Logical Instructions.
Use "ppc" for the enums because logical_and is defined elsewhere and because the original DPPC code used these names for those functions.
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.
Add MPC601 variants. Variants that decrement and test the ctr are invalid bon't don't appear to trigger an exception. The manual says MPC601 can decrement the counter. Other CPUs do not decrement the counter but will branch based on the value.
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.
It was always changing CR1 (starting at CR bit 4) instead of the CR selected by crfD.
Also, it was clearing all but the FL,FG,FE,FU bits of FPRF of FPSCR.
It's used in the main emulator loop (ppc_exec_inner), and the function
call overhead adds up.
By inlining it, time to boot to the Finder using a 7.1.2 install CD
and a 6100 ROM goes from ~6700ms to ~6400ms (with clang 14 on a
M2 Max)
Fixed an issue where TBR doesn't have full 64-bit range. The original calculation was 64 bit and ended with a ÷ 10^9. This means the max for the upper 32 bits is 2^32/10^9 = 4. The solution is to use a multiplication method that supports a 96 bit product. core/mathutils.h contains functions for that. TBR driving frequency is assumed to be less than 1 GHz. Some minor modification is required for future > 1 GHz support.
Fixed an issue where the following would cause inconsistent results (tb in the left column would sometimes decrement instead of always incrementing):
2 0 do 2 0 do cr tb@ 8 u.r ." ." 8 u.r loop 2 0 do cr 12 spaces rtc@ 8 u.r ." ." 8 u.r loop 2 0 do cr tb@ 8 u.r ." ." 8 u.r space rtc@ 8 u.r ." ." 8 u.r loop loop
RTC and TBR could not be used simultaneously because they are both incremented by an amount based on the last time stamp but that time stamp can be changed by accessing either RTC or TBR. The solution is to have a different time stamp for each.
