These files are part of the wx plugin, and they should not be linked
into a separate plugin. I have changed gui/Makefile.in and configure.in
to correct this.
- This fixes bug [ 628667 ] don't build plugin for wxdialog, wxmain
- modified: gui/Makefile.in configure.in configure
one for --disable-cdrom, and one for the defalt if it's not specified. The
enabled action and default are supposed to be the same, but they were
slightly different, and Bochs on BeOS was able to compile with --enable-cdrom
but not with the default action. Solution: now the autoconf actions only
sets bx_cdrom=0 or bx_cdrom=1. Then afterward, it tests $bx_cdrom and does
the enable or disable action. This will be easier to maintain because there
is just one copy of each action, instead of two copies that are supposed to
be kept identical to each other.
SSE/SSE2 for Stanislav. Also, some method prototypes and
skeletal functions in access.cc for read/write double quadword
features.
Also cleaned up one warning in protect_ctrl.cc for non-64 bit compiles.
There was an unused variable, only used for 64-bit.
override default. This is useful if you have more than one wx installation,
for example debug and release libraries.
- modified: Makefile.in configure.in configure
instead of winmm being a part of GUI_LINK_OPTS_WIN32 only, it is
placed in @DEVICE_LINE_OPTS@ so that it will be used for sdl, rfb, wx,
etc.
- solve compile problems when building bximage, niclist, and any other
console based program. The compile flags returned by wx-config and
sdl-config did strange things to these console programs, for example
redefining main to SDL_main. Because I wanted to use the
configure-generated CFLAGS to compile the programs, but I wanted to
avoid including GUI specific compile options, I split up the configure's
@CFLAGS@ variable into @CFLAGS@ and @GUI_CFLAGS@, and split
@CXXFLAGS@ into @CXXFLAGS@ and @GUI_CXXFLAGS@. All programs in the
Bochs binary will use both, but the console programs will just use
@CFLAGS@ or @CXXFLAGS@.
- gui/Makefile.in, I no longer use the gui specific CFLAGS variables,
SDL_CFLAGS and WX_CXXFLAGS. These values are included in CFLAGS and
CXXFLAGS now.
- modified: configure.in, configure, all Makefile.in's
"-pthread" flag to the link line, but as of wxWindows 2.3.3 their
wx-config script adds it for us. Given the keyboard mapping improvements
in wx 2.3.3, I don't expect to support any previous version.
To: bochs-developers@lists.sourceforge.net
Subject: [Bochs-developers] Fix for configure.in bug
This patches fixes a bug in configure.in which prevents configure from setting
default values for CFLAGS and CXXFLAGS. Normally, the way autoconf builds
configure, it will set default values for CFLAGS and CXXFLAGS of `-g -O2'.
But, if the user specified them (via the environment), it won't touch them.
The clause in configure.in that tries to set platform-specific flags breaks
this because it always assigns a value (usually blank for most platforms),
which fools the defaulting mechanism later on.
all available optimizations in one shot.
Finished one last case of an instruction which could but didn't use
the Read-Modify-Write variants of access.cc functions.
Started going through the integer instructions, merging obvious cases
where there are two "if (modrm==11b) {" clauses and very little
action in between, and cleaning up the aweful indentation leftover
from many years ago when those instructions were implemented using
cut-and-paste. We may get a little extra performance out of these
mods, but they'll also be easier after I'm finished to enhance
with asm() statements to knock out the lazy flags processing on x86.
just the wxwindows ones. This is required on cygwin, for example, because
the CFLAGS and CXXFLAGS include gcc flags that change code generation:
-fno-pcc-struct-return and -fvtable-thunks. It is not safe to mix code
compiled with these flags with code compiled without. I learned this the
hard way when I found that sometimes code that called a virtual member
function was jumping to the WRONG member function.
wxWindows guis.
- if cross configuring, don't insist on finding curses library.
- on normal configures, when the target platform is win32 (windows, cygwin,
mingw), don't insist on finding pthread either.
(I'm starting to wonder if when cross_configure=1 we shouldn't just skip over
ALL of the library and header checks. When you're going to configure on one
platform and build on another, all that information is useless anyway.)
smarter. If you use --enable-x86-64, it has the following side
effects on other options:
- cpu level defaults to 6 instead of 5
- ignore bad msr defaults to on (Peter T. requested this)
- if cpu level is 6 or greater, these options are enabled by default.
- 4meg pages (PSE)
- physical address extensions (PAE)
- global pages (PGE)
- apic support
configuring for a different machine. This is used to short-circuit
certain sanity checks, such as existence of certain required libraries.
- in --with-wx configuration, when $cross_configure=1, do not abort
configure if library is not found.
- if wxWindows version not found, print "not_found" instead of nothing
From his patch file text:
> This patch adds Promise DC2300 VLB IDE Support.
> You may find msdos and win95 drivers on the net. Look for
> P2300W95.ZIP and DC2300VLBIDEver260b.ZIP.
>
> The good news is that now win95 natively sees my cdrom,
> and that the disks are not in msdos compatibility mode any more.
>
> The bad news is that it works only for the first ata interface.
>
> I tested that patch on msdos and win95 only.
>
> Some info on VLB IDE can be found at http://ryston.cz/petr/vlb/
I got Win95 running with 32-bit paging/filesystem using the
recommended driver and these patches. Since the patches did
such a good job bracketing code modifications with a #define,
they might as well become part of the current CVS code.
user can turn on/off use of native host specific inline asm
statements. By default, this option is enabled, so you only
need it to disable inline asms in your compile for now.
Currently only on x86+GCC environments, will inline asm()
statements be used. Eventually, other platforms could specify
some asm()s; probably for endian issues such as byte-swapping
and unaligned memory accesses. On x86, there are some inline
asm()s which do the arithmetic EFLAGS processing so that the
lazy flags handling is somewhat bypassed. Eventually, I'll
add more, at least for the more common instructions. This
adds a little extra performance.
- hardcode BX_HAVE_GETTIMEOFDAY=0 if cross compiling for VC++
(this part hasn't been tested)
- modified files: configure configure.in config.h.in iodev/pit_wrap.cc
but if you hand edit cpu/cpu.h, and change BxICacheEntries,
you can try different sizes. I'll make this more flexible
with configure. For now, use "--enable-icache" with no parameters.
- Modified fetchdecode.cc/fetchdecode64.cc just enough so that
instructions which encode a direct address now use a memory
resolution function which just sticks the immediate address
into rm_addr. With cached instructions we need this.
enhancement to bochs. You can now configure with
--enable-guest2host-tlb.
Force the support of big pages (PSE) when x86-64 is configured.
Reverted back to only one kind of TLB entry style, since everything
is ported.
Fixed one bug in io.cc with as_64 and the index registers.
There are others, as noticed by Peter.
you have AC_DEFINE(var, value) executed more than once, autoconf is
supposed to use the last AC_DEFINE value, but sometimes it doesn't.
I haven't been able to figure out why, so I've just worked around it
instead.
- for BX_SupportGlobalPages, which could call AC_DEFINE twice, I kept the
value in a shell variable $support_global_pages until the end and then
did one AC_DEFINE after it had reached its final value. Same thing
with BX_USE_CONFIG_INTERFACE.
- also I realized that we are using AC_SUBST() in many cases where it is
not needed. AC_SUBST(name) substitutes the string @name@ with a
value from the configure script. For preprocessor symbols like
BX_SupportPAE, we only need the AC_DEFINE; the AC_SUBST has no effect.
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.
printing a message when a reserved bit was set, but not causing
a #GP(0). As well, I force a new PAE support option to 1 when
Hammer support is enabled.
circular dependencies between 3 cpu related libs that I need
as part of this transition. I changed the "ar rv" to "ld -i -o"
to do an incremental load instead of an archive. Hope this
doesn't break any platforms. We can reset this later.
to incrementally merge files. For a test, shift16.cc is always
compiled in the cpu/ directory regardless of 32/64-bit configure.
Ultimately, all files will migrate from cpu64 to cpu.
This adds a whole new directory cpu64 with the new emulation code.
Very few changes were necessary outside cpu64. To try it, configure
with --enable-x86-64 and make.
- also this adds Peter Tattam's external debugger interface.
- modified files: Makefile.in bochs.h config.h.in configure.in
load32bitOShack.cc logio.cc cpu/Makefile.in cpu/cpu.cc debug/dbg_main.cc
- added files: cpu/extdb.cc cpu/extdb.h and cpu64/*
You need to use '--enable-global-pages' to configure in support.
If you have something to boot that uses them, give them a
spin. Really the were introduced for PPro and above, but
I haven't put in any limits. CPUID and CR4 report the proper
bits when configured, regardless of --enable-cpu-level at the
moment.
work (control-C kills process instead of returning to debugger prompt), give
a configure-time error if they are enabled together. If we can fix the
signal problem in readline, this check can be removed.
files that need them. This is more in line with the other gui libraries,
and the compile line is easier to read.
- modified: Makefile.in configure.in configure gui/Makefile.in
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.
- Paging code rehash. You must now use --enable-4meg-pages to
use 4Meg pages, with the default of disabled, since we don't well
support 4Meg pages yet. Paging table walks model a real CPU
more closely now, and I fixed some bugs in the old logic.
- Segment check redundancy elimination. After a segment is loaded,
reads and writes are marked when a segment type check succeeds, and
they are skipped thereafter, when possible.
- Repeated IO and memory string copy acceleration. Only some variants
of instructions are available on all platforms, word and dword
variants only on x86 for the moment due to alignment and endian issues.
This is compiled in currently with no option - I should add a configure
option.
- Added a guest linear address to host TLB. Actually, I just stick
the host address (mem.vector[addr] address) in the upper 29 bits
of the field 'combined_access' since they are unused. Convenient
for now. I'm only storing page frame addresses. This was the
simplest for of such a TLB. We can likely enhance this. Also,
I only accelerated the normal read/write routines in access.cc.
Could also modify the read-modify-write versions too. You must
use --enable-guest2host-tlb, to try this out. Currently speeds
up Win95 boot time by about 3.5% for me. More ground to cover...
- Minor mods to CPUI/MOV_CdRd for CMOV.
- Integrated enhancements from Volker to getHostMemAddr() for PCI
being enabled.
the terminology a bit. In particular, the term "gui" has started
to mean different things in different contexts, so I've defined
some more specific names for the parts of the user interface, and
updated comments and some variable names to reflect it. See
siminterface.h for a more complete description of all of these.
VGAW: VGA display window and toolbar buttons, the traditional Bochs
display which is ported to X, win32, MacOS X, etc. Implemented
in gui/gui.* and platform dependent gui/*.cc files.
CI: configuration interface that lets the user change settings such
as floppy disk image, ne2k settings, log options. The CI consists
of two parts: configuration user interface (CUI) which does the
actual rendering to the screen and handles key/mouse/menu events,
and the siminterface object.
CUI: configuration user interface. This handles the user interactions
that allow the user to configure Bochs. To actually change any
values it talks to the siminterface object. One implementation of
the CUI is the text-mode menus in gui/control.cc. Another
implementation is (will be) the wxWindows menus and dialogs in
gui/wxmain.cc.
siminterface: the glue between the CUI and the simulation code,
accessible throughout the code by the global variable
bx_simulator_interface_c *SIM;
Among other things, siminterface methods allow the simulator to ask the
CUI to display things or ask for user input, and allows the CUI
to query and modify variables in the simulation code.
GUI: Literally, "graphical user interface". Until the configuration menus
and wxWindows came along, everyone understood that "gui" referred to the
VGA display window and the toolbar buttons because that's all there
was. Now that we have the wxWindows code, which implements both the VGAW
and the CUI, while all other platforms implement only the VGAW, it's not
so clear. So, I'm trying to use VGAW, CI, and CUI consistently since
they are more specific.
control panel: This has been used as another name for the configuration
interface. "control panel" is also somewhat unspecific and it sounds
like it would be graphical with buttons and sliders, but our text-mode
thing is not graphical at all. I've replaced "control panel" with
"configuration interface" wherever I could find it. In configure script,
the --disable-control-panel option is still supported, but it politely
suggests that you use --disable-config-interface instead.
- clean up comments in siminterface,wx* code
- add comments and examples for bx_param_* and BxEvents
- remove some obsolete stuff: notify_*_args,
bx_simulator_interface_c::[sg]et_enabled() methods
- in siminterface.cc, move a few bx_real_sim_c methods to where they belong,
with the rest of the methods. No changes to the actual methods.
- remove some DOS ^M's which crept in and confused my editor.
called <linux/netlink.h> the ethertap module will be defined. If other
OSes turn up that also have ethertap, we can change the test.
- in eth_tap.cc, I replaced the calls to GPL code from maconlinux with
my own stuff.
the gui will really be. I was afraid people would get confused
if the default gui doesn't match the gui they asked for. Now they
will see both the default gui and the one that was actually chosen.
Not a big deal.
and look at the description at the top. Here's an intro.
This patch makes significant changes to the configure script. It adds the
lines AC_CANONICAL_HOST and AC_CANONICAL_TARGET which detect the OS and
processor type. The configure script, knowing the OS and processor type, can
then make intelligent decisions about which CFLAGS are needed and what is the
default GUI for that platform. One of the goals of this patch is to make it
so that on all supported platforms, "configure;make" will compile cleanly.
Configure detects the target platform, but it can be overridden by using
--target=___. This is important when using one platform to generate
Makefiles and header files for another platform. See config.guess script for
the exact details of platform naming.
The defaults that are currently implemented in the modified configure script
include:
If platform is windows* or winnt*, use win32 gui.
If platform is cygwin*, use win32 gui and compile with
"-mno-cygwin -DWIN32".
If platform is macosx* or darwin*, use carbon gui and compile
with "-fpascal-strings -fno-common -arch ppc -Wno-four-char-constants
-Wno-unknown-pragmas -Dmacintosh"
If platform is macos, use macos gui.
If platform is beos, use beos gui.
If platform is amigaos, use amigaos gui.
Otherwise, use X windows gui.
everything about the installation path. There should be no more
hardcoded references to /usr/local/bochs. Instead, there are
references to @prefix@ which get replaced by the configure script
with the real prefix.
bug #429448. What is strange about this problem (on OpenBSD) is that the
compile and link goes fine, but when you execute your first readline library
function it does a dynamic link and crashes on the spot. Many autoconf
tests only compile and sometimes link the test program, but this test
compiles, links, and runs it.
--with-amigaos is allowed and sets up the makefiles correctly. It
defines a symbol called BX_WITH_AMIGAOS, which should be used in
#if..#endif constructs that are specific to amigaos.
- if --enable-cdrom is used with --with-amigaos, the cdrom_amigaos.o
object file will be added to CDROM_OBJS in the iodev makefile.
for Linux!!! I tested this using host OS kernel 2.2.14, and was able
to use telnet, ftp, irc, lynx, etc. Because it is a packet filter
solution, you aren't able to talk to the host machine, only to other
machines on the network. The patch itself is in
patches/patch.ethlinux-splite.
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!
- remove --enable-external-cpu-memory
- Neither of these options were compiling anymore, and Kevin suggested:
> My advice would be to scrap both of these options. I hadn't used
> those in some time. The way to implement 'external' devices
> would be via a modular plugin architecture, which both bochs
> and plex86 should implement.
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.
For compilers (such as Microsoft VC++) which don't allow "LL" after a
constant to make it 64-bit, this patch declares all such constants as
BX_CONST64(value). Then in config.in, a switch called
BX_64BIT_CONSTANTS_USE_LL controls whether the macro puts the
LL's in or not. Configure sets the macro, if you're on a platform
that can run such things.
- check for snprintf, strtoull
- check if empty structs allowed
- check for hash_map.h
- check for blank labels as in void main () { int x=2; label: }
- if debugger, turn on disasm too
