eden-emu/eden - eden - InfoTonic

13000 Commits

99 Branches

19 Tags

167 MiB

Tree: 33df906815

Commit Graph

Author	SHA1	Message	Date
Lioncash	567b7de124	core/cpu_core_manager: Create threads separately from initialization. Our initialization process is a little wonky than one would expect when it comes to code flow. We initialize the CPU last, as opposed to hardware, where the CPU obviously needs to be first, otherwise nothing else would work, and we have code that adds checks to get around this. For example, in the page table setting code, we check to see if the system is turned on before we even notify the CPU instances of a page table switch. This results in dead code (at the moment), because the only time a page table switch will occur is when the system is not running, preventing the emulated CPU instances from being notified of a page table switch in a convenient manner (technically the code path could be taken, but we don't emulate the process creation svc handlers yet). This moves the threads creation into its own member function of the core manager and restores a little order (and predictability) to our initialization process. Previously, in the multi-threaded cases, we'd kick off several threads before even the main kernel process was created and ready to execute (gross!). Now the initialization process is like so: Initialization: 1. Timers 2. CPU 3. Kernel 4. Filesystem stuff (kind of gross, but can be amended trivially) 5. Applet stuff (ditto in terms of being kind of gross) 6. Main process (will be moved into the loading step in a following change) 7. Telemetry (this should be initialized last in the future). 8. Services (4 and 5 should ideally be alongside this). 9. GDB (gross. Uses namespace scope state. Needs to be refactored into a class or booted altogether). 10. Renderer 11. GPU (will also have its threads created in a separate step in a following change). Which... isn't ideal per-se, however getting rid of the wonky intertwining of CPU state initialization out of this mix gets rid of most of the footguns when it comes to our initialization process.	7 years ago
Lioncash	7128bf879f	core: Relocate CPU core management to its own class Keeps the CPU-specific behavior from being spread throughout the main System class. This will also act as the home to contain member functions that perform operations on all cores. The reason for this being that the following pattern is sort of prevalent throughout sections of the codebase: If clearing the instruction cache for all 4 cores is necessary: Core::System::GetInstance().ArmInterface(0).ClearInstructionCache(); Core::System::GetInstance().ArmInterface(1).ClearInstructionCache(); Core::System::GetInstance().ArmInterface(2).ClearInstructionCache(); Core::System::GetInstance().ArmInterface(3).ClearInstructionCache(); This is kind of... well, silly to copy around whenever it's needed. especially when it can be reduced down to a single line. This change also puts the basics in place to begin "ungrafting" all of the forwarding member functions from the System class that are used to access CPU state or invoke CPU-specific behavior. As such, this change itself makes no changes to the direct external interface of System. This will be covered by another changeset.	7 years ago

Author

SHA1

Message

Date

Lioncash

567b7de124

core/cpu_core_manager: Create threads separately from initialization.

Our initialization process is a little wonky than one would expect when
it comes to code flow. We initialize the CPU last, as opposed to
hardware, where the CPU obviously needs to be first, otherwise nothing
else would work, and we have code that adds checks to get around this.

For example, in the page table setting code, we check to see if the
system is turned on before we even notify the CPU instances of a page
table switch. This results in dead code (at the moment), because the
only time a page table switch will occur is when the system is *not*
running, preventing the emulated CPU instances from being notified of a
page table switch in a convenient manner (technically the code path
could be taken, but we don't emulate the process creation svc handlers
yet).

This moves the threads creation into its own member function of the core
manager and restores a little order (and predictability) to our
initialization process.

Previously, in the multi-threaded cases, we'd kick off several threads
before even the main kernel process was created and ready to execute (gross!).
Now the initialization process is like so:

Initialization:
  1. Timers

  2. CPU

  3. Kernel

  4. Filesystem stuff (kind of gross, but can be amended trivially)

  5. Applet stuff (ditto in terms of being kind of gross)

  6. Main process (will be moved into the loading step in a following
                   change)

  7. Telemetry (this should be initialized last in the future).

  8. Services (4 and 5 should ideally be alongside this).

  9. GDB (gross. Uses namespace scope state. Needs to be refactored into a
          class or booted altogether).

  10. Renderer

  11. GPU (will also have its threads created in a separate step in a
           following change).

Which... isn't *ideal* per-se, however getting rid of the wonky
intertwining of CPU state initialization out of this mix gets rid of
most of the footguns when it comes to our initialization process.

7 years ago

Lioncash

7128bf879f

core: Relocate CPU core management to its own class

Keeps the CPU-specific behavior from being spread throughout the main
System class. This will also act as the home to contain member functions
that perform operations on all cores. The reason for this being that the
following pattern is sort of prevalent throughout sections of the
codebase:

If clearing the instruction cache for all 4 cores is necessary:

Core::System::GetInstance().ArmInterface(0).ClearInstructionCache();
Core::System::GetInstance().ArmInterface(1).ClearInstructionCache();
Core::System::GetInstance().ArmInterface(2).ClearInstructionCache();
Core::System::GetInstance().ArmInterface(3).ClearInstructionCache();

This is kind of... well, silly to copy around whenever it's needed.
especially when it can be reduced down to a single line.

This change also puts the basics in place to begin "ungrafting" all of the
forwarding member functions from the System class that are used to
access CPU state or invoke CPU-specific behavior. As such, this change
itself makes no changes to the direct external interface of System. This
will be covered by another changeset.

7 years ago

2 Commits (33df906815616d1287cdad87ec490ada44c66ead)