[hle] constexpr handler dispatch maps, introduce version gating (#4480)

This PR primarily focuses on upbringing constexpr maps for handlers.

Each time an HLE object of a service is construed, it registers it's own handlers, over and over.
Regardless of whetever it needs them at the moment or not.
Additionally we don't require to keep track of different function pointers amongst each object.
This can be done by overriding the given function instead, as opposed to having a separate
hash map for every given object.

In other words: Remove handlers (and handlers_tipc) map for every instance
then read from a static defined per-class.

- [x] Migrate all HLE functions to new `frozen::map` constexpr time finder
- [ ] Measure if this approach actually makes better codegen

Optional:
- [x] Properly gate all functions (that have versions commented next to them)
- [x] Maybe store `HandlerFnP<>` and `const char*` separately, version gating can go in a different map as well

Information such as name can be used on debug builds, but doesn't particularly help on release as one can consult an external reference (or have an annotated IPC map)

Signed-off-by: lizzie <lizzie@eden-emu.dev>

- [x] I have read and followed the [Contribution Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/CONTRIBUTING.md#code-contributions).
- [x] I have read and followed the [AI Policy](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/AI.md)
- [x] I have read and followed the [Coding Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/Coding.md) to the best of my ability.

-------------------

Co-authored-by: Maufeat <sahyno1996@gmail.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4480
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
This commit is contained in:
lizzie
2026-10-13 04:38:36 +02:00
committed by crueter
parent 4dc69c06f7
commit 218c6705d9
392 changed files with 12860 additions and 14029 deletions
+1 -1
View File
@@ -1,6 +1,6 @@
# Design Overview
Modern game consoles require heavy power to be emulated appropriately. This is why the emulator uses an approach known as HLE (High-Level-Emulation), in a nutshell: Instead of accurately emulating every subsystem that forms part of a component, emulate the resulting visible I/O interface instead.
Modern game consoles require heavy power to emulate. This is why the emulator uses an approach known as HLE (High-Level-Emulation), in a nutshell: Instead of accurately emulating every subsystem that forms part of a component, emulate the resulting visible output of said interface instead.
For example, take a disk write, instead of emulating a proper SD card we instead use the C++ standard library for I/O. Additionally we use the abstractions provided by the `fs` service to "lie" to programs about certain SD card properties. Notably this includes making up sizes for the fake SD card, giving "realistic" values or expected outputs for a given card, and so on. And instead of writing to an actual SD card, the emulator simply writes to a file.