- Jul 23, 2018
- Jul 22, 2018
-
-
Subv authored
-
- Jul 21, 2018
-
-
Subv authored
Note that there's currently a dynarmic bug preventing this register from being written.
-
- Jul 20, 2018
-
-
Lioncash authored
Makes the thread status strongly typed, so implicit conversions can't happen. It also makes it easier to catch mistakes at compile time.
-
- Jul 19, 2018
-
-
Lioncash authored
This introduces a slightly more generic variant of WriteBuffer(). Notably, this variant doesn't constrain the arguments to only accepting std::vector instances. It accepts whatever adheres to the ContiguousContainer concept in the C++ standard library. This essentially means, std::array, std::string, and std::vector can be used directly with this interface. The interface no longer forces you to solely use containers that dynamically allocate. To ensure our overloads play nice with one another, we only enable the container-based WriteBuffer if the argument is not a pointer, otherwise we fall back to the pointer-based one.
-
Lioncash authored
The reason this would never be true is that ideal_processor is a u8 and THREADPROCESSORID_DEFAULT is an s32. In this case, it boils down to how arithmetic conversions are performed before performing the comparison. If an unsigned value has a lesser conversion rank (aka smaller size) than the signed type being compared, then the unsigned value is promoted to the signed value (i.e. u8 -> s32 happens before the comparison). No sign-extension occurs here either. An alternative phrasing: Say we have a variable named core and it's given a value of -2. u8 core = -2; This becomes 254 due to the lack of sign. During integral promotion to the signed type, this still remains as 254, and therefore the condition will always be true, because no matter what value the u8 is given it will never be -2 in terms of 32 bits. Now, if one type was a s32 and one was a u32, this would be entirely different, since they have the same bit width (and the signed type would be converted to unsigned instead of the other way around) but would still have its representation preserved in terms of bits, allowing the comparison to be false in some cases, as opposed to being true all the time. --- We also get rid of two signed/unsigned comparison warnings while we're at it.
-
Lioncash authored
Previously, the buffer_index parameter was unused, causing all writes to use the buffer index of zero, which is not necessarily what is wanted all the time. Thankfully, all current usages don't use a buffer index other than zero, so this just prevents a bug before it has a chance to spring.
-
- Jul 18, 2018
-
-
Lioncash authored
Without these, this would perform concatenation, which is definitely not what we want here.
-
Lioncash authored
Avoids pointless copies
-
Lioncash authored
This would result in a lot of allocations and related object construction, just to toss it all away immediately after the call. These are definitely not intentional, and it was intended that all of these should have been accessing the static function GetInstance() through the name itself, not constructed instances.
- Jul 17, 2018
-
-
bunnei authored
-
Michael Scire authored
-
- Jul 16, 2018
-
-
MerryMage authored
-
- Jul 14, 2018
-
-
David Marcec authored
-
- Jul 03, 2018
-
-
James Rowe authored
-
James Rowe authored
-
- Jun 22, 2018
-
-
mailwl authored
prevent yuzu crash, if games, like Axiom Verge, trying to read 0 bytes from file
-
Michael Scire authored
-
Michael Scire authored
-
Michael Scire authored
-
Michael Scire authored
-
- Jun 21, 2018
-
-
Michael Scire authored
-
Michael Scire authored
-
Michael Scire authored
-
Michael Scire authored
-
Michael Scire authored
-
- Jun 20, 2018
-
-
Subv authored
-
- Jun 18, 2018
-
-
Jules Blok authored
-
- Jun 02, 2018
-
-
Subv authored
Kernel/Threads: A thread waking up by timeout from a WaitProcessWideKey may already have an assigned lock owner. This situation may happen like so: Thread 1 with low priority calls WaitProcessWideKey with timeout. Thread 2 with high priority calls WaitProcessWideKey without timeout. Thread 3 calls SignalProcessWideKey - Thread 2 acquires the lock and awakens. - Thread 1 can't acquire the lock and is put to sleep with the lock owner being Thread 2. Thread 1's timeout expires, with the lock owner still being set to Thread 2.
-
- May 31, 2018
- May 30, 2018
-
-
Subv authored
-
- May 26, 2018
-
-
greggameplayer authored
* add some InfoType * correct OpenApplicationProxy cmd number * add IDisplayController functions * fix clang-format * add more system languages
-
- May 20, 2018
-
-
Subv authored
A thread may own multiple mutexes at the same time, and only release one of them while other threads are waiting for the other mutexes.
-
- May 19, 2018
- May 17, 2018
-
-
David Marcec authored
-