Skip to content
Snippets Groups Projects
  1. Sep 14, 2018
  2. Sep 12, 2018
  3. Sep 02, 2018
  4. Aug 31, 2018
    • Lioncash's avatar
      core/core: Replace includes with forward declarations where applicable · 4a587b81
      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.
      4a587b81
  5. Aug 29, 2018
    • Lioncash's avatar
      kernel: Eliminate kernel global state · 0cbcd6ec
      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.
      0cbcd6ec
  6. Aug 25, 2018
  7. Aug 15, 2018
    • Lioncash's avatar
      kernel/svc: Log svcBreak parameters · 25d71454
      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.
      25d71454
  8. Aug 13, 2018
  9. Aug 12, 2018
    • Subv's avatar
      Kernel/Mutex: Don't duplicate threads in the mutex waiter list. · 5224cc49
      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.
      5224cc49
  10. Aug 02, 2018
  11. Jul 31, 2018
  12. Jul 24, 2018
  13. Jul 22, 2018
  14. Jul 20, 2018
  15. Jul 19, 2018
    • Lioncash's avatar
      svc: Correct always true assertion case in SetThreadCoreMask · b879fb84
      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.
      b879fb84
  16. Jul 03, 2018
  17. Jun 22, 2018
  18. Jun 21, 2018
  19. Jun 20, 2018
  20. Jun 18, 2018
  21. May 31, 2018
  22. May 19, 2018
  23. May 10, 2018
Loading