is the first attempt to regain the performance of pre-SMP bochs
(1.1.2). When simulating only one processor, stay in cpu_loop forever
as pre-SMP versions did. The overhead of returning from cpu_loop over
and over was slowing us down.
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.
- change Makefile.in to "cvs-snapshot" information rather than printing
the release number, since in fact it's not the same as the release anymore
- use #defines to give the actions names (ACT_IGNORE, ACT_REPORT, ACT_FATAL)
- register all logfunctions as they call setio, and keep a list so that
we can change their settings more easily. I admit I used a static-sized
array to store them. Sorry.
- instead of printing a prefix [GEN ] for generic messages, just leave the
prefix blank [ ]. Otherwise you start wondering what does gen stand
for.
- avoid reentry into fatal, since fatal can call BX_INFO and friends.
This avoids a potential infinite recursion.
- now that files other than .bochsrc can be the rc file, print the
actual name of the file in error messages.
what action to take on panic, error, info, and debug. The lines don't
have any effect quite yet because of an initialization order problem
with the logfunctions.
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
signal. First, selection of the GUI should cause BX_GUI_SIGHANDLER to
be defined in config.h.in. Then, the GUI should define member functions
Bit32u get_sighandler_mask ();
void sighandler (int sig);
The mask function returns a bitfield where one bit corresponds to each
signal. For any signal whose bit is set to 1 in the return value of
get_sighandler_mask, the gui will control that signal. When the signal
arrives, bx_gui.sighandler(sig) will be called by bx_signal_handler,
instead of the default behavior of that signal.
since at present there's no way to actually manage this. To use both,
we will need to put the cdrom (or diskd) onto second ide controller with
a different IRQ.
