- #GP when trying to set reserved bits of CR4_HI in 64-bit mode
- #GP when trying to set reserved bits of EFER MSR
- clear upper part of RSI/RDI when executing rep instructions with 32-bit asize
even if no repeat iterations were executed (because of RCX=0 for example)
- write SYSENTER_EIP_MSR and SYSENTER_ESP_MSR as 64-bit when x86_64 supported
- set MSR_FMASK reset value
- MSR_FMASK should be 32-bit only
- check for fetch permissions when doing ITLB lookup
- #GP when trying to write non-canonical address to MSR_CSTAR or MSR_LSTAR
- correct repeat instructions timing
- mark TSS busy in TR after it is loaded
Starting convergence to new lazy flags scheme by Darek Mihocka (www.emulators.com). The new flags code is still being validated and perfected but I try to minimize the diff between 2 versionS
- Fixed critical bug in CPU code added with one of the prev commits
- Disasm support for SSE4
- Rename PNI->SSE3 everywhere in the code
- Correctly decode, disassemble and execute 'XCHG R8, rAX' x86-64 instruction
- Correctly decode, disassemble and execute multi-byte NOP 0F F1 opcode
- Fixed ENTER and LEAVE instructions in x86-64 mode
- Added ability to turn ON instruction trace, only GUI support is missed.
Instruction trace could be enabled if Bochs was compiled with disasm
- More changes Bit32u -> bx_phy_address
- Complete preliminary implementation of SMM in Bochs, SMI is still PANICs but if you press 'continue' everything should work OK
- Small code cleanup
- Update CHANGES and user docs
Averything that required cpu.h include now has it explicitly and there are a lot of files not dependant by CPU at all which will compile a lot faster now ...
Manual says that GP(0) shouldd be generated in this case ALWAYS
Fixed instructions PANIC messages to ERROR for this case
And ... do not leave PANIC messages w/o taking care that user could push CONTINUE button and program should know to continue after the PANIC code line. Mainly in rerurn instructions were several problems ...
these from interfering from a normal compile here's what I did.
In config.h.in (which will generate config.h after a configure),
I added a #define called KPL64Hacks:
#define KPL64Hacks
*After* running configure, you must set this by hand. It will
default to off, so you won't get my hacks in a normal compile.
This will go away soon. There is also a macro just after that
called BailBigRSP(). You don't need to enabled that, but you
can. In many of the instructions which seemed like they could
be hit by the fetchdecode64() process, but which also touched
EIP/ESP, I inserted a macro. Usually this macro expands to nothing.
If you like, you can enabled it, and it will panic if it finds
the upper bits of RIP/RSP set. This helped me find bugs.
Also, I cleaned up the emulation in ctrl_xfer{8,16,32}.cc.
There were some really old legacy code snippets which directly
accessed operands on the stack with access_linear. Lots of
ugly code instead of just pop_32() etc. Cleaning those up,
minimized the number of instructions which directly manipulate
the stack pointer, which should help in refining 64-bit support.
also extended by the REX.B field on Hammer) is passed to instructions.
I rearranged the bxInstruction_c to free up a field to be used
to pass this info when mod-rm bytes are not used. This got rid
of the ugly ((i->b1 & 7) + i->rex_b) code.
Probably shaved just a very little run time off Hammer emulation,
and even less on x86-32. The resultant is a little cleaner anyways.
in cpu.cc out of the main loop, and into the asynchronous
events handling. I went through all the code paths, and
there doesn't seem to be any reason for that code to be
in the hot loop.
Added another accessor for getting instruction data, called
modC0(). A lot of instructions test whether the mod field
of mod-nnn-rm is 0xc0 or not, ie., it's a register operation
and not memory. So I flag this in fetchdecode{,64}.cc.
This added on the order of 1% performance improvement for
a Win95 boot.
Macroized a few leftover calls to Write_RMV_virtual_xyz()
that didn't get modified in the x86-64 merge. Really, they
just call the real function for now, but I want to have them
available to do direct writes with the guest2host TLB pointers.
to bitfields. bxInstruction_c is now 24 bytes, including 4 for
the memory addr resolution function pointer, and 4 for the
execution function pointer (16 + 4 + 4).
Coded more accessors, to abstract access from most code.
with accessors. Had to touch a number of files to update the
access using the new accessors.
Moved rm_addr to the CPU structure, to slim down bxInstruction_c
and to prevent future instruction caching from getting sprayed
with writes to individual rm_addr fields. There only needs to
be one. Though need to deal with instructions which have
static non-modrm addresses, but which are using rm_addr since
that will change.
bxInstruction_c is down to about 40 bytes now. Trying to
get down to 24 bytes.
use accessors. This lets me work on compressing the
size of fetch-decode structure (now called bxInstruction_c).
I've reduced it down to about 76 bytes. We should be able
to do much better soon. I needed the abstraction of the
accessors, so I have a lot of freedom to re-arrange things
without making massive future changes.
Lost a few percent of performance in these mods, but my
main focus was to get the abstraction.
