summaryrefslogtreecommitdiffstatshomepage
path: root/src/devices/cpu/mips/mips1.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Eliminate ARRAY_LENGTH template in favor of C++17's std::size AJR2021-02-141-10/+10
| | | | | | | | | | * osdcomm.h: Move definition of EQUIVALENT_ARRAY to coretmpl.h * sharc.cpp, gt64xxx.cpp, ym2413.cpp, gb_lcd.cpp, snes_ppu.cpp: Use STRUCT_MEMBER for save state registration * gio/newport.cpp, megadrive/svp.cpp, nes_ctrl/bcbattle.cpp, arm7.cpp, tms9995.cpp, pckeybrd.cpp, sa1110.cpp, sa1111.cpp, jangou_blitter.cpp, vic4567.cpp: Use std::fill(_n) instead of memset * emucore.h: Remove obsolete typedef
* sweeten most of the remaining arrays of delegates (nw) Vas Crabb2020-02-071-3/+2
|
* mips1: alignment checking/exceptions (nw) Patrick Mackinlay2020-01-241-31/+65
|
* mips1: remove unintended leftover(?) (nw) hap2019-12-181-1/+0
|
* mips1: cop0 initialization for r3041 (nw) Patrick Mackinlay2019-12-181-1/+16
|
* mips1: revert unnecessary/unwanted initialization (nw) Patrick Mackinlay2019-12-181-4/+1
| | | | | | | | | | | All of these variables are either: 1. Already initialized in the constructor or start/reset; or 2. Guarded against read-before-write by program logic; or 3. Documented as being in an undefined state at device power-up. Regarding the last point, my view is that if the documentation states the value is unpredictable/undefined at power up, I'd rather not initialize it to an arbitrary value. The absence of initialization in the code counts as documenting this behaviour, or conversely, initializing it to an arbitrary zero documents something which is not factual. While there is an argument for consistency in emulation, I'd rather expose and address any such undocumented hardware behaviour. I believe the only required and missing initialization here is for integer register zero, which was indeed a bug. If there are any other test cases which fail after this reversion, please let me know and I'll investigate and address them.
* cpu/mips/mips1: initialize some stuff (nw) Osso132019-12-141-0/+5
|
* mips1: undocumented behaviour (nw) Patrick Mackinlay2019-08-291-1/+12
|
* mips1: rework interrupts (nw) Patrick Mackinlay2019-08-091-52/+41
| | | | This fixes a bug causing IRIX to crash on 4D/20. Specifically, IRIX doesn't handle the case where the pc is pointing to an unmapped address when an interrupt occurs; presumably on real hardware this doesn't happen because the instruction fetch happens before interrupts are tested (or the pc isn't updated until after), and the fetch exception is prioritised over the incoming interrupt.
* mips1: clear softfloat exceptions (nw) Patrick Mackinlay2019-08-061-0/+2
|
* mips1: diagnostic fixes (nw) Patrick Mackinlay2019-07-251-25/+48
| | | | | | Some fixes identified by MIPS Rx3230 diagnostics: * assert/clear irq based on fpu exception state * mask entryhi/lo reserved bits
* mips1: add bus error line (nw) Patrick Mackinlay2019-07-181-5/+21
|
* mips: preserve upper 32 bits for single-precision fp operations (nw) Patrick Mackinlay2019-04-251-4/+20
| | | | | | | While this behaviour is undefined according to the MIPS R4000 Microprocessor User's Manual, various factors point toward it most likely being correct, including: 1. The fact MIPS-I exposes 16x64-bit floating-point registers, but internally implements them as pairs of 32-bit registers (with only the even-numbered pairs being valid for arithmetic operations), making it somewhat likely MOV.S, like LWC1 and SWC1, can access either half. 2. Explicit mention in IDT documentation and "See MIPS Run", i.e. "The odd-numbered registers can be accessed by move and load/store instructions", and other commentary. 3. The presence of paired-single operations in later MIPS32/64 specifications, which operate on independent single-precision values stored in each of the lower and upper halves of a single floating-point register.
* (nw) Clean up the mess on master Vas Crabb2019-03-261-613/+1505
| | | | | | | | | | | | | This effectively reverts b380514764cf857469bae61c11143a19f79a74c5 and c24473ddff715ecec2e258a6eb38960cf8c8e98e, restoring the state at 598cd5227223c3b04ca31f0dbc1981256d9ea3ff. Before pushing, please check that what you're about to push is sane. Check your local commit log and ensure there isn't anything out-of-place before pushing to mainline. When things like this happen, it wastes everyone's time. I really don't need this in a week when real work™ is busting my balls and I'm behind where I want to be with preparing for MAME release.
* Revert "conflict resolution (nw)" andreasnaive2019-03-251-1505/+613
| | | | | This reverts commit c24473ddff715ecec2e258a6eb38960cf8c8e98e, reversing changes made to 009cba4fb8102102168ef32870892438327f3705.
* mips1: bc2/bc3 always work (nw) Patrick Mackinlay2019-03-011-2/+64
| | | | BCzF/BCzT can be used (by reading input lines) when coprocessor 2 or 3 are enabled, even when there's no real coprocessor hardware.
* mips1: fpu emulation Patrick Mackinlay2019-02-261-659/+1269
| | | | | | | | Code refactoring makes the changes hard to isolate, but the main improvements are: * implemented fpu instructions and exceptions * corrected swl/swr implementation * tlb mru lookup optimization * interrupt and privilege debugger breakpoints
* mips1: magic number removal and more logging (nw) Patrick Mackinlay2019-01-091-58/+71
|
* mips1: fix Clang compile (nw) arbee2019-01-041-1/+1
|
* mips1: fix coprocessor exceptions (nw) Patrick Mackinlay2019-01-031-36/+243
| | | | | | * set the coprocessor error number in the cause register * corrected side-effect handling in address translation * added logging for RISC/os system calls
* mips1: fix stupid tlb error (nw) Patrick Mackinlay2019-01-011-3/+3
|
* mips1: tlb fixes (nw) Patrick Mackinlay2018-12-201-14/+35
| | | | | | * corrected cop0 context register encoding * corrected invalid tlb entry exception vector * improved logging
* mips1: missed this (nw) Patrick Mackinlay2018-12-181-1/+5
| | | | Make sure the exception target address isn't incremented.
* mips1: handle exceptions in delay slot instructions (nw) Patrick Mackinlay2018-12-181-30/+36
| | | | I introduced this error when adding tlb support and modifying the exception code previously. This resolves the error, cleans up delayed branch handling and fixes a panic in the mips rx2030 and rx3230 driver.
* (nw) adjust some stuff (uniform spacing, standardised logging, capitalised ↵ Vas Crabb2018-11-281-1/+1
| | | | template parameters, etc.)
* mips1: handle no cache (nw) Patrick Mackinlay2018-11-191-2/+4
|
* mips1: fix overflow logic (nw) Patrick Mackinlay2018-11-071-8/+27
|
* r3000: call it like it is (nw) Patrick Mackinlay2018-11-061-0/+989