if you get computation, you get the curry-howard-lambek correspondence for free. So you have an equivalence between logic as well as (cartesian closed) categories.
It also means some of those axioms are probably superfluous. It also means your bound by some of the same laws (? maybe the wrong term here?) that computation is (halting problem) etc.
they're really simple, in their basic form and for simple ISAs!
it mostly boils down to keeping a bunch of registers and a giant switch statement. Each case simply implements the opcode. You have an array of bytes for the memory, and some emulated devices (e.g. trigger a screen update when the framebuffer memory gets changed, or set the instruction pointer to a handler when a key gets pressed.)
It gets hard when instructions need lots of decoding, or you have 3d graphics hardware to emulate, or if you have something like a BIOS, or if you want to JIT.
I'm actually eyeing implementing a console on an FPGA as my holiday project, with something like Chisel.
It seems like a lot of the complexity may also come in when you have important circuits to emulate other than the CPU. In that case you'd have more to worry about in terms of timing, dataflow, and synchronization. And some platforms might conceivably have analog circuits that play an important role too, although I guess you might be able to abstract that out by trying to create a rough digital functional equivalent even if it isn't completely faithful to the behavior of the analog part.
that's true! but I still think you can get a lot of the way with a NeoGeo emulator without it being perfect on timing. that's a lot of the reason emulators work well on most games but fail to replicate the right graphics or sound in some - some games played hardware tricks to optimize.
My friend who works on the MAME project told me that it's a very friendly platform for adding new emulators (whether you want to add an emulation of a game, a device, a platform, or whatever) because it provides a good structure to work with and a lot of tools to describe recurring patterns in electronics and systems. That might be a good middle ground to start with -- trying to add support in MAME for some device that's not presently emulated there. (Apparently the MAME project really appreciates such contributions, since they think of themselves as pursuing mainly a historical preservation and documentation mission, and would always like to see more devices covered.)
Although that's not "from scratch" because it would still be using their libraries and plumbing, it could be "from scratch" in the sense that you might take an environment with 0% support for emulating a certain device or system and build it up to having 100% support. So it seems like a nice way to start.
Its a given that if you are trying to get into faang you are going to need to spend a considerable amount of time trying to game the interview process by doing as many leetcode problems and mock interviews as you can before the interview. And then still there is no guarantee, even if you ace all rounds and pass all the coding challenges.
Can you share some tips on how you achieved this? What did you do if you got stuck on a question you just couldn't solve? Did you look at the answer and memorized it? How many questions did you solve? Were they mostly mediums or hards? What about system design, any specific resources you used?.
I keep coming back to leetcode every few months but I always get stuck on mediums so I'd appreciate any tips you can share!.
