Mini vMac v3.2.1 (2010-08-04) - 模擬器
By Una
at 2010-08-15T23:10
at 2010-08-15T23:10
Table of Contents
http://minivmac.sourceforge.net/
Mini vMac v3.2.1 (2010-08-04) is released.Mini-vMac is a Macintosh Plus,
Macintosh SE, Macintosh 128 and Macintosh 512 emulator. Mini vMac emulates a
Macintosh Plus, one of the earliest of Macintosh computers. It can run old
Macintosh software that otherwise couldn't be used on recent machines.
Mini vMac v3.2.1 (2010-08-04) Changelog:
Today's Development source snapshot contains an experiment in CPU emulation.
The CPU emulation method introduced in 3.0.1, and made the default in 3.1.0
involves a table that classifies each of the 65536 primary opcodes, saving
the work of decoding opcodes bit by bit. It has occurred to me that the
reason that it is not much faster than the previous approach is because it is
a poor fit for the caching scheme of modern processors. On each instruction
it loads a random byte from this table, which can cause the CPU to load an
entire cache line, perhaps 32 bytes or more, depending on the CPU, the rest
of which likely won't be used. One alternative would be to go back to the
previous bit by bit decoding, making the program a bit smaller and use a bit
less memory, making it more "mini". But instead I've experimented with going
in the opposite direction - as long as an entire cache line is being read in
anyway, make each element of the table larger, saving additional information
that can help with emulation. That's the basic idea, but the pros and cons
are complex, and to see what really would happen I needed to try it. Each
element is now 8 bytes, and depending on the opcode, saves information about
the instruction arguments. The main advantage is that there are now fewer
paths for decoding arguments, so those that remain can be better optimized,
at the expense of making them larger. Parts of the routines they call are
inlined into them, and then rearranged for better parallelism. Another
advantage is that since there are no longer separate classes of, for example,
the ADD instruction for each style of arguments, instead there can be
separate classes for each of the argument sizes (byte, word, and long),
avoiding nasty conditional branches that modern processors will likely
mispredict. Another benefit is that more of the logic of the emulator is
moved into the code that sets up the table (in M68KITAB), simplifying the
multiple versions of MINEM68K (c code, and assembly language for each
processor). The new approach so far averages around 5 percent faster for x86
and PowerPC assembly language, and I feel more improvement is possible. The c
version can be slower than before. The new approach makes careful assembly
language optimization more possible, but that generally doesn't help a c
compiler.
--
Mini vMac v3.2.1 (2010-08-04) is released.Mini-vMac is a Macintosh Plus,
Macintosh SE, Macintosh 128 and Macintosh 512 emulator. Mini vMac emulates a
Macintosh Plus, one of the earliest of Macintosh computers. It can run old
Macintosh software that otherwise couldn't be used on recent machines.
Mini vMac v3.2.1 (2010-08-04) Changelog:
Today's Development source snapshot contains an experiment in CPU emulation.
The CPU emulation method introduced in 3.0.1, and made the default in 3.1.0
involves a table that classifies each of the 65536 primary opcodes, saving
the work of decoding opcodes bit by bit. It has occurred to me that the
reason that it is not much faster than the previous approach is because it is
a poor fit for the caching scheme of modern processors. On each instruction
it loads a random byte from this table, which can cause the CPU to load an
entire cache line, perhaps 32 bytes or more, depending on the CPU, the rest
of which likely won't be used. One alternative would be to go back to the
previous bit by bit decoding, making the program a bit smaller and use a bit
less memory, making it more "mini". But instead I've experimented with going
in the opposite direction - as long as an entire cache line is being read in
anyway, make each element of the table larger, saving additional information
that can help with emulation. That's the basic idea, but the pros and cons
are complex, and to see what really would happen I needed to try it. Each
element is now 8 bytes, and depending on the opcode, saves information about
the instruction arguments. The main advantage is that there are now fewer
paths for decoding arguments, so those that remain can be better optimized,
at the expense of making them larger. Parts of the routines they call are
inlined into them, and then rearranged for better parallelism. Another
advantage is that since there are no longer separate classes of, for example,
the ADD instruction for each style of arguments, instead there can be
separate classes for each of the argument sizes (byte, word, and long),
avoiding nasty conditional branches that modern processors will likely
mispredict. Another benefit is that more of the logic of the emulator is
moved into the code that sets up the table (in M68KITAB), simplifying the
multiple versions of MINEM68K (c code, and assembly language for each
processor). The new approach so far averages around 5 percent faster for x86
and PowerPC assembly language, and I feel more improvement is possible. The c
version can be slower than before. The new approach makes careful assembly
language optimization more possible, but that generally doesn't help a c
compiler.
--
Tags:
模擬器
All Comments
Related Posts
Neko Project II Wii v0.83 beta4
By Agnes
at 2010-08-15T23:03
at 2010-08-15T23:03
Super Mario War Wii v1.4
By Donna
at 2010-08-15T22:09
at 2010-08-15T22:09
Mednafen 0.9.12-wip
By John
at 2010-08-15T21:30
at 2010-08-15T21:30
GBA 未發售的機車賽
By Catherine
at 2010-08-15T21:24
at 2010-08-15T21:24
復活邪神296~技能問題
By Olive
at 2010-08-15T20:27
at 2010-08-15T20:27