Commit Graph

118 Commits

Author SHA1 Message Date
Kevin Lawton
b742ccec7e 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 18:22:24 +00:00
Kevin Lawton
93d05990cc Updated CR4 to use the patented Bryce bitfields accessor method for
both cpu32 and cpu64, to make upcoming merging easier, and the
code cleaner.  Compiled for debug as well, and fixed CR4 for that
also.
2002-09-14 19:21:41 +00:00
Kevin Lawton
bbb20f5d49 Got rid of get_bit{1,3,5,15} accessors to EFLAGS. They were
only used by the debug functions, and those can get the
entire eflags value in one shot now.
2002-09-13 05:03:37 +00:00
Kevin Lawton
6655634179 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 00:15:23 +00:00
Bryce Denney
5fc31bcfda - this revision changes the way eflags are accessed throughout the cpu and
cpu64 directories.  Instead of using the macros introduced in cpu.h rev 1.37
  such as GetEFlagsDFLogical and SetEFlagsDF and ClearEFlagsDF, I made inline
  methods on the BX_CPU_C object that access the eflags fields.  The problem
  with the macros is that they cannot be used outside the BX_CPU_C object.  The
  macros have now been removed, and all references to eflags now use these new
  accessors.
- I debated whether to put the accessors as members of the BX_CPU_C object
  or members of the bx_flags_reg_t struct.  I chose to make them members
  of BX_CPU_C for two reasons: 1. the lazy flags are implemented as
  members of BX_CPU_C, and 2. the eflags are referenced in many many places
  and it is more compact without having to put eflags in front of each.  (The
  real problem with compactness is having to write BX_CPU_THIS_PTR in front of
  everything, but that's another story.)
- Kevin pointed out a major bug in my set accessor code.  What a difference a
  little tilde can make!  That is fixed now.
- modified: load32bitOShack.cc debug/dbg_main.cc
  and in both cpu and cpu64 directories:
    cpu.cc cpu.h ctrl_xfer_pro.cc debugstuff.cc exception.cc flag_ctrl.cc
    flag_ctrl_pro.cc init.cc io.cc io_pro.cc proc_ctrl.cc soft_int.cc
    string.cc vm8086.cc
2002-09-12 18:10:46 +00:00
Bryce Denney
450070850b - the debugger was broken by recent changes in the cpu flags. To provide
a consistent way of accessing these flags that works both inside and
  outside the BX_CPU class, I added inline accessor methods for each
  flag: assert_FLAG(), clear_FLAG(), set_FLAG(value), and get_FLAG ()
  that returns its value.  I use assert to mean "set the value to one"
  to avoid confusion, since there's also a set method that takes a value.
- the eflags access macros (e.g. GetEFlagsDFLogical, ClearEFlagsTF) are
  now defined in terms of the inline accessors.  In most cases it will
  result in the same code anyway.  The major advantage of the accesors
  is that they can be used from inside or outside the BX_CPU object, while
  the macros can only be used from inside.
- since almost all eflags were stored in val32 now, I went ahead and
  removed the if_, rf, and vm fields.  Now the val32 bit is the
  "official" value for these flags, and they have accessors just like
  everything else.
- init.cc: move the registration of registers until after they have been
  initialized so that the initial value of each parameter is correct.

Modified files:
  debug/dbg_main.cc cpu/cpu.h cpu/debugstuff.cc cpu/flag_ctrl.cc
  cpu/flag_ctrl_pro.cc cpu/init.cc
2002-09-11 03:55:22 +00:00
Kevin Lawton
0d7a5fdf3c I rehashed the way the EFLAGS register was stored internally.
All the EFLAGS bits used to be cached in separate fields.  I left
a few of them in separate fields for now - might remove them
at some point also.  When the arithmetic fields are known
(ie they're not in lazy mode), they are all cached in a
32-bit EFLAGS image, just like the x86 EFLAGS register expects.
All other eflags are store in the 32-bit register also, with
a few also mirrored in separate fields for now.

The reason I did this, was so that on x86 hosts, asm() statements
can be #ifdef'd in to do the calculation and get the native
eflags results very cheaply.  Just to test that it works, I
coded ADD_EdId() and ADD_EwIw() with some conditionally compiled
asm()s for accelerated eflags processing and it works.

-Kevin
2002-09-08 04:08:14 +00:00
Bryce Denney
b86dbe1f3c - committed patches/patch.no-busy-in-tr-cache. I'm leaving the patch
lying around for a while in case it needs to be reverted.
2001-10-09 21:15:14 +00:00
Bryce Denney
daf2a9fb55 - 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 13:10:38 +00:00
Bryce Denney
6a1c01c8b5 - back out my poorly written patch.virtual-address-checks-overflow 2001-10-02 20:01:29 +00:00
Bryce Denney
67ebaaca87 - apply patch.virtual-addr-checks-overflow to fix bug
[ #433759 ] virtual address checks can overflow
  > Bochs has been crashing in some cases when you try to access data which
  > overlaps the segment limit, when the segment limit is near the 32-bit
  > boundary.  The example that came up a few times is reading/writing 4 bytes
  > starting at 0xffffffff when the segment limit was 0xffffffff.  The
  > condition used to compare offset+length-1 with the limit, but
  > offset+length-1 was overflowing so the comparison went wrong.  This patch
  > changes the condition so that it supports all segment limits except for
  > sizes 0,1,2,3 bytes.  Dave and I figured that these sizes would not be
  > needed, while size 0xffffffff is used quite a lot.
2001-10-02 17:02:28 +00:00
Todd T.Fries
2bbb1ef8eb 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 18:56:02 +00:00
Todd T.Fries
0b613932ac remove redundant 2001-05-25 15:06:45 +00:00
Bryce Denney
49664f7503 - 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 18:46:34 +00:00
Bryce Denney
e61d00351f - merged BRANCH-smp-bochs into main branch. For details see comments
in BRANCH-smp-bochs revisions.
- The general task was to make multiple CPU's which communicate
  through their APICs.  So instead of BX_CPU and BX_MEM, we now have
  BX_CPU(x) and BX_MEM(y).  For an SMP simulation you have several
  processors in a shared memory space, so there might be processors
  BX_CPU(0..3) but only one memory space BX_MEM(0).  For cosimulation,
  you could have BX_CPU(0) with BX_MEM(0), then BX_CPU(1) with
  BX_MEM(1).  WARNING: Cosimulation is almost certainly broken by the
  SMP changes.
- to simulate multiple CPUs, you have to give each CPU time to execute
  in turn.  This is currently implemented using debugger guards.  The
  cpu loop steps one CPU for a few instructions, then steps the
  next CPU for a few instructions, etc.
- there is some limited support in the debugger for two CPUs, for
  example printing information from each CPU when single stepping.
2001-05-23 08:16:07 +00:00
Todd T.Fries
bdb89cd364 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 14:49:57 +00:00
Bryce Denney
a6fef54678 - update copyright dates to 2001 for all mandrake headers
- for bochs files with other header, replaced with current mandrake header
2001-04-10 02:20:02 +00:00
cvs
beff63eb32 - entered original Bochs snapshot bochs-2000_0325a.tar.gz from
ftp.bochs.com
2001-04-10 01:04:59 +00:00