Does anyone know if OP would be able to work around the single-ownership issue using Cell/RefCell?
I still haven't fully grasped how to use those, but they seem like they'd fit there.
Implementing a NES Emulator in Rust
41–50 of 93 posts
Re: Implementing a NES Emulator in Rust
#42Does anyone know if OP would be able to work around the single-ownership issue using Cell/RefCell? I still haven't fully grasped how to use those, but they seem like they'd fit there.
OP mentions that the use of unsafe code means it's single-threaded, so yes it's likely that RefCell could be used instead of unsafe code.
Re: Implementing a NES Emulator in Rust
#43Does anyone know if OP would be able to work around the single-ownership issue using Cell/RefCell? I still haven't fully grasped how to use those, but they seem like they'd fit there.
Cell and RefCell are both !Sync, as they don't prevent dataraces. You would still need to wrap them in a Mutex to actually make them threadsafe. But Rc> would forego the need for unsafe{} here, at the cost of runtime enforcement of unique mutable access, without making it threadsafe. Or Arc> for the thread safe variation.
Re: Implementing a NES Emulator in Rust
#44Does anyone know if OP would be able to work around the single-ownership issue using Cell/RefCell? I still haven't fully grasped how to use those, but they seem like they'd fit there.
OP mentions that the use of unsafe code means it's single-threaded, so yes it's likely that RefCell could be used instead of unsafe code.
I'm frankly a bit worried about that statement; I believe it means that they're producing UB. Even with unsafe, Rust code is expected to uphold the safety rules.
I haven't read the code though.
Re: Implementing a NES Emulator in Rust
#45Earlier quoted context omitted.
Emulating a system of a few 2Mhz with a 4x3Ghz chipset ought to be doable using managed memory.
Nitpicking a bit, but there's not a lot of useful things that could be multithreaded in an 8-bit emulator, so it would be more like 1x3Ghz ;) In those old 8- and 16-bit machines all components usually ran completely synchronous for each clock tick, for instance if the video emulation runs out of sync with the CPU emulation for a tick or two, a write from the CPU to a video hardware register might not make it in time…
The original hardware was multithreaded... in the sense that there were several separate processing units.
Re: Implementing a NES Emulator in Rust
#46Question, what made it easier to build this in Rust than other languages? I know the advantages of Rust, but what exactly was the experience in this context?
It seems that unsafe references were used, so the advantages of Rust appear to have been somewhat relinquished in this case.
One of Rust's advantages is that you can drop into unsafe to do this sort of thing.
Re: Implementing a NES Emulator in Rust
#47What is something that I can do to learn Rust better? I have been through the book, but that's it. What would help me really learn Rust?
"How do you get to Carnegie Hall?" Seriously, the best thing to do for virtually all professional or hobby work is to get more experience with it. Choose a project with small enough scope to give you encouraging results to keep that feedback loop going.
That is a great analogy thanks.
Re: Implementing a NES Emulator in Rust
#48Earlier quoted context omitted.
It seems that unsafe references were used, so the advantages of Rust appear to have been somewhat relinquished in this case.
unsafe exists in Rust for when you need it. When it is used, it means nothing more than you’re writing code for which you must ensure the safety instead of the compiler. The times when unsafe is poorly used are when it’s being abused to ignore safety related compilation issues, like lifetimes and/or mutability. Though, even in those cases it might be ok if you’re using lower level concurrency primitives to enforce th…
It doesn’t remove restrictions, it adds unchecked constructs. Very different!
Re: Implementing a NES Emulator in Rust
#49Earlier quoted context omitted.
OP mentions that the use of unsafe code means it's single-threaded, so yes it's likely that RefCell could be used instead of unsafe code.
I'm frankly a bit worried about that statement; I believe it means that they're producing UB. Even with unsafe, Rust code is expected to uphold the safety rules. I haven't read the code though.
OP is using unsafe to store a mut pointer to a boxed value so that it can be mutated in two places. So the statement is just referring to data races.
Re: Implementing a NES Emulator in Rust
#50Earlier quoted context omitted.
I'm frankly a bit worried about that statement; I believe it means that they're producing UB. Even with unsafe, Rust code is expected to uphold the safety rules. I haven't read the code though.
OP is using unsafe to store a mut pointer to a boxed value so that it can be mutated in two places. So the statement is just referring to data races.
Sounds like UB to me! I’ll have to take a look. It really depends on the details.
(I tried to run miri on it, but I'm on Windows, and this is unix-only.)
EDIT: even with porting some of the code, I can’t get the current repository to build, there’s a borrow checker error...)