Caching...(something faster than memory)

[earlz]

in my x86 emulator I am wanting to have some sort of caching to speed up the emulation.

all emulator memory right now is stored in actual memory right now, I don't really want to do the translation thingy, plus I don't know how that would be any faster than my current method.


on a side note, I'm thinking about allowing you to use harddrive space instead of memory, hence you could test to make sure an OS works with 4gb of memory, though your actual computer only have 512mb..

[Candy]

in my x86 emulator I am wanting to have some sort of caching to speed up the emulation.

all emulator memory right now is stored in actual memory right now, I don't really want to do the translation thingy, plus I don't know how that would be any faster than my current method.


on a side note, I'm thinking about allowing you to use harddrive space instead of memory, hence you could test to make sure an OS works with 4gb of memory, though your actual computer only have 512mb..

For the last bit, read up on "sparse files". They're the way I'm testing whether my mkfs tool can generate 15TB files, even though I only have 40GB free. (BTW: yes it can).

Bochs can handle them as well. The only break in the chain could be using Windows, which doesn't know about them.

[Solar]

hckr83, I just read your emulator / opcode thread, and now this one... and I absolutely cannot figure out what you want / are talking about. Yea, so you want some sort of caching, don't want "the translation thingy", and generally speaking you don't know.

Uh-huh... and your question was?

Consider this a bug report on your communication style.

[JoeKayzA]

@hckr83: Just a wild guess - do you mean you want to use a file on disk which stores the VMs memory instead of "real" memory? In this case, maybe this could help:

Implement a sort of swapping within your emulator (at application level) - You have a file on disk which represents the VM memory, if memory is accessed, you map parts of the file into the emulators address space and direct the memory access to that location. If memory gets sparse, you unmap that area again and map a different part. To make this efficient you'll need a sophisticated swapping algorithm, a bit similar to swapping at OS level. You could look at qemu, which does a similar thing. The advantage is that you are independent from any swapping or virtual memory restrictions from the host OS's side.

It's pretty hard to distill your actual problem/question out of your post, though...

[Tyler]

I am pretty sure that in order to make the Virtual Operating System Caching faster than a normal access he wants to emulate a faster memory access. I don't believe youw ill be able to find anywhere faster than main memory to store that i am afriad.

[earlz]

meh...just been trying to think of a way to speed up functions[opcode](); faster...and I don't mean converting to a switch()

[os64dev]

meh...just been trying to think of a way to speed up functions[opcode](); faster...and I don't mean converting to a switch()

the functions[opcode](); implies that you are using interpretation which is the slowest of all emulation principles. try googling for dynamic recompilation, or recompilers. or check out the blog of pcsx2(ww.pcsx2.net)

[earlz]

that's the thing, I want it to be portable..

[os64dev]

portable imho comes in different flavors. if you write a recompiler using a library of functions like mov32(void * mem, int val), mov64 etc. than you can port it by implementing the library for a different platform whereas the recompiler itself does not change. this is more of a design pattern which is a good read anyway. the book that is.