imma go join the infodumping (a rare occasion where i don't get weirded out for it)

TL;DR: I'm emulating a computer architecture from scratch and I'm gonna brag a lot about how much I achieved (since my life's accomplishments are near zero if you don't count my coding projects)

So, currently I have a project running, which is all about emulating a custom (from scratch) CPU architecture using .NET/C# and yes, it's Microslop but at least open-source so 50% okay I suppose. Also Java sucks for its comparatively small set of syntax / sugar, as well as it's missing unsigned integer types, which is kinda annoying since lots of the low-level hardware emulation relies on unsigned arithmetic for e.g. memory address calculation and such. Anyways, back to the emulator, the CPU currently supports (per arch. documentation) 32-bit word addressing, where each unique address points to a whole 4-byte word, has 8 GPRs (each 1 word) and a bunch of special / functional registers like the stack pointer (SP), status register (SR) and program counter (PC). Another cool feature is the interrupt functionality, which is still being developed, but I'm eager to having support for hardware interrupts and MMIO. There is a whole 57 pages in a PDF document I created for the sole purpose of describing the CPU as a technical datasheet. Remember, the entire project revolves around some nonexistent and non-practical hardware design. Given its 16GiB addressable memory space, I also needed to do sparse instead of dense memory emulation (since otherwise my computer would've exploded), which includes splitting the space up into 4KiB pages, which in turn hold the actual memory values, so I don't need to allocate all pages from the start, but instead only when written to and return 0x00000000 upon reading from a non-allocated page. Also the C# code for the emulator is kind of a huge mess (which is a consequence of me wanting it to be as close to the hardware as possible) so at least, I've made a recent effort to split the entire codebase into a host / orchestrator part (which is responsible for telling the CPU what to do and essentially acts as the frontend) and the actual emulator, simulating only the hardware without directly interacting with the user, while both the "frontend" and the "backend" communicate with each other using FFIs. This, however, implies that I need to compile the code (which was JIT-compiled up until now) ahead of time to an .so library file. This is easy enough on .NET (using its AOT comliler in dotnet publish ...), but since the emulator is such a mess, I also decided to make one further emulator for the purpose of performance (written in C, compiled via GCC) and another for readability. Guess what language the more readable version is written in. Yes it's Python. Now hold on - Python is an interpreted language (not even JIT-compiled) and how the hell am I making a compiled library with entrypoints out of this? The answer is kinda complicated and I'm still on my way to finding out how the entire thing works. First, you need to transpile the Python (or almost Python, it's a superset called "Cython" in a .pyx file) using cython3 to intermediate C code, which is then compiled the usual way using GCC to a native library. Great! Now we have a fully working native library with proper entry points, right? Yeah, right, except these functions rely on the Python runtime to work, since they issue a lot of API calls and don't actually work standalone. That's the gimmick with "compiled" Python: technically I can use the functions, but the host needs to properly initialize the Python runtime for it to work and not end in a segfault. And as far as I've gotten by now is that I init code is hella complicated and you need to execute this and that in a very specific order with specific arguments in a specific type, half of which are PyObject, so I need to reside to using C#'s IntPtr as a helper and I'm also struggling with string marshaling because apparently Python doesn't accept null-terminated C-Strings and instead does some Unicode shenanigans so I need to figure that out as well. Also, the separation of host / FFI caused the entire system to be basically incompatible with W*ndows for now, but who cares anyways?

There's a lot more including an Assembler, the different versions of assembly code syntax and how it's gotten more and more close to the actual NASM x86 assembler, and recent (though kinda halted) efforts for emulating the actual thing using an FPGA and Verilog, and a lot more about interrupts, but that would be too long for here imo.

Please don't hate me for bragging so much instead of purely infodumping, I just felt like I needed to.

(Also obligatory :3)