What kind of tests are important for an emulator?
#![no_std]
#![no_main]
use riscutils::colours;
use riscutils::draw_char;
use riscutils::print;
use core::panic::PanicInfo;
#[panic_handler]
fn panic(_info: &PanicInfo) -> ! {
loop {}
}
#[unsafe(no_mangle)]
pub extern "C" fn _start() -> ! {
print("Hello, World!", 0, 0, (colours::LCYAN, colours::LGREY));
loop {}
}
should it just be device tests? whats the best way to test most things?
In my experience, the really valuable tests are test ROM/app suites developed by the community. These might produce either output images that can be compared to a known good, or produce output to an IO port, or in really low level tests use a "weird" op like "mov x, x" to signal test completion with results in registers.
Those will tell you something is wrong, but generally not why: there you'll want to build a debugger that lets you inspect registers and memory, run to an instruction, etc.. Egui is a pretty good option given how stateless you want to be here, but you can use a terminal one similar to gdb too. You'll want to have a disassembler for this, but you should be able to reuse your CPU interpreter for most of that.
Also building your own unit tests where you feed small instruction inputs is super handy, though it's a bit too easy with emulators to test what you thought the behavior should be not what it actually is; and it's pretty tricky to either nicely split up systems or to set up all the required state per test. I found this more like the last resort rather than the normal first resort. An exception might be CPU instructions, which tend to be very well documented and easy to isolate, but are pretty exhausting and generally aren't super valuable after you get them right.
An exception might be CPU instructions
so glad ill never make an x86_64 emulator with its 1500 instructions and test all of them
there you'll want to build a debugger that lets you inspect registers and memory, run to an instruction
thats the point youre making for egui? to have a second window for monitoring debug information
Eh, all "real" instruction sets are at least somewhat weird, and often have at least comparable instruction counts. Most of the time you can boil it down to a few dozen u-ops or the like, or ¾ of them are never emitted by any compiler, etc..., but yeah x86 is definitely the weird one!
Being a separate window or not depends on your setup, I've generally gone with it being a mode where the output is embedded as an Image widget, though that needs a bit more framework futzing to be able to write to the underlying texture each frame. That might make it a bit easier to be able to control input too, otherwise you might be fighting input focus while stepping through a button interrupt or the like.