From 218c6705d950635bc18f8458d738a1996fb592b6 Mon Sep 17 00:00:00 2001 From: lizzie Date: Tue, 13 Oct 2026 04:38:36 +0200 Subject: [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 - [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 Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4480 Reviewed-by: Maufeat Reviewed-by: MaranBr --- docs/DesignOverview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/DesignOverview.md') diff --git a/docs/DesignOverview.md b/docs/DesignOverview.md index c6a328cb9c..959fbfdbb2 100644 --- a/docs/DesignOverview.md +++ b/docs/DesignOverview.md @@ -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. -- cgit v1.2.3