TheV360
commented
2 years ago A while ago (1 or 2 days/weeks ago) I think I went through this same thought process, about the "allocate sections of RAM as they're used" thing.
On one hand:
- Not allocating a huge amount of memory at the start
- Allocates minimal amount of memory for normal programs
And on the other:
- Wouldn't there be a performance penalty?
- I am essentially trying to make pages, but worse
- Maybe I just need to make the RAM into some kinda
vecthat grows if you index out of bounds.
It'd be cool to take the RAM out of the CPU however -- imagine having two CPUs running on the same RAM! Fun to emulate.
So yeah, conclusion: don't do this, (not even the vec idea??) just maybe uh keep it the way it is, use MARS' compact memory layout for this and limit RAM to like 0x10_0000 or so.
I'll work on this in a bit.
RAM doesn't need to be inside the CPU, contrary to what this comment says:
https://github.com/TheV360/toy_mips_emu/blob/62abb2239d5cfbca05e39bd52ec6a1f810094cd0/src/chip.rs#L112-L117
Plus, this current implementation is Very wasteful. It's the reason the WASM version takes half a second to initialize!! I want to allocate sections of RAM as they're filled in. Maybe that sucks? It will suck for a program that randomly pokes everywhere, but that program is asking to waste time. We'll see.
I'm thinking of taking an approach similar to how CPUs cache things, y'know? They take parts of the memory address and assign them to different buckets. (Or whatever that term is) After this, I could absolutely switch to the "large" memory format MARS uses by default.