control panel are all implemented as bx_list_c, and look much like
they did before.
- removed many hardcoded UI functions from control.cc, since the
much more general "text_ask" methods have replaced them.
- add range checking on integer parameter values. This exposed several
cases where my initial value for an integer parameter was not in range.
- cleaned up behavior of get/set methods. The get/set methods allow the
handler to override the value that is returned/set, or perform side
effects.
- the title parameter of a bx_list_c now defaults to the name.
- now bx_param_c fields that used to be private are protected instead
- removed references to bx_any
- moved definition of set_handler from siminterface.h to siminterface.cc.
I was considering with doing a "set" of the old value when the
handler is first installed, but that remains commented out.
- BX_BOOT_DISKA and BX_BOOT_DISKC are now 0,1 so that they can correspond
with the values of a bx_param_enum_c. For a while they were 0x00 and 0x80
corresponding to the numbering convention of the bios, but it didn't
really matter.
been converted into parameters temporarily have the letter "O" appended
to their name. I don't want to keep it this way, but it has helped
in the conversion process because the compiler refuses to compile the
old uses of the name. Before I started using the "O" trick, there were
many bugs like this: if (bx_options.diskc.present) {...}
This was legal with the new parameters, but it was testing whether the
parameter structure had been created, instead of testing the value of
the present parameter. Renaming present to Opresent turns this into
a compile error, which points out the incorrect use of the param.
- the "--disable-control-panel" no longer works, I'm afraid. I can no
longer support this and continue progress.
now the whole "Bochs Memory Options" menu uses new style parameters.
The next step is to remove the hardcoded stuff that generates and runs
this menu, and replace it with general menu building code. All you should
need to create this menu is the string "Bochs Memory Options", and the
IDs of the bx_param_c options that should appear on the menu. The
bx_param_c structure for each parameter tell what type it is, how to
display it, constraints on the value, what to do when the parameter
changes.
declared as bx_param_c * types in the bx_options structure. They are
initialized in main.cc (bx_init_options) with default values.
Access to parameters of this type should always be like this:
bx_options.mouse_enabled->get ();
bx_options.mouse_enabled->set (newval);
Eventually I will be transferring all options to this format.
when main.cc no longer had one. Now compiling with debugger is working
with the control panel. To get the control panel, you have to click
the snapshot button, and to get the debugger, you have to press ^C.
These should be better integrated (maybe a control panel menu choice
that jumps into the debugger and a debugger command that starts the
runtime control panel...)
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!
panel. It gives the user the option of continue this time, continue
and never ask again for this type of log message, or die.
- the communication between control.cc and siminterface.cc is still
somewhat crude. I'm trying to implement it so that a network
protocol based on this interface will be simple. I'll get this cleaned
up soon.
writes a bochsrc for you.
- since there were two options related to logging, I moved them both
into a new struct called bx_log_options. This follows the pattern
used by other devices.
- in control.cc: removed option 1 from main menu, the one that said
"Read options from bochsrc.txt." This was identical to choosing
the next option, "Read options from..." and only saved you one
keystroke, so I removed it.
gui/control.cc and the simulator. Now all communication between
the control panel and the rest of bochs goes through an object
called bx_simulator_interface_c.
BX_CPU_C bx_cpu;
BX_MEM_C bx_mem;
and when more than one processor, use
BX_CPU_C *bx_cpu_array[BX_SMP_PROCESSORS];
BX_MEM_C *bx_mem_array[BX_ADDRESS_SPACES];
The changeover is controlled by BX_SMP_PROCESSORS, but there are only
a few code changes since nearly all code uses the BX_CPU(n) and BX_MEM(n)
macros.
- This turns out to make a 10% speed difference! With this revision,
the CVS version now gets 95% of the performance of the 3/25/2000
snapshot, which I've been using as my baseline.
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.
Bryce Denney