Redundant reset methods?

[simias]

This is not a big deal I've noticed that your Cpu has a reset method. I did something similar when I implemented a GameBoy emulator but I got rid of it after a while. The main problem is that I was worried about adding a new state variable to the struct and forget to reset it properly in the method. Moreover you end up having a lot of redundant code between your constructor and reset function.

For this reason I prefer to have a constructor that builds an instance of the module "at reset". When I need to reset something I simply build a new instance and replace the old. Since Rust will raise an error if you don't initialize something in your constructor you're sure you won't forget to set the reset value correctly.

Good luck with your project!

[yupferris]

I guess you could also be cheeky and have a reset fn like this:

pub fn reset(&mut self) {
    *self = Cpu::new();
}

Then you still get the same semantics with that fn, and the niceties you get with initializing everything properly in the ctor :)

[yupferris]

Something "feels" a bit wrong with doing away with the function entirely; perhaps I'm thinking I really want a soft_reset fn that will maintain certain bits of state, and hard reset would just be recreating the whole graph.

[simias]

Yeah it's a matter of "style" really, I can see wanting a reset method to stay closer to the actual chip or something.

On the PlayStation I know that the RAM, VRAM and some registers are not reset when you press the "reset" button but I don't actually bother keeping track of that when a reset is requested by the user. I just put random "garbage" data in them by default. My main concern with a "partial reset" would be to end up with a strange bug that would only happen in certain situations after a partial reset and would be a pain to reproduce and track down. If you always reset to the the same "clean" state you run should be more deterministic, hopefully...

[iherbig]

Considering power_on_reset simply initializes the state of the Cpu and all dependencies, doesn't it make sense to have new simply do that? Is there any circumstance in which you'd call new without calling power_on_reset? Is there any circumstance in which you'd call power_on_reset but you couldn't simply call new?

Obviously doing so would require you to add a new function for some types like Cp0 and RegConfig, but I don't see why the separation of concerns. new is for initialization of a struct and that's exactly what power_on_reset is doing. It just seems like you're initializing each struct half in new/Default and half in power_on_reset.

[yupferris]

@iherbig: For power_on_reset it is indeed a bit strange to have the separation, but I suppose I was thinking you might want to only instantiate the graph once, and call power_on_reset later to simulate a hard reset. It could be argued that you could just re-instantiate the graph (as @simias is also suggesting) and I'll probably switch to that, but I'll likely also have a soft_reset method as well that simulates the reset button on the system (or the reset pin in the case of the subcomponents).

[yupferris]

I'll go ahead and fix this on one of the next streams probably. I'd like to request nobody does a PR for it, because I want to talk about why we want to do this on stream :)

[iherbig]

I definitely think a separate soft_reset is called for, especially if you're going for accuracy of emulation. I'm not sure if there's any examples on the N64, but I know that the NES has at least one case (Final Fantasy) where the soft reset mechanism can actually be used to influence RNG. (Speed runners of the game will often power down the console and let the RAM expire to reset the system back to a cold-reset state.)

Look forward to your next stream, Jake.