There's probably still an issue with the inf_nan check
using reg_a for the first value instead of reg_a * reg_c.
This will probably need rewriting anyway.
genppctests.py
- Fix incorrect bits for some floating-point instruction opcodes or fields.
- Use separate register for FP results like DolphinPPCTests does.
- Remove extra FMULS.
- Use a regular expression for parsing ppcfloattest.txt. Don't parse the values, just put them in the output ppcloattests.csv file.
ppcfloattest.txt
- Clear crf0 and crf7 because we only care about crf1.
- Use values from DolphinPPCTests (0.0, 0.5, 1.0, 3.5, DBL_MAX, FLT_MAX, 2.4679999352, 4.9359998704, etc.). Some of the values were rounded. This will un-round them. Specify snan or qnan instead of nan.
- One of the FCMPO and FCMPU tests had qnan instead of snan input values.
ppcfloattest.csv
- Regenerate this file using the updated genppctests.py which uses the updated ppcfloattest.txt.
ppctests
- Update double_from_string to be able to parse the new values (snan, qnan, FLT_MAX, DBL_MAX).
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.
The `SubOpcode31Grabber[1024] = { ppc_illegalop }` initializer only
populates the first entry with ppc_illegalop (at least on some compilers),
switch to explicitly initializing the entire array with std::fill_n.
Also fix a couple of sign and overflow issues flagged by the Xcode
undefined behavior sanitizer.
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)
doz and dozi were storing the result into the wrong register.
nabs was not taking into account two's complement storage of numbers
and was just setting the signed bit.
These two instructions are used in the implementation of text
measurement in native QuickDraw on 7.1.2/the PDM ROM, and the incorrect
values were resulting in nothing being rendered. With the fix text
appears when booting from the 7.1.2 CD.
Result of running IWYU (https://include-what-you-use.org/) and
applying most of the suggestions about unncessary includes and
forward declarations.
Was motivated by observing that <thread> was being included in
ppcopcodes.cpp even though it was unused (found while researching
the use of threads), but seems generally good to help with build
times and correctness.
While booting Mac OS X 10.2 installer CD, a return from RFI didn't change the instruction address virtual memory page but did change the physical memory page so we must always recalculate the physical address after RFI.
Perhaps there are other cases where this may be required?
- Subtract one so that it can't overflow to zero.
- Use page_start as the base so mask operation is not required.
- Recalculate it only when the page changes.
The same flag was being used for flushing both instruction and data TLBs so sometimes a flush for one TLB list would not occur if the flag was cleared when flushing the other TLB list.
Don't log consecutive accesses to unmapped physical memory addresses. This saves a couple hundred thousand lines in the log in some cases.
This is only a partial fix. Any access that isn't logged should be queued and output if a log message is output that is not this log message or after a time period.
- mpc601_block_address_translation will now return 0 for prot and pa when bat_hit is false (when the if statement is not positive during the for loop). The calling function doesn't care what prot and pa are when bat_hit is false, but we do this to remove the compiler warining.
- For tlb_flush_entry, the compiler thinks m might not always be in the range 0 to 5 so tlb1 and tlb2 might not get initialized by the switch statement. Add default to get around this warning.
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.
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 get-msecs-601 and get-msecs-60x were not returning the same value. RTC was being calculated using timebase frequency instead of nanosecond frequency. 601 uses RTC. 60x uses TBR. On a real Mac, a G3 CPU won't have a RTC and accessing RTC would cause an exception. This is not the case for dingusppc but I don't think that's a problem.
Fixed an issue where RTC was not being updated if only the upper 32 bits (seconds) was read.
Also simplified things by always updating the timestamp instead of only when the seconds changes.
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.
Fixed a typo that caused rtc@ to always return 0 for the upper 32 bits (represents seconds).
The problem could cause the following to hang on Power Mac 7500:
cr 2000 0 do get-msecs u. 1 ms loop
