Commit Graph

380 Commits

Author SHA1 Message Date
Bryce Denney
15a3cbc35f - make cpu_param_handler compile with SMP enabled. Unfortunately it will
read all param values from CPU #0.  The only solution I can come up with
  is to change the siminterface handler function interface to pass a void*
  to the callback function.  I'll take care of it eventually.
2002-09-18 04:32:16 +00:00
Kevin Lawton
80dd7a07ec Removed references to building libextdb.a. It doesn't seem to
be used at all, and Peter didn't want it.  "extdb.o" is compiled
into libcpu.a, if configured for it.

Removed a few #warnings for x86-64 compile, based on Peter's
line-item comments regarding the warnings I inserted during
the port/merge.
2002-09-15 15:10:21 +00:00
Bryce Denney
03bb4c1c92 - update wxwindows param for cr4, since it's changed into a structure 2002-09-15 11:01:36 +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
c24ef050e1 (cpu64) Merged init.cc. 2002-09-14 00:51:46 +00:00
Bryce Denney
565b3846c9 - add infrastructure for sending commands from the wxWindows interface to the
Bochs debugger.  The Bochs debugger calls SIM->debug_get_next_command() which
  does not return until a debugger command is found.  The siminterface sends an
  synchronous event to the wxWindows thread with a blank to be filled in with a
  debugger command.  wxWindows fills in the blank and sends the synchronous
  event back, and the Bochs debugger interprets it as if it was typed on
  the command line.  For the long term I haven't decided whether to stick with
  sending text strings vs. some other method.
- so far the wxWindows debugger consists of one big dialog box that shows
  all the standard registers, and a working Continue, Stop, and Step button.
- modify ParamDialog so that it is more useful as a base class, by moving
  some things to protected members&fields, separating out functionality
  that is most likely to be replaced into virtual functions, and making it
  generally more flexible.  The new CpuRegistersDialog is based on
  ParamDialog.
- in wxdialog.cc, continue the convention of using wxID_HELP, wxID_OK,
  wxID_CANCEL, etc. for the id's of buttons, instead of wxHELP, wxOK, etc.
  which are intended to be ORred together in a bit field.
- cpu/init.cc: put ifdefs around DEFPARAMs for flags in configurations
  where they don't exist.  Add an eflags shadow parameter that represents all
  of the bits of eflags at once.  There are also boolean shadow params for
  each bit.
- modified files: cpu/init.cc debug/dbg_main.cc debug/debug.h
  gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h
  gui/wxmain.cc gui/wxmain.h
2002-09-13 19:39:38 +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
f4818e6fa3 - bug fix from Peter Tattam that he describes as follows:
> This is the bug fix to make the reset button work properly when the cpu
  > is in the halt state.  There is another patch in init.cc as well to clear
  > async_event.  If you don't do this, if a cpu goes into HLT, the only thing
  > which will fix it is another interrupt.  The reset button won't work.
2002-09-12 06:29:13 +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
80a3900b8b - apply a patch I've been working on
- modified files: config.h.in cpu/init.cc debug/dbg_main.cc gui/control.cc
  gui/siminterface.cc gui/siminterface.h gui/wxdialog.cc gui/wxdialog.h
  gui/wxmain.cc gui/wxmain.h iodev/keyboard.cc

----------------------------------------------------------------------
Patch name: patch.wx-show-cpu2
Author: Bryce Denney
Date: Fri Sep  6 12:13:28 EDT 2002

Description:

Second try at implementing the "Debug:Show Cpu" and "Debug:Show
Keyboard" dialog with values that change as the simulation proceeds.
(Nobody gets to see the first try.)  This is the first step toward
making something resembling a wxWindows debugger.

First, variables which are going to be visible in the CI must be
registered as parameters.  For some variables, it might be acceptable
to change them from Bit32u into bx_param_num_c and access them only
with set/get methods, but for most variables it would be a horrible
pain and wreck performance.

To deal with this, I introduced the concept of a shadow parameter.  A
normal parameter has its value stored inside the struct, but a shadow
parameter has only a pointer to the value.  Shadow params allow you to
treat any variable as if it was a parameter, without having to change
its type and access it using get/set methods.  Of course, a shadow
param's value is controlled by someone else, so it can change at any
time.

To demonstrate and test the registration of shadow parameters, I
added code in cpu/init.cc to register a few CPU registers and
code in iodev/keyboard.cc to register a few keyboard state values.
Now these parameters are visible in the Debug:Show CPU and
Debug:Show Keyboard dialog boxes.

The Debug:Show* dialog boxes are created by the ParamDialog class,
which already understands how to display each type of parameter,
including the new shadow parameters (because they are just a subclass
of a normal parameter class).  I have added a ParamDialog::Refresh()
method, which rereads the value from every parameter that it is
displaying and changes the displayed value.  At the moment, in the
Debug:Show CPU dialog, changing the values has no effect.  However
this is trivial to add when it's time (just call CommitChanges!).  It
wouldn't really make sense to change the values unless you have paused
the simulation, for example when single stepping with the debugger.

