bsnes/nall/primitives/natural.hpp

103 lines
5.1 KiB
C++
Raw Normal View History

Update to v106r77 release. byuu says: So this turned out to be a rather unproductive ten-hour rabbit hole, but ... I reworked nall/primitives.hpp a lot. And because the changes are massive, testing of this WIP for regressions is critically important. I really can't stress that enough, we're almost certainly going to have some hidden regressions here ... We now have a nall/primitives/ subfolder that splits up the classes into manageable components. The bit-field support is now shared between both Natural and Integer. All of the assignment operator overloads are now templated and take references instead of values. Things like the GSU::Register class are non-copyable on account of the function<> object inside of it, and previously only operator= would work with classes like that. The big change is nall/primitives/operators.hpp, which is a really elaborate system to compute the minimum number of bits needed for any operation, and to return a Natural<T> or Integer<T> when one or both of the arguments are such a type. Unfortunately, it doesn't really work yet ... Kirby's Dream Land 3 breaks if we include operators.hpp. Zelda 3 runs fine with this, but I had to make a huge amount of core changes, including introducing a new ternary(bool, lhs, rhs) function to nall/algorithm to get past Natural<X> and Natural<Y> not being equivalent (is_integral types get a special exemption to ternary ?: type equivalence, yet it's impossible to simulate with our own classes, which is bullshit.) The horrifying part is that ternary() will evaluate both lhs and rhs, unlike ?: I converted some of the functions to test ? uint(x) : uint(y), and others to ternary(test, x, y) ... I don't have a strong preference either way yet. But the part where things may have gotten broken is in the changes to where ternary() was placed. Some cases like in the GBA PPU renderer, it was rather unclear the order of evaluations, so I may have made a mistake somewhere. So again, please please test this if you can. Or even better, look over the diff. Longer-term, I'd really like the enable nall/primitives/operators.hpp, but right now I'm not sure why Kirby's Dream Land 3 is breaking. Help would be appreciated, but ... it's gonna be really complex and difficult to debug, so I'm probably gonna be on my own here ... sigh.
2019-01-13 06:25:14 +00:00
#pragma once
namespace nall {
Update to v106r83 release. byuu says: Changelog: - reverted nall/inline-if.hpp usage for now, since the nall/primitives.hpp math operators still cast to (u)int64_t - improved nall/primitives.hpp more; integer8 x = -128; print(-x) will now print 128 (unary operator+ and - cast to (u)int64_t) - renamed processor/lr35902 to processor/sm83; after the Sharp SM83 CPU core [gekkio discovered the name] - a few bugfixes to the TLCS900H CPU core - completed the disassembler for the TLCS900H core As a result of reverting most of the inline if stuff, I guess the testing priority has been reduced. Which is probably a good thing, considering I seem to have a smaller pool of testers these days. Indeed, the TLCS900H core has ended up at 131KiB compared to the M68000 core at 128KiB. So it's now the largest CPU core in all of higan. It's even more ridiculous because the M68000 core would ordinarily be quite a bit smaller, had I not gone overboard with the extreme templating to reduce instruction decoding overhead (you kind of have to do this for RISC CPUs, and the inverted design of the TLCS900H kind of makes it infeasible to do the same there.) This CPU core is bound to have dozens of extremely difficult CPU bugs, and there's no easy way for me to test them. I would greatly appreciate any help in looking over the core for bugs. A fresh pair of eyes to spot a mistake could save me up to several days of tedious debugging work. The core still isn't ready to actually be tested: I have to hook up cartridge loading, a memory bus, interrupts, timers, and the micro DMA controller before it's likely that anything happens at all.
2019-01-19 01:34:17 +00:00
template<uint Precision = 64> struct Natural {
static_assert(Precision >= 1 && Precision <= 64);
Update to v106r77 release. byuu says: So this turned out to be a rather unproductive ten-hour rabbit hole, but ... I reworked nall/primitives.hpp a lot. And because the changes are massive, testing of this WIP for regressions is critically important. I really can't stress that enough, we're almost certainly going to have some hidden regressions here ... We now have a nall/primitives/ subfolder that splits up the classes into manageable components. The bit-field support is now shared between both Natural and Integer. All of the assignment operator overloads are now templated and take references instead of values. Things like the GSU::Register class are non-copyable on account of the function<> object inside of it, and previously only operator= would work with classes like that. The big change is nall/primitives/operators.hpp, which is a really elaborate system to compute the minimum number of bits needed for any operation, and to return a Natural<T> or Integer<T> when one or both of the arguments are such a type. Unfortunately, it doesn't really work yet ... Kirby's Dream Land 3 breaks if we include operators.hpp. Zelda 3 runs fine with this, but I had to make a huge amount of core changes, including introducing a new ternary(bool, lhs, rhs) function to nall/algorithm to get past Natural<X> and Natural<Y> not being equivalent (is_integral types get a special exemption to ternary ?: type equivalence, yet it's impossible to simulate with our own classes, which is bullshit.) The horrifying part is that ternary() will evaluate both lhs and rhs, unlike ?: I converted some of the functions to test ? uint(x) : uint(y), and others to ternary(test, x, y) ... I don't have a strong preference either way yet. But the part where things may have gotten broken is in the changes to where ternary() was placed. Some cases like in the GBA PPU renderer, it was rather unclear the order of evaluations, so I may have made a mistake somewhere. So again, please please test this if you can. Or even better, look over the diff. Longer-term, I'd really like the enable nall/primitives/operators.hpp, but right now I'm not sure why Kirby's Dream Land 3 is breaking. Help would be appreciated, but ... it's gonna be really complex and difficult to debug, so I'm probably gonna be on my own here ... sigh.
2019-01-13 06:25:14 +00:00
static inline constexpr auto bits() -> uint { return Precision; }
using utype =
Update to v106r83 release. byuu says: Changelog: - reverted nall/inline-if.hpp usage for now, since the nall/primitives.hpp math operators still cast to (u)int64_t - improved nall/primitives.hpp more; integer8 x = -128; print(-x) will now print 128 (unary operator+ and - cast to (u)int64_t) - renamed processor/lr35902 to processor/sm83; after the Sharp SM83 CPU core [gekkio discovered the name] - a few bugfixes to the TLCS900H CPU core - completed the disassembler for the TLCS900H core As a result of reverting most of the inline if stuff, I guess the testing priority has been reduced. Which is probably a good thing, considering I seem to have a smaller pool of testers these days. Indeed, the TLCS900H core has ended up at 131KiB compared to the M68000 core at 128KiB. So it's now the largest CPU core in all of higan. It's even more ridiculous because the M68000 core would ordinarily be quite a bit smaller, had I not gone overboard with the extreme templating to reduce instruction decoding overhead (you kind of have to do this for RISC CPUs, and the inverted design of the TLCS900H kind of makes it infeasible to do the same there.) This CPU core is bound to have dozens of extremely difficult CPU bugs, and there's no easy way for me to test them. I would greatly appreciate any help in looking over the core for bugs. A fresh pair of eyes to spot a mistake could save me up to several days of tedious debugging work. The core still isn't ready to actually be tested: I have to hook up cartridge loading, a memory bus, interrupts, timers, and the micro DMA controller before it's likely that anything happens at all.
2019-01-19 01:34:17 +00:00
conditional_t<bits() <= 8, uint8_t,
conditional_t<bits() <= 16, uint16_t,
conditional_t<bits() <= 32, uint32_t,
conditional_t<bits() <= 64, uint64_t,
void>>>>;
static inline constexpr auto mask() -> utype { return ~0ull >> 64 - bits(); }
Update to v106r77 release. byuu says: So this turned out to be a rather unproductive ten-hour rabbit hole, but ... I reworked nall/primitives.hpp a lot. And because the changes are massive, testing of this WIP for regressions is critically important. I really can't stress that enough, we're almost certainly going to have some hidden regressions here ... We now have a nall/primitives/ subfolder that splits up the classes into manageable components. The bit-field support is now shared between both Natural and Integer. All of the assignment operator overloads are now templated and take references instead of values. Things like the GSU::Register class are non-copyable on account of the function<> object inside of it, and previously only operator= would work with classes like that. The big change is nall/primitives/operators.hpp, which is a really elaborate system to compute the minimum number of bits needed for any operation, and to return a Natural<T> or Integer<T> when one or both of the arguments are such a type. Unfortunately, it doesn't really work yet ... Kirby's Dream Land 3 breaks if we include operators.hpp. Zelda 3 runs fine with this, but I had to make a huge amount of core changes, including introducing a new ternary(bool, lhs, rhs) function to nall/algorithm to get past Natural<X> and Natural<Y> not being equivalent (is_integral types get a special exemption to ternary ?: type equivalence, yet it's impossible to simulate with our own classes, which is bullshit.) The horrifying part is that ternary() will evaluate both lhs and rhs, unlike ?: I converted some of the functions to test ? uint(x) : uint(y), and others to ternary(test, x, y) ... I don't have a strong preference either way yet. But the part where things may have gotten broken is in the changes to where ternary() was placed. Some cases like in the GBA PPU renderer, it was rather unclear the order of evaluations, so I may have made a mistake somewhere. So again, please please test this if you can. Or even better, look over the diff. Longer-term, I'd really like the enable nall/primitives/operators.hpp, but right now I'm not sure why Kirby's Dream Land 3 is breaking. Help would be appreciated, but ... it's gonna be really complex and difficult to debug, so I'm probably gonna be on my own here ... sigh.
2019-01-13 06:25:14 +00:00
inline Natural() : data(0) {}
Update to v106r79 release. byuu says: This WIP is just work on nall/primitives ... Basically, I'm coming to the conclusion that it's just not practical to try and make Natural/Integer implicitly castable to primitive signed and unsigned integers. C++ just has too many edge cases there. I also want to get away from the problem of C++ deciding that all math operations return 32-bit values, unless one of the parameters is 64-bit, in which case you get a 64-bit value. You know, so things like array[-1] won't end up accessing the 4 billionth element of the array. It's nice to be fancy and minimally size operations (eg 32-bit+32-bit = 33-bit), but it's just too unintuitive. I think all Natural<X>+Natural<Y> expessions should result in a Natural<64> (eg natural) type. nall/primitives/operators.hpp has been removed, and new Natural<>Natural / Integer<>Integer casts exist. My feeling is that signed and unsigned types should not be implicitly convertible where data loss can occur. In the future, I think an integer8*natural8 is fine to return an integer64, and the bitwise operators are probably all fine between the two types. I could probably add (Integer,Natural)+Boolean conversions as well. To simplify expressions, there are new user-defined literals for _b (boolean), _n (natural), _i (integer), _r (real), _n# (eg _n8), _i# (eg _i8), _r# (eg _r32), and _s (nall::string). In the long-term, my intention is to make the conversion and cast constructors explicit for primitive types, but obviously that'll shatter most of higan, so for now that won't be the case. Something I can do in the future is allow implicit conversion and casting to (u)int64_t. That may be a nice balance.
2019-01-15 04:33:20 +00:00
template<int Bits> inline Natural(Natural<Bits> value) { data = mask(value); }
Update to v106r77 release. byuu says: So this turned out to be a rather unproductive ten-hour rabbit hole, but ... I reworked nall/primitives.hpp a lot. And because the changes are massive, testing of this WIP for regressions is critically important. I really can't stress that enough, we're almost certainly going to have some hidden regressions here ... We now have a nall/primitives/ subfolder that splits up the classes into manageable components. The bit-field support is now shared between both Natural and Integer. All of the assignment operator overloads are now templated and take references instead of values. Things like the GSU::Register class are non-copyable on account of the function<> object inside of it, and previously only operator= would work with classes like that. The big change is nall/primitives/operators.hpp, which is a really elaborate system to compute the minimum number of bits needed for any operation, and to return a Natural<T> or Integer<T> when one or both of the arguments are such a type. Unfortunately, it doesn't really work yet ... Kirby's Dream Land 3 breaks if we include operators.hpp. Zelda 3 runs fine with this, but I had to make a huge amount of core changes, including introducing a new ternary(bool, lhs, rhs) function to nall/algorithm to get past Natural<X> and Natural<Y> not being equivalent (is_integral types get a special exemption to ternary ?: type equivalence, yet it's impossible to simulate with our own classes, which is bullshit.) The horrifying part is that ternary() will evaluate both lhs and rhs, unlike ?: I converted some of the functions to test ? uint(x) : uint(y), and others to ternary(test, x, y) ... I don't have a strong preference either way yet. But the part where things may have gotten broken is in the changes to where ternary() was placed. Some cases like in the GBA PPU renderer, it was rather unclear the order of evaluations, so I may have made a mistake somewhere. So again, please please test this if you can. Or even better, look over the diff. Longer-term, I'd really like the enable nall/primitives/operators.hpp, but right now I'm not sure why Kirby's Dream Land 3 is breaking. Help would be appreciated, but ... it's gonna be really complex and difficult to debug, so I'm probably gonna be on my own here ... sigh.
2019-01-13 06:25:14 +00:00
template<typename T> inline Natural(const T& value) { data = mask(value); }
Update to v106r79 release. byuu says: This WIP is just work on nall/primitives ... Basically, I'm coming to the conclusion that it's just not practical to try and make Natural/Integer implicitly castable to primitive signed and unsigned integers. C++ just has too many edge cases there. I also want to get away from the problem of C++ deciding that all math operations return 32-bit values, unless one of the parameters is 64-bit, in which case you get a 64-bit value. You know, so things like array[-1] won't end up accessing the 4 billionth element of the array. It's nice to be fancy and minimally size operations (eg 32-bit+32-bit = 33-bit), but it's just too unintuitive. I think all Natural<X>+Natural<Y> expessions should result in a Natural<64> (eg natural) type. nall/primitives/operators.hpp has been removed, and new Natural<>Natural / Integer<>Integer casts exist. My feeling is that signed and unsigned types should not be implicitly convertible where data loss can occur. In the future, I think an integer8*natural8 is fine to return an integer64, and the bitwise operators are probably all fine between the two types. I could probably add (Integer,Natural)+Boolean conversions as well. To simplify expressions, there are new user-defined literals for _b (boolean), _n (natural), _i (integer), _r (real), _n# (eg _n8), _i# (eg _i8), _r# (eg _r32), and _s (nall::string). In the long-term, my intention is to make the conversion and cast constructors explicit for primitive types, but obviously that'll shatter most of higan, so for now that won't be the case. Something I can do in the future is allow implicit conversion and casting to (u)int64_t. That may be a nice balance.
2019-01-15 04:33:20 +00:00
explicit inline operator bool() const { return data; }
inline operator uint64_t() const { return data; }
Update to v106r77 release. byuu says: So this turned out to be a rather unproductive ten-hour rabbit hole, but ... I reworked nall/primitives.hpp a lot. And because the changes are massive, testing of this WIP for regressions is critically important. I really can't stress that enough, we're almost certainly going to have some hidden regressions here ... We now have a nall/primitives/ subfolder that splits up the classes into manageable components. The bit-field support is now shared between both Natural and Integer. All of the assignment operator overloads are now templated and take references instead of values. Things like the GSU::Register class are non-copyable on account of the function<> object inside of it, and previously only operator= would work with classes like that. The big change is nall/primitives/operators.hpp, which is a really elaborate system to compute the minimum number of bits needed for any operation, and to return a Natural<T> or Integer<T> when one or both of the arguments are such a type. Unfortunately, it doesn't really work yet ... Kirby's Dream Land 3 breaks if we include operators.hpp. Zelda 3 runs fine with this, but I had to make a huge amount of core changes, including introducing a new ternary(bool, lhs, rhs) function to nall/algorithm to get past Natural<X> and Natural<Y> not being equivalent (is_integral types get a special exemption to ternary ?: type equivalence, yet it's impossible to simulate with our own classes, which is bullshit.) The horrifying part is that ternary() will evaluate both lhs and rhs, unlike ?: I converted some of the functions to test ? uint(x) : uint(y), and others to ternary(test, x, y) ... I don't have a strong preference either way yet. But the part where things may have gotten broken is in the changes to where ternary() was placed. Some cases like in the GBA PPU renderer, it was rather unclear the order of evaluations, so I may have made a mistake somewhere. So again, please please test this if you can. Or even better, look over the diff. Longer-term, I'd really like the enable nall/primitives/operators.hpp, but right now I'm not sure why Kirby's Dream Land 3 is breaking. Help would be appreciated, but ... it's gonna be really complex and difficult to debug, so I'm probably gonna be on my own here ... sigh.
2019-01-13 06:25:14 +00:00
inline auto operator++(int) { auto value = *this; data = mask(data + 1); return value; }
inline auto operator--(int) { auto value = *this; data = mask(data - 1); return value; }
inline auto& operator++() { data = mask(data + 1); return *this; }
inline auto& operator--() { data = mask(data - 1); return *this; }
inline auto operator!() const { return !data; }
inline auto operator~() const { return Natural<>{mask(~data)}; }
inline auto operator+() const { return Natural<>{+data}; }
Update to v106r83 release. byuu says: Changelog: - reverted nall/inline-if.hpp usage for now, since the nall/primitives.hpp math operators still cast to (u)int64_t - improved nall/primitives.hpp more; integer8 x = -128; print(-x) will now print 128 (unary operator+ and - cast to (u)int64_t) - renamed processor/lr35902 to processor/sm83; after the Sharp SM83 CPU core [gekkio discovered the name] - a few bugfixes to the TLCS900H CPU core - completed the disassembler for the TLCS900H core As a result of reverting most of the inline if stuff, I guess the testing priority has been reduced. Which is probably a good thing, considering I seem to have a smaller pool of testers these days. Indeed, the TLCS900H core has ended up at 131KiB compared to the M68000 core at 128KiB. So it's now the largest CPU core in all of higan. It's even more ridiculous because the M68000 core would ordinarily be quite a bit smaller, had I not gone overboard with the extreme templating to reduce instruction decoding overhead (you kind of have to do this for RISC CPUs, and the inverted design of the TLCS900H kind of makes it infeasible to do the same there.) This CPU core is bound to have dozens of extremely difficult CPU bugs, and there's no easy way for me to test them. I would greatly appreciate any help in looking over the core for bugs. A fresh pair of eyes to spot a mistake could save me up to several days of tedious debugging work. The core still isn't ready to actually be tested: I have to hook up cartridge loading, a memory bus, interrupts, timers, and the micro DMA controller before it's likely that anything happens at all.
2019-01-19 01:34:17 +00:00
inline auto operator-() const { return Natural<>{-(uint64_t)data}; }
Update to v106r77 release. byuu says: So this turned out to be a rather unproductive ten-hour rabbit hole, but ... I reworked nall/primitives.hpp a lot. And because the changes are massive, testing of this WIP for regressions is critically important. I really can't stress that enough, we're almost certainly going to have some hidden regressions here ... We now have a nall/primitives/ subfolder that splits up the classes into manageable components. The bit-field support is now shared between both Natural and Integer. All of the assignment operator overloads are now templated and take references instead of values. Things like the GSU::Register class are non-copyable on account of the function<> object inside of it, and previously only operator= would work with classes like that. The big change is nall/primitives/operators.hpp, which is a really elaborate system to compute the minimum number of bits needed for any operation, and to return a Natural<T> or Integer<T> when one or both of the arguments are such a type. Unfortunately, it doesn't really work yet ... Kirby's Dream Land 3 breaks if we include operators.hpp. Zelda 3 runs fine with this, but I had to make a huge amount of core changes, including introducing a new ternary(bool, lhs, rhs) function to nall/algorithm to get past Natural<X> and Natural<Y> not being equivalent (is_integral types get a special exemption to ternary ?: type equivalence, yet it's impossible to simulate with our own classes, which is bullshit.) The horrifying part is that ternary() will evaluate both lhs and rhs, unlike ?: I converted some of the functions to test ? uint(x) : uint(y), and others to ternary(test, x, y) ... I don't have a strong preference either way yet. But the part where things may have gotten broken is in the changes to where ternary() was placed. Some cases like in the GBA PPU renderer, it was rather unclear the order of evaluations, so I may have made a mistake somewhere. So again, please please test this if you can. Or even better, look over the diff. Longer-term, I'd really like the enable nall/primitives/operators.hpp, but right now I'm not sure why Kirby's Dream Land 3 is breaking. Help would be appreciated, but ... it's gonna be really complex and difficult to debug, so I'm probably gonna be on my own here ... sigh.
2019-01-13 06:25:14 +00:00
#define lhs data
#define rhs value
template<typename T> inline auto& operator =(const T& value) { lhs = mask( rhs); return *this; }
template<typename T> inline auto& operator *=(const T& value) { lhs = mask(lhs * rhs); return *this; }
template<typename T> inline auto& operator /=(const T& value) { lhs = mask(lhs / rhs); return *this; }
template<typename T> inline auto& operator %=(const T& value) { lhs = mask(lhs % rhs); return *this; }
template<typename T> inline auto& operator +=(const T& value) { lhs = mask(lhs + rhs); return *this; }
template<typename T> inline auto& operator -=(const T& value) { lhs = mask(lhs - rhs); return *this; }
template<typename T> inline auto& operator<<=(const T& value) { lhs = mask(lhs << rhs); return *this; }
template<typename T> inline auto& operator>>=(const T& value) { lhs = mask(lhs >> rhs); return *this; }
template<typename T> inline auto& operator &=(const T& value) { lhs = mask(lhs & rhs); return *this; }
template<typename T> inline auto& operator ^=(const T& value) { lhs = mask(lhs ^ rhs); return *this; }
template<typename T> inline auto& operator |=(const T& value) { lhs = mask(lhs | rhs); return *this; }
#undef lhs
#undef rhs
Update to v106r83 release. byuu says: Changelog: - reverted nall/inline-if.hpp usage for now, since the nall/primitives.hpp math operators still cast to (u)int64_t - improved nall/primitives.hpp more; integer8 x = -128; print(-x) will now print 128 (unary operator+ and - cast to (u)int64_t) - renamed processor/lr35902 to processor/sm83; after the Sharp SM83 CPU core [gekkio discovered the name] - a few bugfixes to the TLCS900H CPU core - completed the disassembler for the TLCS900H core As a result of reverting most of the inline if stuff, I guess the testing priority has been reduced. Which is probably a good thing, considering I seem to have a smaller pool of testers these days. Indeed, the TLCS900H core has ended up at 131KiB compared to the M68000 core at 128KiB. So it's now the largest CPU core in all of higan. It's even more ridiculous because the M68000 core would ordinarily be quite a bit smaller, had I not gone overboard with the extreme templating to reduce instruction decoding overhead (you kind of have to do this for RISC CPUs, and the inverted design of the TLCS900H kind of makes it infeasible to do the same there.) This CPU core is bound to have dozens of extremely difficult CPU bugs, and there's no easy way for me to test them. I would greatly appreciate any help in looking over the core for bugs. A fresh pair of eyes to spot a mistake could save me up to several days of tedious debugging work. The core still isn't ready to actually be tested: I have to hook up cartridge loading, a memory bus, interrupts, timers, and the micro DMA controller before it's likely that anything happens at all.
2019-01-19 01:34:17 +00:00
//warning: this does not and cannot short-circuit; value is always evaluated
template<typename T> inline auto orElse(const T& value) { return Natural<>{data ? data : value}; }
inline auto bits(int lo, int hi) -> BitRange<Precision> { return {(utype&)data, lo, hi}; }
inline auto bit(int index) -> BitRange<Precision> { return {(utype&)data, index, index}; }
inline auto byte(int index) -> BitRange<Precision> { return {(utype&)data, index * 8 + 0, index * 8 + 7}; }
Update to v106r77 release. byuu says: So this turned out to be a rather unproductive ten-hour rabbit hole, but ... I reworked nall/primitives.hpp a lot. And because the changes are massive, testing of this WIP for regressions is critically important. I really can't stress that enough, we're almost certainly going to have some hidden regressions here ... We now have a nall/primitives/ subfolder that splits up the classes into manageable components. The bit-field support is now shared between both Natural and Integer. All of the assignment operator overloads are now templated and take references instead of values. Things like the GSU::Register class are non-copyable on account of the function<> object inside of it, and previously only operator= would work with classes like that. The big change is nall/primitives/operators.hpp, which is a really elaborate system to compute the minimum number of bits needed for any operation, and to return a Natural<T> or Integer<T> when one or both of the arguments are such a type. Unfortunately, it doesn't really work yet ... Kirby's Dream Land 3 breaks if we include operators.hpp. Zelda 3 runs fine with this, but I had to make a huge amount of core changes, including introducing a new ternary(bool, lhs, rhs) function to nall/algorithm to get past Natural<X> and Natural<Y> not being equivalent (is_integral types get a special exemption to ternary ?: type equivalence, yet it's impossible to simulate with our own classes, which is bullshit.) The horrifying part is that ternary() will evaluate both lhs and rhs, unlike ?: I converted some of the functions to test ? uint(x) : uint(y), and others to ternary(test, x, y) ... I don't have a strong preference either way yet. But the part where things may have gotten broken is in the changes to where ternary() was placed. Some cases like in the GBA PPU renderer, it was rather unclear the order of evaluations, so I may have made a mistake somewhere. So again, please please test this if you can. Or even better, look over the diff. Longer-term, I'd really like the enable nall/primitives/operators.hpp, but right now I'm not sure why Kirby's Dream Land 3 is breaking. Help would be appreciated, but ... it's gonna be really complex and difficult to debug, so I'm probably gonna be on my own here ... sigh.
2019-01-13 06:25:14 +00:00
inline auto bits(int lo, int hi) const -> const BitRange<Precision> { return {(utype&)data, lo, hi}; }
inline auto bit(int index) const -> const BitRange<Precision> { return {(utype&)data, index, index}; }
inline auto byte(int index) const -> const BitRange<Precision> { return {(utype&)data, index * 8 + 0, index * 8 + 7}; }
Update to v106r77 release. byuu says: So this turned out to be a rather unproductive ten-hour rabbit hole, but ... I reworked nall/primitives.hpp a lot. And because the changes are massive, testing of this WIP for regressions is critically important. I really can't stress that enough, we're almost certainly going to have some hidden regressions here ... We now have a nall/primitives/ subfolder that splits up the classes into manageable components. The bit-field support is now shared between both Natural and Integer. All of the assignment operator overloads are now templated and take references instead of values. Things like the GSU::Register class are non-copyable on account of the function<> object inside of it, and previously only operator= would work with classes like that. The big change is nall/primitives/operators.hpp, which is a really elaborate system to compute the minimum number of bits needed for any operation, and to return a Natural<T> or Integer<T> when one or both of the arguments are such a type. Unfortunately, it doesn't really work yet ... Kirby's Dream Land 3 breaks if we include operators.hpp. Zelda 3 runs fine with this, but I had to make a huge amount of core changes, including introducing a new ternary(bool, lhs, rhs) function to nall/algorithm to get past Natural<X> and Natural<Y> not being equivalent (is_integral types get a special exemption to ternary ?: type equivalence, yet it's impossible to simulate with our own classes, which is bullshit.) The horrifying part is that ternary() will evaluate both lhs and rhs, unlike ?: I converted some of the functions to test ? uint(x) : uint(y), and others to ternary(test, x, y) ... I don't have a strong preference either way yet. But the part where things may have gotten broken is in the changes to where ternary() was placed. Some cases like in the GBA PPU renderer, it was rather unclear the order of evaluations, so I may have made a mistake somewhere. So again, please please test this if you can. Or even better, look over the diff. Longer-term, I'd really like the enable nall/primitives/operators.hpp, but right now I'm not sure why Kirby's Dream Land 3 is breaking. Help would be appreciated, but ... it's gonna be really complex and difficult to debug, so I'm probably gonna be on my own here ... sigh.
2019-01-13 06:25:14 +00:00
Update to v106r83 release. byuu says: Changelog: - reverted nall/inline-if.hpp usage for now, since the nall/primitives.hpp math operators still cast to (u)int64_t - improved nall/primitives.hpp more; integer8 x = -128; print(-x) will now print 128 (unary operator+ and - cast to (u)int64_t) - renamed processor/lr35902 to processor/sm83; after the Sharp SM83 CPU core [gekkio discovered the name] - a few bugfixes to the TLCS900H CPU core - completed the disassembler for the TLCS900H core As a result of reverting most of the inline if stuff, I guess the testing priority has been reduced. Which is probably a good thing, considering I seem to have a smaller pool of testers these days. Indeed, the TLCS900H core has ended up at 131KiB compared to the M68000 core at 128KiB. So it's now the largest CPU core in all of higan. It's even more ridiculous because the M68000 core would ordinarily be quite a bit smaller, had I not gone overboard with the extreme templating to reduce instruction decoding overhead (you kind of have to do this for RISC CPUs, and the inverted design of the TLCS900H kind of makes it infeasible to do the same there.) This CPU core is bound to have dozens of extremely difficult CPU bugs, and there's no easy way for me to test them. I would greatly appreciate any help in looking over the core for bugs. A fresh pair of eyes to spot a mistake could save me up to several days of tedious debugging work. The core still isn't ready to actually be tested: I have to hook up cartridge loading, a memory bus, interrupts, timers, and the micro DMA controller before it's likely that anything happens at all.
2019-01-19 01:34:17 +00:00
inline auto slice(int index) const { return Natural<>{bit(index)}; }
inline auto slice(int lo, int hi) const { return Natural<>{bits(lo, hi)}; }
inline auto clamp(uint bits) {
Update to v106r83 release. byuu says: Changelog: - reverted nall/inline-if.hpp usage for now, since the nall/primitives.hpp math operators still cast to (u)int64_t - improved nall/primitives.hpp more; integer8 x = -128; print(-x) will now print 128 (unary operator+ and - cast to (u)int64_t) - renamed processor/lr35902 to processor/sm83; after the Sharp SM83 CPU core [gekkio discovered the name] - a few bugfixes to the TLCS900H CPU core - completed the disassembler for the TLCS900H core As a result of reverting most of the inline if stuff, I guess the testing priority has been reduced. Which is probably a good thing, considering I seem to have a smaller pool of testers these days. Indeed, the TLCS900H core has ended up at 131KiB compared to the M68000 core at 128KiB. So it's now the largest CPU core in all of higan. It's even more ridiculous because the M68000 core would ordinarily be quite a bit smaller, had I not gone overboard with the extreme templating to reduce instruction decoding overhead (you kind of have to do this for RISC CPUs, and the inverted design of the TLCS900H kind of makes it infeasible to do the same there.) This CPU core is bound to have dozens of extremely difficult CPU bugs, and there's no easy way for me to test them. I would greatly appreciate any help in looking over the core for bugs. A fresh pair of eyes to spot a mistake could save me up to several days of tedious debugging work. The core still isn't ready to actually be tested: I have to hook up cartridge loading, a memory bus, interrupts, timers, and the micro DMA controller before it's likely that anything happens at all.
2019-01-19 01:34:17 +00:00
const uint64_t b = 1ull << (bits - 1);
const uint64_t m = b * 2 - 1;
return Natural<>{data < m ? data : m};
Update to v106r77 release. byuu says: So this turned out to be a rather unproductive ten-hour rabbit hole, but ... I reworked nall/primitives.hpp a lot. And because the changes are massive, testing of this WIP for regressions is critically important. I really can't stress that enough, we're almost certainly going to have some hidden regressions here ... We now have a nall/primitives/ subfolder that splits up the classes into manageable components. The bit-field support is now shared between both Natural and Integer. All of the assignment operator overloads are now templated and take references instead of values. Things like the GSU::Register class are non-copyable on account of the function<> object inside of it, and previously only operator= would work with classes like that. The big change is nall/primitives/operators.hpp, which is a really elaborate system to compute the minimum number of bits needed for any operation, and to return a Natural<T> or Integer<T> when one or both of the arguments are such a type. Unfortunately, it doesn't really work yet ... Kirby's Dream Land 3 breaks if we include operators.hpp. Zelda 3 runs fine with this, but I had to make a huge amount of core changes, including introducing a new ternary(bool, lhs, rhs) function to nall/algorithm to get past Natural<X> and Natural<Y> not being equivalent (is_integral types get a special exemption to ternary ?: type equivalence, yet it's impossible to simulate with our own classes, which is bullshit.) The horrifying part is that ternary() will evaluate both lhs and rhs, unlike ?: I converted some of the functions to test ? uint(x) : uint(y), and others to ternary(test, x, y) ... I don't have a strong preference either way yet. But the part where things may have gotten broken is in the changes to where ternary() was placed. Some cases like in the GBA PPU renderer, it was rather unclear the order of evaluations, so I may have made a mistake somewhere. So again, please please test this if you can. Or even better, look over the diff. Longer-term, I'd really like the enable nall/primitives/operators.hpp, but right now I'm not sure why Kirby's Dream Land 3 is breaking. Help would be appreciated, but ... it's gonna be really complex and difficult to debug, so I'm probably gonna be on my own here ... sigh.
2019-01-13 06:25:14 +00:00
}
inline auto clip(uint bits) {
Update to v106r83 release. byuu says: Changelog: - reverted nall/inline-if.hpp usage for now, since the nall/primitives.hpp math operators still cast to (u)int64_t - improved nall/primitives.hpp more; integer8 x = -128; print(-x) will now print 128 (unary operator+ and - cast to (u)int64_t) - renamed processor/lr35902 to processor/sm83; after the Sharp SM83 CPU core [gekkio discovered the name] - a few bugfixes to the TLCS900H CPU core - completed the disassembler for the TLCS900H core As a result of reverting most of the inline if stuff, I guess the testing priority has been reduced. Which is probably a good thing, considering I seem to have a smaller pool of testers these days. Indeed, the TLCS900H core has ended up at 131KiB compared to the M68000 core at 128KiB. So it's now the largest CPU core in all of higan. It's even more ridiculous because the M68000 core would ordinarily be quite a bit smaller, had I not gone overboard with the extreme templating to reduce instruction decoding overhead (you kind of have to do this for RISC CPUs, and the inverted design of the TLCS900H kind of makes it infeasible to do the same there.) This CPU core is bound to have dozens of extremely difficult CPU bugs, and there's no easy way for me to test them. I would greatly appreciate any help in looking over the core for bugs. A fresh pair of eyes to spot a mistake could save me up to several days of tedious debugging work. The core still isn't ready to actually be tested: I have to hook up cartridge loading, a memory bus, interrupts, timers, and the micro DMA controller before it's likely that anything happens at all.
2019-01-19 01:34:17 +00:00
const uint64_t b = 1ull << (bits - 1);
const uint64_t m = b * 2 - 1;
return Natural<>{data & m};
Update to v106r77 release. byuu says: So this turned out to be a rather unproductive ten-hour rabbit hole, but ... I reworked nall/primitives.hpp a lot. And because the changes are massive, testing of this WIP for regressions is critically important. I really can't stress that enough, we're almost certainly going to have some hidden regressions here ... We now have a nall/primitives/ subfolder that splits up the classes into manageable components. The bit-field support is now shared between both Natural and Integer. All of the assignment operator overloads are now templated and take references instead of values. Things like the GSU::Register class are non-copyable on account of the function<> object inside of it, and previously only operator= would work with classes like that. The big change is nall/primitives/operators.hpp, which is a really elaborate system to compute the minimum number of bits needed for any operation, and to return a Natural<T> or Integer<T> when one or both of the arguments are such a type. Unfortunately, it doesn't really work yet ... Kirby's Dream Land 3 breaks if we include operators.hpp. Zelda 3 runs fine with this, but I had to make a huge amount of core changes, including introducing a new ternary(bool, lhs, rhs) function to nall/algorithm to get past Natural<X> and Natural<Y> not being equivalent (is_integral types get a special exemption to ternary ?: type equivalence, yet it's impossible to simulate with our own classes, which is bullshit.) The horrifying part is that ternary() will evaluate both lhs and rhs, unlike ?: I converted some of the functions to test ? uint(x) : uint(y), and others to ternary(test, x, y) ... I don't have a strong preference either way yet. But the part where things may have gotten broken is in the changes to where ternary() was placed. Some cases like in the GBA PPU renderer, it was rather unclear the order of evaluations, so I may have made a mistake somewhere. So again, please please test this if you can. Or even better, look over the diff. Longer-term, I'd really like the enable nall/primitives/operators.hpp, but right now I'm not sure why Kirby's Dream Land 3 is breaking. Help would be appreciated, but ... it's gonna be really complex and difficult to debug, so I'm probably gonna be on my own here ... sigh.
2019-01-13 06:25:14 +00:00
}
inline auto serialize(serializer& s) { s(data); }
inline auto integer() const -> Integer<Precision>;
Update to v106r77 release. byuu says: So this turned out to be a rather unproductive ten-hour rabbit hole, but ... I reworked nall/primitives.hpp a lot. And because the changes are massive, testing of this WIP for regressions is critically important. I really can't stress that enough, we're almost certainly going to have some hidden regressions here ... We now have a nall/primitives/ subfolder that splits up the classes into manageable components. The bit-field support is now shared between both Natural and Integer. All of the assignment operator overloads are now templated and take references instead of values. Things like the GSU::Register class are non-copyable on account of the function<> object inside of it, and previously only operator= would work with classes like that. The big change is nall/primitives/operators.hpp, which is a really elaborate system to compute the minimum number of bits needed for any operation, and to return a Natural<T> or Integer<T> when one or both of the arguments are such a type. Unfortunately, it doesn't really work yet ... Kirby's Dream Land 3 breaks if we include operators.hpp. Zelda 3 runs fine with this, but I had to make a huge amount of core changes, including introducing a new ternary(bool, lhs, rhs) function to nall/algorithm to get past Natural<X> and Natural<Y> not being equivalent (is_integral types get a special exemption to ternary ?: type equivalence, yet it's impossible to simulate with our own classes, which is bullshit.) The horrifying part is that ternary() will evaluate both lhs and rhs, unlike ?: I converted some of the functions to test ? uint(x) : uint(y), and others to ternary(test, x, y) ... I don't have a strong preference either way yet. But the part where things may have gotten broken is in the changes to where ternary() was placed. Some cases like in the GBA PPU renderer, it was rather unclear the order of evaluations, so I may have made a mistake somewhere. So again, please please test this if you can. Or even better, look over the diff. Longer-term, I'd really like the enable nall/primitives/operators.hpp, but right now I'm not sure why Kirby's Dream Land 3 is breaking. Help would be appreciated, but ... it's gonna be really complex and difficult to debug, so I'm probably gonna be on my own here ... sigh.
2019-01-13 06:25:14 +00:00
private:
inline auto mask(utype value) const -> utype {
Update to v106r77 release. byuu says: So this turned out to be a rather unproductive ten-hour rabbit hole, but ... I reworked nall/primitives.hpp a lot. And because the changes are massive, testing of this WIP for regressions is critically important. I really can't stress that enough, we're almost certainly going to have some hidden regressions here ... We now have a nall/primitives/ subfolder that splits up the classes into manageable components. The bit-field support is now shared between both Natural and Integer. All of the assignment operator overloads are now templated and take references instead of values. Things like the GSU::Register class are non-copyable on account of the function<> object inside of it, and previously only operator= would work with classes like that. The big change is nall/primitives/operators.hpp, which is a really elaborate system to compute the minimum number of bits needed for any operation, and to return a Natural<T> or Integer<T> when one or both of the arguments are such a type. Unfortunately, it doesn't really work yet ... Kirby's Dream Land 3 breaks if we include operators.hpp. Zelda 3 runs fine with this, but I had to make a huge amount of core changes, including introducing a new ternary(bool, lhs, rhs) function to nall/algorithm to get past Natural<X> and Natural<Y> not being equivalent (is_integral types get a special exemption to ternary ?: type equivalence, yet it's impossible to simulate with our own classes, which is bullshit.) The horrifying part is that ternary() will evaluate both lhs and rhs, unlike ?: I converted some of the functions to test ? uint(x) : uint(y), and others to ternary(test, x, y) ... I don't have a strong preference either way yet. But the part where things may have gotten broken is in the changes to where ternary() was placed. Some cases like in the GBA PPU renderer, it was rather unclear the order of evaluations, so I may have made a mistake somewhere. So again, please please test this if you can. Or even better, look over the diff. Longer-term, I'd really like the enable nall/primitives/operators.hpp, but right now I'm not sure why Kirby's Dream Land 3 is breaking. Help would be appreciated, but ... it's gonna be really complex and difficult to debug, so I'm probably gonna be on my own here ... sigh.
2019-01-13 06:25:14 +00:00
return value & mask();
}
utype data;
Update to v106r77 release. byuu says: So this turned out to be a rather unproductive ten-hour rabbit hole, but ... I reworked nall/primitives.hpp a lot. And because the changes are massive, testing of this WIP for regressions is critically important. I really can't stress that enough, we're almost certainly going to have some hidden regressions here ... We now have a nall/primitives/ subfolder that splits up the classes into manageable components. The bit-field support is now shared between both Natural and Integer. All of the assignment operator overloads are now templated and take references instead of values. Things like the GSU::Register class are non-copyable on account of the function<> object inside of it, and previously only operator= would work with classes like that. The big change is nall/primitives/operators.hpp, which is a really elaborate system to compute the minimum number of bits needed for any operation, and to return a Natural<T> or Integer<T> when one or both of the arguments are such a type. Unfortunately, it doesn't really work yet ... Kirby's Dream Land 3 breaks if we include operators.hpp. Zelda 3 runs fine with this, but I had to make a huge amount of core changes, including introducing a new ternary(bool, lhs, rhs) function to nall/algorithm to get past Natural<X> and Natural<Y> not being equivalent (is_integral types get a special exemption to ternary ?: type equivalence, yet it's impossible to simulate with our own classes, which is bullshit.) The horrifying part is that ternary() will evaluate both lhs and rhs, unlike ?: I converted some of the functions to test ? uint(x) : uint(y), and others to ternary(test, x, y) ... I don't have a strong preference either way yet. But the part where things may have gotten broken is in the changes to where ternary() was placed. Some cases like in the GBA PPU renderer, it was rather unclear the order of evaluations, so I may have made a mistake somewhere. So again, please please test this if you can. Or even better, look over the diff. Longer-term, I'd really like the enable nall/primitives/operators.hpp, but right now I'm not sure why Kirby's Dream Land 3 is breaking. Help would be appreciated, but ... it's gonna be really complex and difficult to debug, so I'm probably gonna be on my own here ... sigh.
2019-01-13 06:25:14 +00:00
};
#define lhs (uint64_t)l
Update to v106r83 release. byuu says: Changelog: - reverted nall/inline-if.hpp usage for now, since the nall/primitives.hpp math operators still cast to (u)int64_t - improved nall/primitives.hpp more; integer8 x = -128; print(-x) will now print 128 (unary operator+ and - cast to (u)int64_t) - renamed processor/lr35902 to processor/sm83; after the Sharp SM83 CPU core [gekkio discovered the name] - a few bugfixes to the TLCS900H CPU core - completed the disassembler for the TLCS900H core As a result of reverting most of the inline if stuff, I guess the testing priority has been reduced. Which is probably a good thing, considering I seem to have a smaller pool of testers these days. Indeed, the TLCS900H core has ended up at 131KiB compared to the M68000 core at 128KiB. So it's now the largest CPU core in all of higan. It's even more ridiculous because the M68000 core would ordinarily be quite a bit smaller, had I not gone overboard with the extreme templating to reduce instruction decoding overhead (you kind of have to do this for RISC CPUs, and the inverted design of the TLCS900H kind of makes it infeasible to do the same there.) This CPU core is bound to have dozens of extremely difficult CPU bugs, and there's no easy way for me to test them. I would greatly appreciate any help in looking over the core for bugs. A fresh pair of eyes to spot a mistake could save me up to several days of tedious debugging work. The core still isn't ready to actually be tested: I have to hook up cartridge loading, a memory bus, interrupts, timers, and the micro DMA controller before it's likely that anything happens at all.
2019-01-19 01:34:17 +00:00
#define rhs r
template<int LHS, int RHS> inline auto operator *(Natural<LHS> l, Natural<RHS> r) { return Natural{lhs * rhs}; }
template<int LHS, int RHS> inline auto operator /(Natural<LHS> l, Natural<RHS> r) { return Natural{lhs / rhs}; }
template<int LHS, int RHS> inline auto operator %(Natural<LHS> l, Natural<RHS> r) { return Natural{lhs % rhs}; }
template<int LHS, int RHS> inline auto operator +(Natural<LHS> l, Natural<RHS> r) { return Natural{lhs + rhs}; }
template<int LHS, int RHS> inline auto operator -(Natural<LHS> l, Natural<RHS> r) { return Natural{lhs - rhs}; }
template<int LHS, int RHS> inline auto operator<<(Natural<LHS> l, Natural<RHS> r) { return Natural{lhs << rhs}; }
template<int LHS, int RHS> inline auto operator>>(Natural<LHS> l, Natural<RHS> r) { return Natural{lhs >> rhs}; }
template<int LHS, int RHS> inline auto operator &(Natural<LHS> l, Natural<RHS> r) { return Natural{lhs & rhs}; }
template<int LHS, int RHS> inline auto operator ^(Natural<LHS> l, Natural<RHS> r) { return Natural{lhs ^ rhs}; }
template<int LHS, int RHS> inline auto operator |(Natural<LHS> l, Natural<RHS> r) { return Natural{lhs | rhs}; }
Update to v106r79 release. byuu says: This WIP is just work on nall/primitives ... Basically, I'm coming to the conclusion that it's just not practical to try and make Natural/Integer implicitly castable to primitive signed and unsigned integers. C++ just has too many edge cases there. I also want to get away from the problem of C++ deciding that all math operations return 32-bit values, unless one of the parameters is 64-bit, in which case you get a 64-bit value. You know, so things like array[-1] won't end up accessing the 4 billionth element of the array. It's nice to be fancy and minimally size operations (eg 32-bit+32-bit = 33-bit), but it's just too unintuitive. I think all Natural<X>+Natural<Y> expessions should result in a Natural<64> (eg natural) type. nall/primitives/operators.hpp has been removed, and new Natural<>Natural / Integer<>Integer casts exist. My feeling is that signed and unsigned types should not be implicitly convertible where data loss can occur. In the future, I think an integer8*natural8 is fine to return an integer64, and the bitwise operators are probably all fine between the two types. I could probably add (Integer,Natural)+Boolean conversions as well. To simplify expressions, there are new user-defined literals for _b (boolean), _n (natural), _i (integer), _r (real), _n# (eg _n8), _i# (eg _i8), _r# (eg _r32), and _s (nall::string). In the long-term, my intention is to make the conversion and cast constructors explicit for primitive types, but obviously that'll shatter most of higan, so for now that won't be the case. Something I can do in the future is allow implicit conversion and casting to (u)int64_t. That may be a nice balance.
2019-01-15 04:33:20 +00:00
#undef lhs
#undef rhs
Update to v106r77 release. byuu says: So this turned out to be a rather unproductive ten-hour rabbit hole, but ... I reworked nall/primitives.hpp a lot. And because the changes are massive, testing of this WIP for regressions is critically important. I really can't stress that enough, we're almost certainly going to have some hidden regressions here ... We now have a nall/primitives/ subfolder that splits up the classes into manageable components. The bit-field support is now shared between both Natural and Integer. All of the assignment operator overloads are now templated and take references instead of values. Things like the GSU::Register class are non-copyable on account of the function<> object inside of it, and previously only operator= would work with classes like that. The big change is nall/primitives/operators.hpp, which is a really elaborate system to compute the minimum number of bits needed for any operation, and to return a Natural<T> or Integer<T> when one or both of the arguments are such a type. Unfortunately, it doesn't really work yet ... Kirby's Dream Land 3 breaks if we include operators.hpp. Zelda 3 runs fine with this, but I had to make a huge amount of core changes, including introducing a new ternary(bool, lhs, rhs) function to nall/algorithm to get past Natural<X> and Natural<Y> not being equivalent (is_integral types get a special exemption to ternary ?: type equivalence, yet it's impossible to simulate with our own classes, which is bullshit.) The horrifying part is that ternary() will evaluate both lhs and rhs, unlike ?: I converted some of the functions to test ? uint(x) : uint(y), and others to ternary(test, x, y) ... I don't have a strong preference either way yet. But the part where things may have gotten broken is in the changes to where ternary() was placed. Some cases like in the GBA PPU renderer, it was rather unclear the order of evaluations, so I may have made a mistake somewhere. So again, please please test this if you can. Or even better, look over the diff. Longer-term, I'd really like the enable nall/primitives/operators.hpp, but right now I'm not sure why Kirby's Dream Land 3 is breaking. Help would be appreciated, but ... it's gonna be really complex and difficult to debug, so I'm probably gonna be on my own here ... sigh.
2019-01-13 06:25:14 +00:00
}