mirrors/Bochs
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
3aa1b591c1
Bochs/bochs/cpu/ctrl_xfer32.cc

634 lines
15 KiB
C++
Raw Normal View History

- add RCS Id to header of every file. This makes it easier to know what's going on when someone sends in a modified file.
2001-10-03 17:10:38 +04:00
/////////////////////////////////////////////////////////////////////////
instrumentation enchancements: * renamed CPU_ID to BX_CPU_ID. with this new name there is no possibility for name contentions and BX_CPU_ID definition could be moved out to NEED_CPU_REG_SHORTCUTS block * returned back `unsigned BX_CPU::which_cpu(void)` function * added BX_CPU_ID parameter for BX_INSTR_PHY_READ(a20addr, len); BX_INSTR_PHY_WRITE(a20addr, len); now it will be BX_INSTR_PHY_READ(cpu_id, a20addr, len); BX_INSTR_PHY_WRITE(cpu_id, a20addr, len);
2003-02-13 18:04:11 +03:00
// $Id: ctrl_xfer32.cc,v 1.25 2003-02-13 15:03:59 sshwarts Exp $
- add RCS Id to header of every file. This makes it easier to know what's going on when someone sends in a modified file.
2001-10-03 17:10:38 +04:00
/////////////////////////////////////////////////////////////////////////
//
- update copyright dates to 2001 for all mandrake headers - for bochs files with other header, replaced with current mandrake header
2001-04-10 06:20:02 +04:00
// Copyright (C) 2001 MandrakeSoft S.A.
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
//
// MandrakeSoft S.A.
// 43, rue d'Aboukir
// 75002 Paris - France
// http://www.linux-mandrake.com/
// http://www.mandrakesoft.com/
//
// This library is free software; you can redistribute it and/or
// modify it under the terms of the GNU Lesser General Public
// License as published by the Free Software Foundation; either
// version 2 of the License, or (at your option) any later version.
//
// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
// Lesser General Public License for more details.
//
// You should have received a copy of the GNU Lesser General Public
// License along with this library; if not, write to the Free Software
// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- parts of the SMP merge apparantly broke the debugger and this revision tries to fix it. The shortcuts to register names such as AX and DL are #defines in cpu/cpu.h, and they are defined in terms of BX_CPU_THIS_PTR. When BX_USE_CPU_SMF=1, this works fine. (This is what bochs used for a long time, and nobody used the SMF=0 mode at all.) To make SMP bochs work, I had to get SMF=0 mode working for the CPU so that there could be an array of cpus. When SMF=0 for the CPU, BX_CPU_THIS_PTR is defined to be "this->" which only works within methods of BX_CPU_C. Code outside of BX_CPU_C must reference BX_CPU(num) instead. - to try to enforce the correct use of AL/AX/DL/etc. shortcuts, they are now only #defined when "NEED_CPU_REG_SHORTCUTS" is #defined. This is only done in the cpu/*.cc code.
2001-05-24 22:46:34 +04:00
#define NEED_CPU_REG_SHORTCUTS 1
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
#include "bochs.h"
merge in BRANCH-io-cleanup. To see the commit logs for this use either cvsweb or cvs update -r BRANCH-io-cleanup and then 'cvs log' the various files. In general this provides a generic interface for logging. logfunctions:: is a class that is inherited by some classes, and also . allocated as a standalone global called 'genlog'. All logging uses . one of the ::info(), ::error(), ::ldebug(), ::panic() methods of this . class through 'BX_INFO(), BX_ERROR(), BX_DEBUG(), BX_PANIC()' macros . respectively. . . An example usage: . BX_INFO(("Hello, World!\n")); iofunctions:: is a class that is allocated once by default, and assigned as the iofunction of each logfunctions instance. It is this class that maintains the file descriptor and other output related code, at this point using vfprintf(). At some future point, someone may choose to write a gui 'console' for bochs to which messages would be redirected simply by assigning a different iofunction class to the various logfunctions objects. More cleanup is coming, but this works for now. If you want to see alot of debugging output, in main.cc, change onoff[LOGLEV_DEBUG]=0 to =1. Comments, bugs, flames, to me: todd@fries.net
2001-05-15 18:49:57 +04:00
#define LOG_THIS BX_CPU_THIS_PTR
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
void
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
BX_CPU_C::RETnear32_Iw(bxInstruction_c *i)
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
{
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
BailBigRSP("RETnear32_Iw");
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
Bit16u imm16;
Bit32u temp_ESP;
Bit32u return_EIP;
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
invalidate_prefetch_q();
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
#if BX_DEBUGGER
BX_CPU_THIS_PTR show_flag |= Flag_ret;
#endif
if (BX_CPU_THIS_PTR sregs[BX_SEG_REG_SS].cache.u.segment.d_b) /* 32bit stack */
temp_ESP = ESP;
else
temp_ESP = SP;
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
imm16 = i->Iw();
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
if (protected_mode()) {
if ( !can_pop(4) ) {
strip '\n' from BX_{INFO,DEBUG,ERROR,PANIC} don't need it, moved the output of it into the general io functions. saves space, as well as removes the confusing output if a '\n' is left off
2001-05-30 22:56:02 +04:00
BX_PANIC(("retnear_iw: can't pop EIP"));
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
/* ??? #SS(0) -or #GP(0) */
}
access_linear(BX_CPU_THIS_PTR sregs[BX_SEG_REG_SS].cache.u.segment.base + temp_ESP + 0,
4, CPL==3, BX_READ, &return_EIP);
if (protected_mode() &&
(return_EIP > BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].cache.u.segment.limit_scaled) ) {
strip '\n' from BX_{INFO,DEBUG,ERROR,PANIC} don't need it, moved the output of it into the general io functions. saves space, as well as removes the confusing output if a '\n' is left off
2001-05-30 22:56:02 +04:00
BX_DEBUG(("retnear_iw: EIP > limit"));
merge in BRANCH-io-cleanup. To see the commit logs for this use either cvsweb or cvs update -r BRANCH-io-cleanup and then 'cvs log' the various files. In general this provides a generic interface for logging. logfunctions:: is a class that is inherited by some classes, and also . allocated as a standalone global called 'genlog'. All logging uses . one of the ::info(), ::error(), ::ldebug(), ::panic() methods of this . class through 'BX_INFO(), BX_ERROR(), BX_DEBUG(), BX_PANIC()' macros . respectively. . . An example usage: . BX_INFO(("Hello, World!\n")); iofunctions:: is a class that is allocated once by default, and assigned as the iofunction of each logfunctions instance. It is this class that maintains the file descriptor and other output related code, at this point using vfprintf(). At some future point, someone may choose to write a gui 'console' for bochs to which messages would be redirected simply by assigning a different iofunction class to the various logfunctions objects. More cleanup is coming, but this works for now. If you want to see alot of debugging output, in main.cc, change onoff[LOGLEV_DEBUG]=0 to =1. Comments, bugs, flames, to me: todd@fries.net
2001-05-15 18:49:57 +04:00
exception(BX_GP_EXCEPTION, 0, 0);
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
/* Pentium book says imm16 is number of words ??? */
if ( !can_pop(4 + imm16) ) {
strip '\n' from BX_{INFO,DEBUG,ERROR,PANIC} don't need it, moved the output of it into the general io functions. saves space, as well as removes the confusing output if a '\n' is left off
2001-05-30 22:56:02 +04:00
BX_PANIC(("retnear_iw: can't release bytes from stack"));
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
/* #GP(0) -or #SS(0) ??? */
}
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
EIP = return_EIP;
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
if (BX_CPU_THIS_PTR sregs[BX_SEG_REG_SS].cache.u.segment.d_b) /* 32bit stack */
ESP += 4 + imm16; /* ??? should it be 2*imm16 ? */
else
SP += 4 + imm16;
}
else {
pop_32(&return_EIP);
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
EIP = return_EIP;
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
if (BX_CPU_THIS_PTR sregs[BX_SEG_REG_SS].cache.u.segment.d_b) /* 32bit stack */
ESP += imm16; /* ??? should it be 2*imm16 ? */
else
SP += imm16;
}
instrumentation enchancements: * renamed CPU_ID to BX_CPU_ID. with this new name there is no possibility for name contentions and BX_CPU_ID definition could be moved out to NEED_CPU_REG_SHORTCUTS block * returned back `unsigned BX_CPU::which_cpu(void)` function * added BX_CPU_ID parameter for BX_INSTR_PHY_READ(a20addr, len); BX_INSTR_PHY_WRITE(a20addr, len); now it will be BX_INSTR_PHY_READ(cpu_id, a20addr, len); BX_INSTR_PHY_WRITE(cpu_id, a20addr, len);
2003-02-13 18:04:11 +03:00
BX_INSTR_UCNEAR_BRANCH(BX_CPU_ID, BX_INSTR_IS_RET, EIP);
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
void
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
BX_CPU_C::RETnear32(bxInstruction_c *i)
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
{
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
BailBigRSP("RETnear32");
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
Bit32u temp_ESP;
Bit32u return_EIP;
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
invalidate_prefetch_q();
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
#if BX_DEBUGGER
BX_CPU_THIS_PTR show_flag |= Flag_ret;
#endif
if (BX_CPU_THIS_PTR sregs[BX_SEG_REG_SS].cache.u.segment.d_b) /* 32bit stack */
temp_ESP = ESP;
else
temp_ESP = SP;
if (protected_mode()) {
if ( !can_pop(4) ) {
strip '\n' from BX_{INFO,DEBUG,ERROR,PANIC} don't need it, moved the output of it into the general io functions. saves space, as well as removes the confusing output if a '\n' is left off
2001-05-30 22:56:02 +04:00
BX_PANIC(("retnear: can't pop EIP"));
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
/* ??? #SS(0) -or #GP(0) */
}
access_linear(BX_CPU_THIS_PTR sregs[BX_SEG_REG_SS].cache.u.segment.base + temp_ESP + 0,
4, CPL==3, BX_READ, &return_EIP);
if ( return_EIP > BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].cache.u.segment.limit_scaled ) {
strip '\n' from BX_{INFO,DEBUG,ERROR,PANIC} don't need it, moved the output of it into the general io functions. saves space, as well as removes the confusing output if a '\n' is left off
2001-05-30 22:56:02 +04:00
BX_PANIC(("retnear: EIP > limit"));
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
//exception(BX_GP_EXCEPTION, 0, 0);
}
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
EIP = return_EIP;
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
if (BX_CPU_THIS_PTR sregs[BX_SEG_REG_SS].cache.u.segment.d_b) /* 32bit stack */
ESP += 4;
else
SP += 4;
}
else {
pop_32(&return_EIP);
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
EIP = return_EIP;
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
instrumentation enchancements: * renamed CPU_ID to BX_CPU_ID. with this new name there is no possibility for name contentions and BX_CPU_ID definition could be moved out to NEED_CPU_REG_SHORTCUTS block * returned back `unsigned BX_CPU::which_cpu(void)` function * added BX_CPU_ID parameter for BX_INSTR_PHY_READ(a20addr, len); BX_INSTR_PHY_WRITE(a20addr, len); now it will be BX_INSTR_PHY_READ(cpu_id, a20addr, len); BX_INSTR_PHY_WRITE(cpu_id, a20addr, len);
2003-02-13 18:04:11 +03:00
BX_INSTR_UCNEAR_BRANCH(BX_CPU_ID, BX_INSTR_IS_RET, EIP);
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
void
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
BX_CPU_C::RETfar32_Iw(bxInstruction_c *i)
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
{
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
BailBigRSP("RETfar32_Iw");
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
Bit32u eip, ecs_raw;
Bit16s imm16;
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
invalidate_prefetch_q();
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
#if BX_DEBUGGER
BX_CPU_THIS_PTR show_flag |= Flag_ret;
#endif
/* ??? is imm16, number of bytes/words depending on operandsize ? */
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
imm16 = i->Iw();
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
#if BX_CPU_LEVEL >= 2
if (protected_mode()) {
BX_CPU_THIS_PTR return_protected(i, imm16);
goto done;
}
#endif
pop_32(&eip);
pop_32(&ecs_raw);
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
EIP = eip;
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
load_seg_reg(&BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS], (Bit16u) ecs_raw);
if (BX_CPU_THIS_PTR sregs[BX_SEG_REG_SS].cache.u.segment.d_b)
ESP += imm16;
else
SP += imm16;
done:
instrumentation enchancements: * renamed CPU_ID to BX_CPU_ID. with this new name there is no possibility for name contentions and BX_CPU_ID definition could be moved out to NEED_CPU_REG_SHORTCUTS block * returned back `unsigned BX_CPU::which_cpu(void)` function * added BX_CPU_ID parameter for BX_INSTR_PHY_READ(a20addr, len); BX_INSTR_PHY_WRITE(a20addr, len); now it will be BX_INSTR_PHY_READ(cpu_id, a20addr, len); BX_INSTR_PHY_WRITE(cpu_id, a20addr, len);
2003-02-13 18:04:11 +03:00
BX_INSTR_FAR_BRANCH(BX_CPU_ID, BX_INSTR_IS_RET,
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].selector.value, EIP);
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
void
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
BX_CPU_C::RETfar32(bxInstruction_c *i)
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
{
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
BailBigRSP("RETfar32");
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
Bit32u eip, ecs_raw;
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
invalidate_prefetch_q();
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
#if BX_DEBUGGER
BX_CPU_THIS_PTR show_flag |= Flag_ret;
#endif
#if BX_CPU_LEVEL >= 2
if ( protected_mode() ) {
BX_CPU_THIS_PTR return_protected(i, 0);
goto done;
}
#endif
pop_32(&eip);
pop_32(&ecs_raw); /* 32bit pop, MSW discarded */
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
EIP = eip;
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
load_seg_reg(&BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS], (Bit16u) ecs_raw);
done:
instrumentation enchancements: * renamed CPU_ID to BX_CPU_ID. with this new name there is no possibility for name contentions and BX_CPU_ID definition could be moved out to NEED_CPU_REG_SHORTCUTS block * returned back `unsigned BX_CPU::which_cpu(void)` function * added BX_CPU_ID parameter for BX_INSTR_PHY_READ(a20addr, len); BX_INSTR_PHY_WRITE(a20addr, len); now it will be BX_INSTR_PHY_READ(cpu_id, a20addr, len); BX_INSTR_PHY_WRITE(cpu_id, a20addr, len);
2003-02-13 18:04:11 +03:00
BX_INSTR_FAR_BRANCH(BX_CPU_ID, BX_INSTR_IS_RET,
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].selector.value, EIP);
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
void
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
BX_CPU_C::CALL_Ad(bxInstruction_c *i)
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
{
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
BailBigRSP("CALL_Ad");
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
Bit32u new_EIP;
Bit32s disp32;
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
invalidate_prefetch_q();
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
#if BX_DEBUGGER
BX_CPU_THIS_PTR show_flag |= Flag_call;
#endif
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
disp32 = i->Id();
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
new_EIP = EIP + disp32;
if ( protected_mode() ) {
if ( new_EIP > BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].cache.u.segment.limit_scaled ) {
strip '\n' from BX_{INFO,DEBUG,ERROR,PANIC} don't need it, moved the output of it into the general io functions. saves space, as well as removes the confusing output if a '\n' is left off
2001-05-30 22:56:02 +04:00
BX_PANIC(("call_av: offset outside of CS limits"));
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
exception(BX_GP_EXCEPTION, 0, 0);
}
}
/* push 32 bit EA of next instruction */
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
push_32(EIP);
EIP = new_EIP;
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
instrumentation enchancements: * renamed CPU_ID to BX_CPU_ID. with this new name there is no possibility for name contentions and BX_CPU_ID definition could be moved out to NEED_CPU_REG_SHORTCUTS block * returned back `unsigned BX_CPU::which_cpu(void)` function * added BX_CPU_ID parameter for BX_INSTR_PHY_READ(a20addr, len); BX_INSTR_PHY_WRITE(a20addr, len); now it will be BX_INSTR_PHY_READ(cpu_id, a20addr, len); BX_INSTR_PHY_WRITE(cpu_id, a20addr, len);
2003-02-13 18:04:11 +03:00
BX_INSTR_UCNEAR_BRANCH(BX_CPU_ID, BX_INSTR_IS_CALL, EIP);
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
void
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
BX_CPU_C::CALL32_Ap(bxInstruction_c *i)
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
{
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
BailBigRSP("CALL32_Ap");
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
Bit16u cs_raw;
Bit32u disp32;
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
invalidate_prefetch_q();
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
#if BX_DEBUGGER
BX_CPU_THIS_PTR show_flag |= Flag_call;
#endif
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
disp32 = i->Id();
cs_raw = i->Iw2();
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
if (protected_mode()) {
BX_CPU_THIS_PTR call_protected(i, cs_raw, disp32);
goto done;
}
push_32(BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].selector.value);
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
push_32(EIP);
EIP = disp32;
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
load_seg_reg(&BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS], cs_raw);
done:
instrumentation enchancements: * renamed CPU_ID to BX_CPU_ID. with this new name there is no possibility for name contentions and BX_CPU_ID definition could be moved out to NEED_CPU_REG_SHORTCUTS block * returned back `unsigned BX_CPU::which_cpu(void)` function * added BX_CPU_ID parameter for BX_INSTR_PHY_READ(a20addr, len); BX_INSTR_PHY_WRITE(a20addr, len); now it will be BX_INSTR_PHY_READ(cpu_id, a20addr, len); BX_INSTR_PHY_WRITE(cpu_id, a20addr, len);
2003-02-13 18:04:11 +03:00
BX_INSTR_FAR_BRANCH(BX_CPU_ID, BX_INSTR_IS_CALL,
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].selector.value, EIP);
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
void
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
BX_CPU_C::CALL_Ed(bxInstruction_c *i)
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
{
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
BailBigRSP("CALL_Ed");
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
Bit32u temp_ESP;
Bit32u op1_32;
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
invalidate_prefetch_q();
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
#if BX_DEBUGGER
BX_CPU_THIS_PTR show_flag |= Flag_call;
#endif
if (BX_CPU_THIS_PTR sregs[BX_SEG_REG_SS].cache.u.segment.d_b)
temp_ESP = ESP;
else
temp_ESP = SP;
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
if (i->modC0()) {
op1_32 = BX_READ_32BIT_REG(i->rm());
}
else {
read_virtual_dword(i->seg(), RMAddr(i), &op1_32);
}
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
if (protected_mode()) {
if (op1_32 >
BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].cache.u.segment.limit_scaled) {
exception(BX_GP_EXCEPTION, 0, 0);
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
}
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
push_32(EIP);
EIP = op1_32;
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
instrumentation enchancements: * renamed CPU_ID to BX_CPU_ID. with this new name there is no possibility for name contentions and BX_CPU_ID definition could be moved out to NEED_CPU_REG_SHORTCUTS block * returned back `unsigned BX_CPU::which_cpu(void)` function * added BX_CPU_ID parameter for BX_INSTR_PHY_READ(a20addr, len); BX_INSTR_PHY_WRITE(a20addr, len); now it will be BX_INSTR_PHY_READ(cpu_id, a20addr, len); BX_INSTR_PHY_WRITE(cpu_id, a20addr, len);
2003-02-13 18:04:11 +03:00
BX_INSTR_UCNEAR_BRANCH(BX_CPU_ID, BX_INSTR_IS_CALL, EIP);
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
void
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
BX_CPU_C::CALL32_Ep(bxInstruction_c *i)
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
{
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
BailBigRSP("CALL32_Ep");
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
Bit16u cs_raw;
Bit32u op1_32;
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
invalidate_prefetch_q();
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
#if BX_DEBUGGER
BX_CPU_THIS_PTR show_flag |= Flag_call;
#endif
/* op1_32 is a register or memory reference */
Moved the EFLAGS.RF check and clearing of inhibit_mask code 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.
2002-09-20 07:52:59 +04:00
if (i->modC0()) {
strip '\n' from BX_{INFO,DEBUG,ERROR,PANIC} don't need it, moved the output of it into the general io functions. saves space, as well as removes the confusing output if a '\n' is left off
2001-05-30 22:56:02 +04:00
BX_PANIC(("CALL_Ep: op1 is a register"));
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
/* pointer, segment address pair */
Moved more separate fields in the bxInstruction_c into bitfields 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.
2002-09-18 09:36:48 +04:00
read_virtual_dword(i->seg(), RMAddr(i), &op1_32);
read_virtual_word(i->seg(), RMAddr(i)+4, &cs_raw);
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
if ( protected_mode() ) {
BX_CPU_THIS_PTR call_protected(i, cs_raw, op1_32);
goto done;
}
push_32(BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].selector.value);
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
push_32(EIP);
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
EIP = op1_32;
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
load_seg_reg(&BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS], cs_raw);
done:
instrumentation enchancements: * renamed CPU_ID to BX_CPU_ID. with this new name there is no possibility for name contentions and BX_CPU_ID definition could be moved out to NEED_CPU_REG_SHORTCUTS block * returned back `unsigned BX_CPU::which_cpu(void)` function * added BX_CPU_ID parameter for BX_INSTR_PHY_READ(a20addr, len); BX_INSTR_PHY_WRITE(a20addr, len); now it will be BX_INSTR_PHY_READ(cpu_id, a20addr, len); BX_INSTR_PHY_WRITE(cpu_id, a20addr, len);
2003-02-13 18:04:11 +03:00
BX_INSTR_FAR_BRANCH(BX_CPU_ID, BX_INSTR_IS_CALL,
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].selector.value, EIP);
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
void
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
BX_CPU_C::JMP_Jd(bxInstruction_c *i)
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
{
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
BailBigRSP("JMP_Jd");
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
Bit32u new_EIP;
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
invalidate_prefetch_q();
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
new_EIP = EIP + (Bit32s) i->Id();
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
#if BX_CPU_LEVEL >= 2
if (protected_mode()) {
if ( new_EIP > BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].cache.u.segment.limit_scaled ) {
strip '\n' from BX_{INFO,DEBUG,ERROR,PANIC} don't need it, moved the output of it into the general io functions. saves space, as well as removes the confusing output if a '\n' is left off
2001-05-30 22:56:02 +04:00
BX_PANIC(("jmp_jv: offset outside of CS limits"));
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
exception(BX_GP_EXCEPTION, 0, 0);
}
}
#endif
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
EIP = new_EIP;
instrumentation enchancements: * renamed CPU_ID to BX_CPU_ID. with this new name there is no possibility for name contentions and BX_CPU_ID definition could be moved out to NEED_CPU_REG_SHORTCUTS block * returned back `unsigned BX_CPU::which_cpu(void)` function * added BX_CPU_ID parameter for BX_INSTR_PHY_READ(a20addr, len); BX_INSTR_PHY_WRITE(a20addr, len); now it will be BX_INSTR_PHY_READ(cpu_id, a20addr, len); BX_INSTR_PHY_WRITE(cpu_id, a20addr, len);
2003-02-13 18:04:11 +03:00
BX_INSTR_UCNEAR_BRANCH(BX_CPU_ID, BX_INSTR_IS_JMP, new_EIP);
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
void
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
BX_CPU_C::JCC_Jd(bxInstruction_c *i)
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
{
- Apply patch.replace-Boolean rev 1.3. Every "Boolean" is now changed to a "bx_bool" which is always defined as Bit32u on all platforms. In Carbon specific code, Boolean is still used because the Carbon header files define it to unsigned char. - this fixes bug [ 623152 ] MacOSX: Triple Exception Booting win95. The bug was that some code in Bochs depends on Boolean to be a 32 bit value. (This should be fixed, but I don't know all the places where it needs to be fixed yet.) Because Carbon defined Boolean as an unsigned char, Bochs just followed along and used the unsigned char definition to avoid compile problems. This exposed the dependency on 32 bit Boolean on MacOS X only and led to major simulation problems, that could only be reproduced and debugged on that platform. - On the mailing list we debated whether to make all Booleans into "bool" or our own type. I chose bx_bool for several reasons. 1. Unlike C++'s bool, we can guarantee that bx_bool is the same size on all platforms, which makes it much less likely to have more platform-specific simulation differences in the future. (I spent hours on a borrowed MacOSX machine chasing bug 618388 before discovering that different sized Booleans were the problem, and I don't want to repeat that.) 2. We still have at least one dependency on 32 bit Booleans which must be fixed some time, but I don't want to risk introducing new bugs into the simulation just before the 2.0 release. Modified Files: bochs.h config.h.in gdbstub.cc logio.cc main.cc pc_system.cc pc_system.h plugin.cc plugin.h bios/rombios.c cpu/apic.cc cpu/arith16.cc cpu/arith32.cc cpu/arith64.cc cpu/arith8.cc cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer16.cc cpu/ctrl_xfer32.cc cpu/ctrl_xfer64.cc cpu/data_xfer16.cc cpu/data_xfer32.cc cpu/data_xfer64.cc cpu/debugstuff.cc cpu/exception.cc cpu/fetchdecode.cc cpu/flag_ctrl_pro.cc cpu/init.cc cpu/io_pro.cc cpu/lazy_flags.cc cpu/lazy_flags.h cpu/mult16.cc cpu/mult32.cc cpu/mult64.cc cpu/mult8.cc cpu/paging.cc cpu/proc_ctrl.cc cpu/segment_ctrl_pro.cc cpu/stack_pro.cc cpu/tasking.cc debug/dbg_main.cc debug/debug.h debug/sim2.cc disasm/dis_decode.cc disasm/disasm.h doc/docbook/Makefile docs-html/cosimulation.html fpu/wmFPUemu_glue.cc gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/gui.cc gui/gui.h gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc gui/rfb.cc gui/sdl.cc gui/siminterface.cc gui/siminterface.h gui/term.cc gui/win32.cc gui/wx.cc gui/wxmain.cc gui/wxmain.h gui/x.cc instrument/example0/instrument.cc instrument/example0/instrument.h instrument/example1/instrument.cc instrument/example1/instrument.h instrument/stubs/instrument.cc instrument/stubs/instrument.h iodev/cdrom.cc iodev/cdrom.h iodev/cdrom_osx.cc iodev/cmos.cc iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_arpback.cc iodev/eth_packetmaker.cc iodev/eth_packetmaker.h iodev/floppy.cc iodev/floppy.h iodev/guest2host.h iodev/harddrv.cc iodev/harddrv.h iodev/ioapic.cc iodev/ioapic.h iodev/iodebug.cc iodev/iodev.h iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.h iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pic.h iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h iodev/sb16.cc iodev/sb16.h iodev/serial.cc iodev/serial.h iodev/vga.cc iodev/vga.h memory/memory.h memory/misc_mem.cc
2002-10-25 15:44:41 +04:00
bx_bool condition;
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
Converted all the remaining available separate fields in bxInstruction_c 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.
2002-09-18 12:00:43 +04:00
switch (i->b1() & 0x0f) {
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
case 0x00: /* JO */ condition = get_OF(); break;
case 0x01: /* JNO */ condition = !get_OF(); break;
case 0x02: /* JB */ condition = get_CF(); break;
case 0x03: /* JNB */ condition = !get_CF(); break;
case 0x04: /* JZ */ condition = get_ZF(); break;
case 0x05: /* JNZ */ condition = !get_ZF(); break;
case 0x06: /* JBE */ condition = get_CF() || get_ZF(); break;
case 0x07: /* JNBE */ condition = !get_CF() && !get_ZF(); break;
case 0x08: /* JS */ condition = get_SF(); break;
case 0x09: /* JNS */ condition = !get_SF(); break;
case 0x0A: /* JP */ condition = get_PF(); break;
case 0x0B: /* JNP */ condition = !get_PF(); break;
Changed eflags accessors for get_?F() to use (val32 & (1<<N)) instead of (1 & (val32>>N)), and added a getB_?F() accessor for special cases which need a strict binary value (exactly 0 or 1). Most code only needed a value for logical comparison. I modified the special cases which do need a binary number for shifting and comparison between flags, to use the special getB_?F() accessor. Cleaned up memory.cc functions a little, now that all accesses are within a single page. Fixed a (not very likely encountered) bug in fetchdecode.cc (and fetchdecode64.cc) where a 2-byte opcode starting with a prefix starts at the last offset on a page. There were no checks on the segment overrides for a boundary condition. I added them. The eflags enhancements added just a tiny bit of performance.
2002-09-22 22:22:24 +04:00
case 0x0C: /* JL */ condition = getB_SF() != getB_OF(); break;
case 0x0D: /* JNL */ condition = getB_SF() == getB_OF(); break;
case 0x0E: /* JLE */ condition = get_ZF() || (getB_SF() != getB_OF());
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
break;
Changed eflags accessors for get_?F() to use (val32 & (1<<N)) instead of (1 & (val32>>N)), and added a getB_?F() accessor for special cases which need a strict binary value (exactly 0 or 1). Most code only needed a value for logical comparison. I modified the special cases which do need a binary number for shifting and comparison between flags, to use the special getB_?F() accessor. Cleaned up memory.cc functions a little, now that all accesses are within a single page. Fixed a (not very likely encountered) bug in fetchdecode.cc (and fetchdecode64.cc) where a 2-byte opcode starting with a prefix starts at the last offset on a page. There were no checks on the segment overrides for a boundary condition. I added them. The eflags enhancements added just a tiny bit of performance.
2002-09-22 22:22:24 +04:00
case 0x0F: /* JNLE */ condition = (getB_SF() == getB_OF()) &&
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
!get_ZF();
break;
Split out JZ/JNZ instructions from JCC because they were called so frequently. Coded asm() statements for INC/DEC_ERX() instructions. Cleaned up the iCache a litle including a bug fix. The generation ID was decrementing the whole field including some high meta bits. That could roll over after 1 Billion cycles. I know only decrement if the field is valid, to save the write. I implemented inline functions which can serve the value of the arithmetic flags if they are cached, and redirect to the lazy_flags.cc routines if not. Most of this was just prep work for adding more asm() statements for native eflags processing when on x86.
2002-09-22 05:52:21 +04:00
default:
condition = 0; // For compiler...all targets should set condition.
break;
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
if (condition) {
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
BailBigRSP("JCC_Jd");
Got rid of the KPL64Hacks macro. The fixes below eliminated it. Created 64-bit versions of some branch instructions and changed fetchdecode64.cc to use them instead. This keeps the #ifdef pollution down for 32-bit code and made fixing them easier. They needed to clear the upper bits of RIP for 16-bit operand sizes. They also should not have had a protection limit check in them, especially since that field is still 32-bit in cpu.h, so there's no way to set nominal 64-bit values. The 32-bit versions were also not honoring the upper 32-bits of RIP. LOOPNE64_Jb LOOPE64_Jb LOOP64_Jb JCXZ64_Jb Changed all occurances of JCC_Jw/JCC_Jd in fetchdecode64.cc to use JCC_Jq, which was coded already. Both JMP_Jq and JCC_Jq are now fixed w.r.t. 16-bit opsizes and upper RIP bit clearing.
2002-09-27 11:01:02 +04:00
Bit32u new_EIP;
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
Got rid of the KPL64Hacks macro. The fixes below eliminated it. Created 64-bit versions of some branch instructions and changed fetchdecode64.cc to use them instead. This keeps the #ifdef pollution down for 32-bit code and made fixing them easier. They needed to clear the upper bits of RIP for 16-bit operand sizes. They also should not have had a protection limit check in them, especially since that field is still 32-bit in cpu.h, so there's no way to set nominal 64-bit values. The 32-bit versions were also not honoring the upper 32-bits of RIP. LOOPNE64_Jb LOOPE64_Jb LOOP64_Jb JCXZ64_Jb Changed all occurances of JCC_Jw/JCC_Jd in fetchdecode64.cc to use JCC_Jq, which was coded already. Both JMP_Jq and JCC_Jq are now fixed w.r.t. 16-bit opsizes and upper RIP bit clearing.
2002-09-27 11:01:02 +04:00
new_EIP = EIP + (Bit32s) i->Id();
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
#if BX_CPU_LEVEL >= 2
Got rid of the KPL64Hacks macro. The fixes below eliminated it. Created 64-bit versions of some branch instructions and changed fetchdecode64.cc to use them instead. This keeps the #ifdef pollution down for 32-bit code and made fixing them easier. They needed to clear the upper bits of RIP for 16-bit operand sizes. They also should not have had a protection limit check in them, especially since that field is still 32-bit in cpu.h, so there's no way to set nominal 64-bit values. The 32-bit versions were also not honoring the upper 32-bits of RIP. LOOPNE64_Jb LOOPE64_Jb LOOP64_Jb JCXZ64_Jb Changed all occurances of JCC_Jw/JCC_Jd in fetchdecode64.cc to use JCC_Jq, which was coded already. Both JMP_Jq and JCC_Jq are now fixed w.r.t. 16-bit opsizes and upper RIP bit clearing.
2002-09-27 11:01:02 +04:00
if (protected_mode()) {
if ( new_EIP >
BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].cache.u.segment.limit_scaled )
{
BX_PANIC(("jo_routine: offset outside of CS limits"));
exception(BX_GP_EXCEPTION, 0, 0);
Split out JZ/JNZ instructions from JCC because they were called so frequently. Coded asm() statements for INC/DEC_ERX() instructions. Cleaned up the iCache a litle including a bug fix. The generation ID was decrementing the whole field including some high meta bits. That could roll over after 1 Billion cycles. I know only decrement if the field is valid, to save the write. I implemented inline functions which can serve the value of the arithmetic flags if they are cached, and redirect to the lazy_flags.cc routines if not. Most of this was just prep work for adding more asm() statements for native eflags processing when on x86.
2002-09-22 05:52:21 +04:00
}
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
}
Got rid of the KPL64Hacks macro. The fixes below eliminated it. Created 64-bit versions of some branch instructions and changed fetchdecode64.cc to use them instead. This keeps the #ifdef pollution down for 32-bit code and made fixing them easier. They needed to clear the upper bits of RIP for 16-bit operand sizes. They also should not have had a protection limit check in them, especially since that field is still 32-bit in cpu.h, so there's no way to set nominal 64-bit values. The 32-bit versions were also not honoring the upper 32-bits of RIP. LOOPNE64_Jb LOOPE64_Jb LOOP64_Jb JCXZ64_Jb Changed all occurances of JCC_Jw/JCC_Jd in fetchdecode64.cc to use JCC_Jq, which was coded already. Both JMP_Jq and JCC_Jq are now fixed w.r.t. 16-bit opsizes and upper RIP bit clearing.
2002-09-27 11:01:02 +04:00
#endif
EIP = new_EIP;
instrumentation enchancements: * renamed CPU_ID to BX_CPU_ID. with this new name there is no possibility for name contentions and BX_CPU_ID definition could be moved out to NEED_CPU_REG_SHORTCUTS block * returned back `unsigned BX_CPU::which_cpu(void)` function * added BX_CPU_ID parameter for BX_INSTR_PHY_READ(a20addr, len); BX_INSTR_PHY_WRITE(a20addr, len); now it will be BX_INSTR_PHY_READ(cpu_id, a20addr, len); BX_INSTR_PHY_WRITE(cpu_id, a20addr, len);
2003-02-13 18:04:11 +03:00
BX_INSTR_CNEAR_BRANCH_TAKEN(BX_CPU_ID, new_EIP);
Split out JZ/JNZ instructions from JCC because they were called so frequently. Coded asm() statements for INC/DEC_ERX() instructions. Cleaned up the iCache a litle including a bug fix. The generation ID was decrementing the whole field including some high meta bits. That could roll over after 1 Billion cycles. I know only decrement if the field is valid, to save the write. I implemented inline functions which can serve the value of the arithmetic flags if they are cached, and redirect to the lazy_flags.cc routines if not. Most of this was just prep work for adding more asm() statements for native eflags processing when on x86.
2002-09-22 05:52:21 +04:00
revalidate_prefetch_q();
}
#if BX_INSTRUMENTATION
else {
instrumentation enchancements: * renamed CPU_ID to BX_CPU_ID. with this new name there is no possibility for name contentions and BX_CPU_ID definition could be moved out to NEED_CPU_REG_SHORTCUTS block * returned back `unsigned BX_CPU::which_cpu(void)` function * added BX_CPU_ID parameter for BX_INSTR_PHY_READ(a20addr, len); BX_INSTR_PHY_WRITE(a20addr, len); now it will be BX_INSTR_PHY_READ(cpu_id, a20addr, len); BX_INSTR_PHY_WRITE(cpu_id, a20addr, len);
2003-02-13 18:04:11 +03:00
BX_INSTR_CNEAR_BRANCH_NOT_TAKEN(BX_CPU_ID);
Split out JZ/JNZ instructions from JCC because they were called so frequently. Coded asm() statements for INC/DEC_ERX() instructions. Cleaned up the iCache a litle including a bug fix. The generation ID was decrementing the whole field including some high meta bits. That could roll over after 1 Billion cycles. I know only decrement if the field is valid, to save the write. I implemented inline functions which can serve the value of the arithmetic flags if they are cached, and redirect to the lazy_flags.cc routines if not. Most of this was just prep work for adding more asm() statements for native eflags processing when on x86.
2002-09-22 05:52:21 +04:00
}
#endif
}
void
BX_CPU_C::JZ_Jd(bxInstruction_c *i)
{
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
BailBigRSP("JZ_Jd");
Split out JZ/JNZ instructions from JCC because they were called so frequently. Coded asm() statements for INC/DEC_ERX() instructions. Cleaned up the iCache a litle including a bug fix. The generation ID was decrementing the whole field including some high meta bits. That could roll over after 1 Billion cycles. I know only decrement if the field is valid, to save the write. I implemented inline functions which can serve the value of the arithmetic flags if they are cached, and redirect to the lazy_flags.cc routines if not. Most of this was just prep work for adding more asm() statements for native eflags processing when on x86.
2002-09-22 05:52:21 +04:00
if (get_ZF()) {
Bit32u new_EIP;
new_EIP = EIP + (Bit32s) i->Id();
#if BX_CPU_LEVEL >= 2
if (protected_mode()) {
if ( new_EIP >
BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].cache.u.segment.limit_scaled ) {
BX_PANIC(("jo_routine: offset outside of CS limits"));
exception(BX_GP_EXCEPTION, 0, 0);
}
}
#endif
EIP = new_EIP;
instrumentation enchancements: * renamed CPU_ID to BX_CPU_ID. with this new name there is no possibility for name contentions and BX_CPU_ID definition could be moved out to NEED_CPU_REG_SHORTCUTS block * returned back `unsigned BX_CPU::which_cpu(void)` function * added BX_CPU_ID parameter for BX_INSTR_PHY_READ(a20addr, len); BX_INSTR_PHY_WRITE(a20addr, len); now it will be BX_INSTR_PHY_READ(cpu_id, a20addr, len); BX_INSTR_PHY_WRITE(cpu_id, a20addr, len);
2003-02-13 18:04:11 +03:00
BX_INSTR_CNEAR_BRANCH_TAKEN(BX_CPU_ID, new_EIP);
Split out JZ/JNZ instructions from JCC because they were called so frequently. Coded asm() statements for INC/DEC_ERX() instructions. Cleaned up the iCache a litle including a bug fix. The generation ID was decrementing the whole field including some high meta bits. That could roll over after 1 Billion cycles. I know only decrement if the field is valid, to save the write. I implemented inline functions which can serve the value of the arithmetic flags if they are cached, and redirect to the lazy_flags.cc routines if not. Most of this was just prep work for adding more asm() statements for native eflags processing when on x86.
2002-09-22 05:52:21 +04:00
revalidate_prefetch_q();
}
#if BX_INSTRUMENTATION
else {
instrumentation enchancements: * renamed CPU_ID to BX_CPU_ID. with this new name there is no possibility for name contentions and BX_CPU_ID definition could be moved out to NEED_CPU_REG_SHORTCUTS block * returned back `unsigned BX_CPU::which_cpu(void)` function * added BX_CPU_ID parameter for BX_INSTR_PHY_READ(a20addr, len); BX_INSTR_PHY_WRITE(a20addr, len); now it will be BX_INSTR_PHY_READ(cpu_id, a20addr, len); BX_INSTR_PHY_WRITE(cpu_id, a20addr, len);
2003-02-13 18:04:11 +03:00
BX_INSTR_CNEAR_BRANCH_NOT_TAKEN(BX_CPU_ID);
Split out JZ/JNZ instructions from JCC because they were called so frequently. Coded asm() statements for INC/DEC_ERX() instructions. Cleaned up the iCache a litle including a bug fix. The generation ID was decrementing the whole field including some high meta bits. That could roll over after 1 Billion cycles. I know only decrement if the field is valid, to save the write. I implemented inline functions which can serve the value of the arithmetic flags if they are cached, and redirect to the lazy_flags.cc routines if not. Most of this was just prep work for adding more asm() statements for native eflags processing when on x86.
2002-09-22 05:52:21 +04:00
}
#endif
}
void
BX_CPU_C::JNZ_Jd(bxInstruction_c *i)
{
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
BailBigRSP("JNZ_Jd");
Split out JZ/JNZ instructions from JCC because they were called so frequently. Coded asm() statements for INC/DEC_ERX() instructions. Cleaned up the iCache a litle including a bug fix. The generation ID was decrementing the whole field including some high meta bits. That could roll over after 1 Billion cycles. I know only decrement if the field is valid, to save the write. I implemented inline functions which can serve the value of the arithmetic flags if they are cached, and redirect to the lazy_flags.cc routines if not. Most of this was just prep work for adding more asm() statements for native eflags processing when on x86.
2002-09-22 05:52:21 +04:00
if (!get_ZF()) {
Bit32u new_EIP;
new_EIP = EIP + (Bit32s) i->Id();
#if BX_CPU_LEVEL >= 2
if (protected_mode()) {
if ( new_EIP >
BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].cache.u.segment.limit_scaled ) {
strip '\n' from BX_{INFO,DEBUG,ERROR,PANIC} don't need it, moved the output of it into the general io functions. saves space, as well as removes the confusing output if a '\n' is left off
2001-05-30 22:56:02 +04:00
BX_PANIC(("jo_routine: offset outside of CS limits"));
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
exception(BX_GP_EXCEPTION, 0, 0);
}
}
#endif
EIP = new_EIP;
instrumentation enchancements: * renamed CPU_ID to BX_CPU_ID. with this new name there is no possibility for name contentions and BX_CPU_ID definition could be moved out to NEED_CPU_REG_SHORTCUTS block * returned back `unsigned BX_CPU::which_cpu(void)` function * added BX_CPU_ID parameter for BX_INSTR_PHY_READ(a20addr, len); BX_INSTR_PHY_WRITE(a20addr, len); now it will be BX_INSTR_PHY_READ(cpu_id, a20addr, len); BX_INSTR_PHY_WRITE(cpu_id, a20addr, len);
2003-02-13 18:04:11 +03:00
BX_INSTR_CNEAR_BRANCH_TAKEN(BX_CPU_ID, new_EIP);
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
revalidate_prefetch_q();
}
#if BX_INSTRUMENTATION
else {
instrumentation enchancements: * renamed CPU_ID to BX_CPU_ID. with this new name there is no possibility for name contentions and BX_CPU_ID definition could be moved out to NEED_CPU_REG_SHORTCUTS block * returned back `unsigned BX_CPU::which_cpu(void)` function * added BX_CPU_ID parameter for BX_INSTR_PHY_READ(a20addr, len); BX_INSTR_PHY_WRITE(a20addr, len); now it will be BX_INSTR_PHY_READ(cpu_id, a20addr, len); BX_INSTR_PHY_WRITE(cpu_id, a20addr, len);
2003-02-13 18:04:11 +03:00
BX_INSTR_CNEAR_BRANCH_NOT_TAKEN(BX_CPU_ID);
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
#endif
}
void
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
BX_CPU_C::JMP_Ap(bxInstruction_c *i)
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
{
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
BailBigRSP("JMP_Ap");
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
Bit32u disp32;
Bit16u cs_raw;
invalidate_prefetch_q();
Moved more separate fields in the bxInstruction_c into bitfields 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.
2002-09-18 09:36:48 +04:00
if (i->os32L()) {
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
disp32 = i->Id();
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
else {
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
disp32 = i->Iw();
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
cs_raw = i->Iw2();
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
#if BX_CPU_LEVEL >= 2
if (protected_mode()) {
BX_CPU_THIS_PTR jump_protected(i, cs_raw, disp32);
goto done;
}
#endif
load_seg_reg(&BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS], cs_raw);
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
EIP = disp32;
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
done:
instrumentation enchancements: * renamed CPU_ID to BX_CPU_ID. with this new name there is no possibility for name contentions and BX_CPU_ID definition could be moved out to NEED_CPU_REG_SHORTCUTS block * returned back `unsigned BX_CPU::which_cpu(void)` function * added BX_CPU_ID parameter for BX_INSTR_PHY_READ(a20addr, len); BX_INSTR_PHY_WRITE(a20addr, len); now it will be BX_INSTR_PHY_READ(cpu_id, a20addr, len); BX_INSTR_PHY_WRITE(cpu_id, a20addr, len);
2003-02-13 18:04:11 +03:00
BX_INSTR_FAR_BRANCH(BX_CPU_ID, BX_INSTR_IS_JMP,
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].selector.value, EIP);
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
void
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
BX_CPU_C::JMP_Ed(bxInstruction_c *i)
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
{
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
BailBigRSP("JMP_Ed");
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
Bit32u new_EIP;
Bit32u op1_32;
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
invalidate_prefetch_q();
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
/* op1_32 is a register or memory reference */
Moved the EFLAGS.RF check and clearing of inhibit_mask code 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.
2002-09-20 07:52:59 +04:00
if (i->modC0()) {
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
op1_32 = BX_READ_32BIT_REG(i->rm());
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
else {
/* pointer, segment address pair */
Moved more separate fields in the bxInstruction_c into bitfields 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.
2002-09-18 09:36:48 +04:00
read_virtual_dword(i->seg(), RMAddr(i), &op1_32);
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
new_EIP = op1_32;
#if BX_CPU_LEVEL >= 2
if (protected_mode()) {
if (new_EIP > BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].cache.u.segment.limit_scaled) {
strip '\n' from BX_{INFO,DEBUG,ERROR,PANIC} don't need it, moved the output of it into the general io functions. saves space, as well as removes the confusing output if a '\n' is left off
2001-05-30 22:56:02 +04:00
BX_PANIC(("jmp_ev: IP out of CS limits!"));
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
exception(BX_GP_EXCEPTION, 0, 0);
}
}
#endif
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
EIP = new_EIP;
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
instrumentation enchancements: * renamed CPU_ID to BX_CPU_ID. with this new name there is no possibility for name contentions and BX_CPU_ID definition could be moved out to NEED_CPU_REG_SHORTCUTS block * returned back `unsigned BX_CPU::which_cpu(void)` function * added BX_CPU_ID parameter for BX_INSTR_PHY_READ(a20addr, len); BX_INSTR_PHY_WRITE(a20addr, len); now it will be BX_INSTR_PHY_READ(cpu_id, a20addr, len); BX_INSTR_PHY_WRITE(cpu_id, a20addr, len);
2003-02-13 18:04:11 +03:00
BX_INSTR_UCNEAR_BRANCH(BX_CPU_ID, BX_INSTR_IS_JMP, new_EIP);
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
/* Far indirect jump */
void
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
BX_CPU_C::JMP32_Ep(bxInstruction_c *i)
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
{
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
BailBigRSP("JMP32_Ep");
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
Bit16u cs_raw;
Bit32u op1_32;
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
invalidate_prefetch_q();
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
/* op1_32 is a register or memory reference */
Moved the EFLAGS.RF check and clearing of inhibit_mask code 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.
2002-09-20 07:52:59 +04:00
if (i->modC0()) {
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
/* far indirect must specify a memory address */
strip '\n' from BX_{INFO,DEBUG,ERROR,PANIC} don't need it, moved the output of it into the general io functions. saves space, as well as removes the confusing output if a '\n' is left off
2001-05-30 22:56:02 +04:00
BX_PANIC(("JMP_Ep(): op1 is a register"));
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
/* pointer, segment address pair */
Moved more separate fields in the bxInstruction_c into bitfields 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.
2002-09-18 09:36:48 +04:00
read_virtual_dword(i->seg(), RMAddr(i), &op1_32);
read_virtual_word(i->seg(), RMAddr(i)+4, &cs_raw);
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
if ( protected_mode() ) {
BX_CPU_THIS_PTR jump_protected(i, cs_raw, op1_32);
goto done;
}
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
EIP = op1_32;
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
load_seg_reg(&BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS], cs_raw);
done:
instrumentation enchancements: * renamed CPU_ID to BX_CPU_ID. with this new name there is no possibility for name contentions and BX_CPU_ID definition could be moved out to NEED_CPU_REG_SHORTCUTS block * returned back `unsigned BX_CPU::which_cpu(void)` function * added BX_CPU_ID parameter for BX_INSTR_PHY_READ(a20addr, len); BX_INSTR_PHY_WRITE(a20addr, len); now it will be BX_INSTR_PHY_READ(cpu_id, a20addr, len); BX_INSTR_PHY_WRITE(cpu_id, a20addr, len);
2003-02-13 18:04:11 +03:00
BX_INSTR_FAR_BRANCH(BX_CPU_ID, BX_INSTR_IS_JMP,
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].selector.value, EIP);
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
void
Updated accessing of modrm/sib addressing information to 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.
2002-09-18 02:50:53 +04:00
BX_CPU_C::IRET32(bxInstruction_c *i)
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
{
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
BailBigRSP("IRET32");
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
Bit32u eip, ecs_raw, eflags;
I integrated my hacks to get Linux/x86-64 booting. To keep 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.
2002-09-24 04:44:56 +04:00
invalidate_prefetch_q();
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
#if BX_DEBUGGER
BX_CPU_THIS_PTR show_flag |= Flag_iret;
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
BX_CPU_THIS_PTR show_eip = EIP;
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
#endif
if (v8086_mode()) {
// IOPL check in stack_return_from_v86()
stack_return_from_v86(i);
goto done;
}
#if BX_CPU_LEVEL >= 2
if (BX_CPU_THIS_PTR cr0.pe) {
iret_protected(i);
goto done;
}
#endif
- clean up ^M pollution from working in cygwin
2002-09-16 21:00:16 +04:00
BX_ERROR(("IRET32 called when you're not in vm8086 mode or protected mode."));
BX_ERROR(("IRET32 may not be implemented right, since it doesn't check anything."));
BX_PANIC(("Please report that you have found a test case for BX_CPU_C::IRET32."));
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
pop_32(&eip);
pop_32(&ecs_raw);
pop_32(&eflags);
load_seg_reg(&BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS], (Bit16u) ecs_raw);
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
EIP = eip;
Added a comment on iret flag writing.
2002-02-22 08:33:36 +03:00
//FIXME: this should do (eflags & 0x257FD5) | (EFLAGS | 0x1A0000)
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
write_eflags(eflags, /* change IOPL? */ 1, /* change IF? */ 1, 0, 1);
done:
instrumentation enchancements: * renamed CPU_ID to BX_CPU_ID. with this new name there is no possibility for name contentions and BX_CPU_ID definition could be moved out to NEED_CPU_REG_SHORTCUTS block * returned back `unsigned BX_CPU::which_cpu(void)` function * added BX_CPU_ID parameter for BX_INSTR_PHY_READ(a20addr, len); BX_INSTR_PHY_WRITE(a20addr, len); now it will be BX_INSTR_PHY_READ(cpu_id, a20addr, len); BX_INSTR_PHY_WRITE(cpu_id, a20addr, len);
2003-02-13 18:04:11 +03:00
BX_INSTR_FAR_BRANCH(BX_CPU_ID, BX_INSTR_IS_IRET,
I merged the cpu/cpu.h and cpu64/cpu.h files as well as the other header files. There no longer are any *.h files in cpu64/. Had to make some changes to the *.cc files for dealing with accesses to eip.
2002-09-13 04:15:23 +04:00
BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].selector.value, EIP);
- entered original Bochs snapshot bochs-2000_0325a.tar.gz from ftp.bochs.com
2001-04-10 05:04:59 +04:00
}
Reference in New Issue Copy Permalink