bsnes/higan/processor/arm/registers.hpp

122 lines
3.5 KiB
C++
Raw Normal View History

struct GPR {
inline operator uint32_t() const { return data; }
inline auto operator=(uint32_t n) { data = n; if(modify) modify(); return *this; }
inline auto operator=(const GPR& source) { return operator=(source.data); }
inline auto operator &=(uint32_t n) { return operator=(data & n); }
inline auto operator |=(uint32_t n) { return operator=(data | n); }
inline auto operator ^=(uint32_t n) { return operator=(data ^ n); }
inline auto operator +=(uint32_t n) { return operator=(data + n); }
inline auto operator -=(uint32_t n) { return operator=(data - n); }
inline auto operator *=(uint32_t n) { return operator=(data * n); }
inline auto operator /=(uint32_t n) { return operator=(data / n); }
inline auto operator %=(uint32_t n) { return operator=(data % n); }
inline auto operator<<=(uint32_t n) { return operator=(data << n); }
inline auto operator>>=(uint32_t n) { return operator=(data >> n); }
uint32_t data = 0;
function<auto () -> void> modify;
};
struct PSR {
Update to v098r19 release. byuu says: Changelog: - added nall/bit-field.hpp - updated all CPU cores (sans LR35902 due to some complexities) to use BitFields instead of bools - updated as many CPU cores as I could to use BitFields instead of union { struct { uint8_t ... }; }; pairs The speed changes are mostly a wash for this. In some instances, I noticed a ~2-3% speedup (eg SNES emulation), and in others a 2-3% slowdown (eg Famicom emulation.) It's within the margin of error, so it's safe to say it has no impact. This does give us a lot of new useful things, however: - no more manual reconstruction of flag values from lots of left shifts and ORs - no more manual deconstruction of flag values from lots of ANDs - ability to get completely free aliases to flag groups (eg GSU can provide alt2, alt1 and also alt (which is alt2,alt1 combined) - removes the need for the nasty order_lsbN macro hack (eventually will make higan 100% endian independent) - saves us from insane compilers that try and do nasty things with alignment on union-structs - saves us from insane compilers that try to store bit-field bits in reverse order - will allow some really novel new use cases (I'm planning an instant-decode ARM opcode function, for instance.) - reduces code size (we can serialize flag registers in one line instead of one for each flag) However, I probably won't use it for super critical code that's constantly reading out register values (eg PPU MMIO registers.) I think there we would end up with a performance penalty.
2016-06-08 22:26:35 +00:00
union {
uint32_t data = 0;
BooleanBitField<uint32_t, 31> n; //negative
BooleanBitField<uint32_t, 30> z; //zero
BooleanBitField<uint32_t, 29> c; //carry
BooleanBitField<uint32_t, 28> v; //overflow
BooleanBitField<uint32_t, 7> i; //irq
BooleanBitField<uint32_t, 6> f; //fiq
BooleanBitField<uint32_t, 5> t; //thumb
NaturalBitField<uint32_t, 4, 0> m; //mode
Update to v098r19 release. byuu says: Changelog: - added nall/bit-field.hpp - updated all CPU cores (sans LR35902 due to some complexities) to use BitFields instead of bools - updated as many CPU cores as I could to use BitFields instead of union { struct { uint8_t ... }; }; pairs The speed changes are mostly a wash for this. In some instances, I noticed a ~2-3% speedup (eg SNES emulation), and in others a 2-3% slowdown (eg Famicom emulation.) It's within the margin of error, so it's safe to say it has no impact. This does give us a lot of new useful things, however: - no more manual reconstruction of flag values from lots of left shifts and ORs - no more manual deconstruction of flag values from lots of ANDs - ability to get completely free aliases to flag groups (eg GSU can provide alt2, alt1 and also alt (which is alt2,alt1 combined) - removes the need for the nasty order_lsbN macro hack (eventually will make higan 100% endian independent) - saves us from insane compilers that try and do nasty things with alignment on union-structs - saves us from insane compilers that try to store bit-field bits in reverse order - will allow some really novel new use cases (I'm planning an instant-decode ARM opcode function, for instance.) - reduces code size (we can serialize flag registers in one line instead of one for each flag) However, I probably won't use it for super critical code that's constantly reading out register values (eg PPU MMIO registers.) I think there we would end up with a performance penalty.
2016-06-08 22:26:35 +00:00
};
PSR() = default;
PSR(const PSR& value) { data = value.data; }
inline operator uint() const { return data & 0xf00000ff; }
inline auto& operator=(uint value) { return data = value, *this; }
inline auto& operator=(const PSR& value) { return data = value.data, *this; }
};
struct Pipeline {
bool reload = false;
bool nonsequential = false;
struct Instruction {
uint32 address = 0;
uint32 instruction = 0;
};
Instruction execute;
Instruction decode;
Instruction fetch;
};
struct Processor {
Update to v099r13 release. byuu says: Changelog: - GB core code cleanup completed - GBA core code cleanup completed - some more cleanup on missed processor/arm functions/variables - fixed FC loading icarus bug - "Load ROM File" icarus functionality restored - minor code unification efforts all around (not perfect yet) - MMIO->IO - mmio.cpp->io.cpp - read,write->readIO,writeIO It's been a very long work in progress ... starting all the way back with v094r09, but the major part of the higan code cleanup is now completed! Of course, it's very important to note that this is only for the basic style: - under_score functions and variables are now camelCase - return-type function-name() are now auto function-name() -> return-type - Natural<T>/Integer<T> replace (u)intT_n types where possible - signed/unsigned are now int/uint - most of the x==true,x==false tests changed to x,!x A lot of spot improvements to consistency, simplicity and quality have gone in along the way, of course. But we'll probably never fully finishing beautifying every last line of code in the entire codebase. Still, this is a really great start. Going forward, WIP diffs should start being smaller and of higher quality once again. I know the joke is, "until my coding style changes again", but ... this was way too stressful, way too time consuming, and way too risky. I'm too old and tired now for extreme upheavel like this again. The only major change I'm slowly mulling over would be renaming the using Natural<T>/Integer<T> = (u)intT; shorthand to something that isn't as easily confused with the (u)int_t types ... but we'll see. I'll definitely continue to change small things all the time, but for the larger picture, I need to just accept the style I have and live with it.
2016-06-29 11:10:28 +00:00
enum class Mode : uint {
USR = 0x10, //user
FIQ = 0x11, //fast interrupt request
IRQ = 0x12, //interrupt request
SVC = 0x13, //supervisor (software interrupt)
ABT = 0x17, //abort
UND = 0x1b, //undefined
SYS = 0x1f, //system
};
GPR r0, r1, r2, r3, r4, r5, r6, r7;
struct USR {
GPR r8, r9, r10, r11, r12, sp, lr;
} usr;
struct FIQ {
GPR r8, r9, r10, r11, r12, sp, lr;
PSR spsr;
} fiq;
struct IRQ {
GPR sp, lr;
PSR spsr;
} irq;
struct SVC {
GPR sp, lr;
PSR spsr;
} svc;
struct ABT {
GPR sp, lr;
PSR spsr;
} abt;
struct UND {
GPR sp, lr;
PSR spsr;
} und;
GPR pc;
PSR cpsr;
bool carryout = false;
bool irqline = false;
GPR* r[16] = {nullptr};
PSR* spsr = nullptr;
auto power() -> void;
auto setMode(Mode) -> void;
};
Processor processor;
Pipeline pipeline;
bool crash = false;
alwaysinline auto r(uint n) -> GPR& { return *processor.r[n]; }
alwaysinline auto cpsr() -> PSR& { return processor.cpsr; }
alwaysinline auto spsr() -> PSR& { return *processor.spsr; }
alwaysinline auto carryout() -> bool& { return processor.carryout; }
alwaysinline auto instruction() -> uint32 { return pipeline.execute.instruction; }
Update to v098r19 release. byuu says: Changelog: - added nall/bit-field.hpp - updated all CPU cores (sans LR35902 due to some complexities) to use BitFields instead of bools - updated as many CPU cores as I could to use BitFields instead of union { struct { uint8_t ... }; }; pairs The speed changes are mostly a wash for this. In some instances, I noticed a ~2-3% speedup (eg SNES emulation), and in others a 2-3% slowdown (eg Famicom emulation.) It's within the margin of error, so it's safe to say it has no impact. This does give us a lot of new useful things, however: - no more manual reconstruction of flag values from lots of left shifts and ORs - no more manual deconstruction of flag values from lots of ANDs - ability to get completely free aliases to flag groups (eg GSU can provide alt2, alt1 and also alt (which is alt2,alt1 combined) - removes the need for the nasty order_lsbN macro hack (eventually will make higan 100% endian independent) - saves us from insane compilers that try and do nasty things with alignment on union-structs - saves us from insane compilers that try to store bit-field bits in reverse order - will allow some really novel new use cases (I'm planning an instant-decode ARM opcode function, for instance.) - reduces code size (we can serialize flag registers in one line instead of one for each flag) However, I probably won't use it for super critical code that's constantly reading out register values (eg PPU MMIO registers.) I think there we would end up with a performance penalty.
2016-06-08 22:26:35 +00:00
alwaysinline auto mode() -> Processor::Mode { return (Processor::Mode)(uint)processor.cpsr.m; }
alwaysinline auto privilegedMode() const -> bool { return (Processor::Mode)(uint)processor.cpsr.m != Processor::Mode::USR; }
alwaysinline auto exceptionMode() const -> bool { return privilegedMode() && (Processor::Mode)(uint)processor.cpsr.m != Processor::Mode::SYS; }