The term "memory" is really ambiguous in the context of an emulator,
especially since the MMU is being developed. It can refer to host memory, or
guest memory, or both.
Signed-off-by: Ronald Caesar <github43132@proton.me>
The term "aarch64" is the formal name for Armv8-A architecture. However,
I found that the establish convention across the wider open source
ecosystem is to use the short name "arm64".
Signed-off-by: Ronald Caesar <github43132@proton.me>
To handle faults such as data aborts, alignment faults, or supervisor
calls, the CPU must transition from the guest's context into a
privileged exception handler. This patch emulates the hardware sequence
for this entry process.
1. The vcpu_state_t struct includes the essential EL1 system registers
required for exception handling (ELR_EL1, SPSR_EL1, ESR_EL1, FAR_EL1,
and VBAR_EL1).
2. A new function, take_synchronous_exception(), is introduced. It
models the requirements for entering an exception targeting EL1:
- Saves the return address (PC) into ELR_EL1.
- Saves the current proccess state (PSTATE) into SPSR_EL1.
- Contructs the Exception Syndrome Register (ESR_EL1) from the
provided Exception Class and ISS.
- Saves the faulting address to FAR_EL1 for data aborts.
- Updates the live PSTATE to a safe state for the handler.
This implementation is intentially partial. The final step of updating the
PC to jump to a handler in the guest's vector table (using VBAR_EL1) is
stubbed out. The vector table will contain assembly instructions so a
functional instruction decoder is required to fully complete the
exception handler.
Signed-off-by: Ronald Caesar <github43132@proton.me>
The existing memory arena impelmentation is moved into the pound::memory
namespace to align with the pound::aarch64 namespace.
Signed-off-by: Ronald Caesar <github43132@proton.me>
Sinan Karakaya says:
==============
Adds the system registers for aarch64. They includes the one defined in Yuzu, but also include other from the armv8 specs that seems like they should be necessary for emulation.
Most of them might be subject to being removed in the future, if they turn out to not be required for emulation.
Signed-off-by: Ronald Caesar <github43132@proton.me>
This commit introduces a proper abstraction layer for all read and write
operations.
The previous approach of directly calculating a Host Virtual Address
(HVA) from a Guest Physical Address (GPA) via gpa_to_hva() forces every
part of the emulator that touches guest memory to be aware of the
underlying host pointer, which is poor design.
This new layer introduces a suite of guest_mem_read{b,w,l,q} and
guest_mem_write{b,w,l,q} fuctions. All future memory accesses from the
emulated CPU should be performed through these functions.
The code has also been moved into the pound::aarch64 namespace for
better organization.
Signed-off-by: Ronald Caesar <github43132@proton.me>
In emulating guests with a simple, flat memory model, we frequently need
to translate a guest physical address (GPA) into a host virtual address
(HVA). This is a hot path operation that must be efficient as possible.
This commit introduces gpa_to_hva(), a static inline helper function
designed for this purpose. The implementation relies on the fundamental
pre-condition that the guest's physical RAM is backed by a single,
contiguous region of host virtual memory (typically acquired via mmap).
It treats the GPA not as a pointer but as a direct byte offset from the
base of this host mapping.
This approach is optimal for performance for two key reasons:
1. The translation is a single pointer-offset calculation, which
typically compiles to a single LEA intruction on x86-64.
2. It preserves memory access locality. When a guest performs
sequential accesses, the host's accesses are also sequential,
allowing the host CPU's hardware prefetcher to function effectively.
This helper provides the fast path for simple RAM accesses. More
complex address spaces involving discontiguous memory or MMIO regions
will require a slower, lookup-based translation mechanism. This
function is not intended for those cases.
Signed-off-by: Ronald Caesar <github43132@proton.me>
The initial vCPU state for AArch64 had a couple of architectural
inaccuracies that this commit corrects.
First, AArch64 has 32 general-purpose registers (X0-X31), not 31.
The stack pointer (SP) is not a separate special-purpose register
but is an alias for register X31. The dedicated `sp` field in
vcpu_state_t was therefore redundant and architecturally incorrect.
This change increases GP_REGISTERS to 32 and removes the separate
`sp` field. The SP should be managed via `r[31]`.
Second, to support floating-point and SIMD instructions, the vCPU
state must include the vector registers. This adds the definitions
and storage for the 32 128-bit FP/SIMD registers (V0-V31).
Signed-off-by: Ronald Caesar <github43132@proton.me>
Introduce the basic data structures required to manage the architectural
state of an emulated ARMv8 guest. This is a foundational patch for a
forthcoming emulator framework.
The core of this change is the `vcpu_state_t` structure, which holds
the essential user-visible state of a single virtual CPU (vCPU),
including the general-purpose registers, stack pointer, program counter,
and PSTATE.
The state for all vCPUs is aligned to the CPU L1 cache line. This design
choice ensures that there is no false sharing between physical host
cores running separate vCPU emulation threads.
Signed-off-by: Ronald Caesar <github43132@proton.me>
arena_init() has been given the parameter `size_t capacity`, however,
docs amd some definitions wasn't changed to reflect this.
The definition MEMORY_CAPACITY was replaced by `size_t capacity` but
it wasn't removed.
Signed-off-by: Ronald Caesar <github43132@proton.me>
This is because the source code is objected oriented which is not cpu cache
friendly, making the program slower than it has to be. Yuzu's entire
codebase is written in a objected oriented way and I wonder how much faster
it could if they had use DoD principles from the very beginning.
That's why I want to instill DoD fundamentals early on so this won't be a
problem going forward.
Signed-off-by: Ronald Caesar <github43132@proton.me>
This commit removes a custom mmap() function which was supposed
to support both windows and linux but the linux and macOS builds
failed to compile.
The custom mmap() function will be replaced by malloc() for windows
and linux's native mmap().
Signed-off-by: Ronald Caesar <github43132@proton.me>
- Create modular GUI architecture with base Panel class
- Implement GUIManager to handle window lifecycle and panel management
- Add Window wrapper class for SDL3/OpenGL context management
- Create specialized panels:
- ConsolePanel: Colored log output with timestamps
- CPUPanel: CPU debugging with tabs for registers, memory, and disassembly
- PerformancePanel: Real-time FPS and frame time monitoring
- Apply modern dark theme with purple accents
- Add comprehensive menu bar (File, Emulation, View, Tools, Help)
- Update CMakeLists.txt to include new gui/ directory structure
- Refactor main.cpp to use the new GUI system
- Cutom theme on switch colors
I wanted a fast and predictable memory allocator before I start working on the virtual filesystem.
Functions like malloc and realloc will not be used anymore, instead, the allocator will
need to be passed as a function parameter when doing any kind of heap allocation. For example
char* create_string(Memory::Arena *allocator);
int* create_int_array(Memory::Arena *allocator, int size);
The definition MEMORY_CAPACITY in arena.h sets the amount of memory the arena can use.
The number can be increased as needed.
Signed-off-by: Ronald Caesar <github43132@proton.me>
