281e62d8b1
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. |
||
---|---|---|
bochs | ||
bochs-performance | ||
CVSROOT | ||
sfsite |