- Sep 14, 2018
- Sep 12, 2018
-
-
Lioncash authored
This is what the kernel does for an out-of-range processor ID.
-
Lioncash authored
-
Lioncash authored
While unlikely, it does avoid constructing a std::string and unnecessarily calling into the memory code if a game or executable decides to be really silly about their logging.
-
Lioncash authored
This should be a u64 to represent size.
-
- Sep 02, 2018
-
-
Lioncash authored
Now that we have a class representing the kernel in some capacity, we now have a place to put the named port map, so we move it over and get rid of another piece of global state within the core.
-
- Aug 31, 2018
-
-
Lioncash authored
The follow-up to e2457418, which replaces most of the includes in the core header with forward declarations. This makes it so that if any of the headers the core header was previously including change, then no one will need to rebuild the bulk of the core, due to core.h being quite a prevalent inclusion. This should make turnaround for changes much faster for developers.
-
- Aug 29, 2018
-
-
Lioncash authored
As means to pave the way for getting rid of global state within core, This eliminates kernel global state by removing all globals. Instead this introduces a KernelCore class which acts as a kernel instance. This instance lives in the System class, which keeps its lifetime contained to the lifetime of the System class. This also forces the kernel types to actually interact with the main kernel instance itself instead of having transient kernel state placed all over several translation units, keeping everything together. It also has a nice consequence of making dependencies much more explicit. This also makes our initialization a tad bit more correct. Previously we were creating a kernel process before the actual kernel was initialized, which doesn't really make much sense. The KernelCore class itself follows the PImpl idiom, which allows keeping all the implementation details sealed away from everything else, which forces the use of the exposed API and allows us to avoid any unnecessary inclusions within the main kernel header.
-
- Aug 25, 2018
-
-
Lioncash authored
We already have the variable itself set up to perform this task, so we can just return its value from the currently executing process instead of always stubbing it to zero.
-
- Aug 15, 2018
-
-
Lioncash authored
Given if we hit here all is lost, we should probably be logging the break reason code and associated information to distinguish between the causes.
-
- Aug 13, 2018
-
-
Subv authored
The current core may have nothing to do with the core where the new thread was scheduled to run. In case it's the same core, then the following PrepareReshedule call will take care of that.
-
- Aug 12, 2018
-
-
Subv authored
Exit from AddMutexWaiter early if the thread is already waiting for a mutex owned by the owner thread. This accounts for the possibility of a thread that is waiting on a condition variable being awakened twice in a row. Also added more validation asserts. This should fix one of the random crashes in Breath Of The Wild.
-
- Aug 02, 2018
-
-
Lioncash authored
Makes our immutable state explicit.
-
- Jul 31, 2018
-
-
Lioncash authored
These source files were entirely unused throughout the rest of the codebase. This also has the benefit of getting rid of a global variable as well.
-
Lioncash authored
Removes unnecessary direct dependencies in some headers and also gets rid of indirect dependencies that were being relied on to be included.
-
- Jul 24, 2018
- Jul 22, 2018
-
-
Subv authored
-
- 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
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.
-
- Jul 03, 2018
-
-
James Rowe authored
-
James Rowe authored
-
- Jun 22, 2018
-
-
Michael Scire authored
-
Michael Scire authored
-
- Jun 21, 2018
-
-
Michael Scire authored
-
Michael Scire authored
-
Michael Scire authored
-
- Jun 20, 2018
-
-
Subv authored
-
- Jun 18, 2018
-
-
Jules Blok authored
-
- May 31, 2018
-
-
Subv authored
Also added some proper error handling.
-
- May 19, 2018
- May 10, 2018