The Refresh() method must be called periodically or else the dialog
will show the initial values forever.  At the moment, Refresh() is
called when the simulator sends an async event called
BX_ASYNC_EVT_REFRESH, created by a call to SIM->refresh_ci ().

Details:
- implement shadow parameter class for Bit32s, called bx_shadow_num_c.
  implement shadow parameter class for Boolean, called bx_shadow_bool_c.
  more to follow (I need one for every type!)
- now the simulator thread can request that the config interface refresh
  its display.  For now, the refresh event causes the CI to check every
  parameter it is watching and change the display value.  Later, it may
  be worth the trouble to keep track of which parameters have actually
  changed.  Code in the simulator thread calls SIM->refresh_ci(), which
  creates an async event called BX_ASYNC_EVT_REFRESH and sends it to
  the config interface.  When it arrives in the wxWindows gui thread,
  it calls RefreshDialogs(), which calls the Refresh() method on any
  dialogs that might need it.
- in the debugger, SIM->refresh_ci() is called before every prompt
  is printed.  Otherwise, the refresh would wait until the next
  SIM->periodic(), which might be thousands of cycles.  This way,
  when you're single stepping, the dialogs update with every step.
- To improve performance, the CI has a flag (MyFrame::WantRefresh())
  which tells whether it has any need for refresh events.  If no
  dialogs are showing that need refresh events, then no event is sent
  between threads.
- add a few defaults to the param classes that affect the settings of
  newly created parameters.  When declaring a lot of params with
  similar settings it's more compact to set the default for new params
  rather than to change each one separately.  default_text_format is
  the printf format string for displaying numbers.  default_base is
  the default base for displaying numbers (0, 16, 2, etc.)
- I added to ParamDialog to make it able to display modeless dialog
  boxes such as "Debug:Show CPU".  The new Refresh() method queries
  all the parameters for their current value and changes the value in
  the wxWindows control.  The ParamDialog class still needs a little
  work; for example, if it's modal it should have Cancel/Ok buttons,
  but if it's going to be modeless it should maybe have Apply (commit
  any changes) and Close.
2002-09-06 16:43:26 +00:00
Kevin Lawton
746f09b427 There's a bug in the repeated IO & mem copy speedups. I
added --enable-repeat-speedups with default to disabled.
Reconfigure/recompile and the speedup code will be #ifdef'd
out for now.  It manifested as junk written to the VGA screen
while booting/running Windows.

Also made some more mods to the main cpu loop.  Moved the
handling of EXT/errorno outside the main loop, much like
the extra EIP/ESP commits were moved, for a little better
performance.

I changed the fetch_ptr/bytesleft method of fetching to
a slightly different model, which calculates a window
for which EIP will be valid (land on the current page),
and a bias which when applied to EIP will be from
0..upper_page_limit.  Speed is about the same for either
method, but a pseudo-op/threaded-interpreter will plug
in better with this and be faster.
2002-09-02 18:44:35 +00:00
Kevin Lawton
3d8e5f8b61 Removed the BX_FETCHDECODE_CACHE mods, and the patch that
Bryce created for use of ensuring all mods were removed
cleanly.
2002-09-01 23:02:36 +00:00
Gregory Alexander
1be5b1d46c Added a linked list to further speed up icache invalidates.
These should be pretty snappy now.  It's time to generate
some actual statistics.

 Modified Files:
 	cpu/cpu.cc cpu/cpu.h cpu/init.cc memory/memory.cc
2002-06-05 21:51:30 +00:00
Bryce Denney
640d71d017 - check in Zwane Mwaikambo's MSR patch: patch.msr. 2002-03-27 16:04:05 +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
284178479b - apply patch "patch.ifdef-paging-tlb" 2001-08-10 18:42:24 +00:00
Todd T.Fries
4f1c151520 Move Init $ to ::init() 2001-06-27 20:27:49 +00:00
Todd T.Fries
a06b031dcf setprefix -> put 2001-06-27 19:16:01 +00:00
Todd T.Fries
12985edb26 setprefix now uses a variable length name as a string for an argument 2001-06-19 21:36:09 +00:00
Bryce Denney
c8ae6c4aa9 - set logging prefix and type in the constructor 2001-06-16 04:27:22 +00:00
Bryce Denney
f822257511 - there were cases where BX_APIC_SUPPORT were used and others where
BX_SUPPORT_APIC were used.  To follow the pattern used by other
  names like this, I changed them all to BX_SUPPORT_APIC.
  Thanks to Tom Lindström for chasing this down!
2001-06-12 13:07:43 +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
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
Bryce Denney
d7d75a7bdc - changed some messages from BX_INFO to BX_DEBUG so that they wouldn't
show up by default.
2001-05-22 18:48:31 +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