Even though we're not incorrect about operator precedence, let's add
some parens in some particularly confusing places to placate GCC 4.3
so that we don't have to turn the warning off. Agreed that this is a
bit of a pain for those users who get the order of operations correct,
but it is likely to prevent bugs in certain cases.
We should always refer to the specific ISA in that arch directory.
This is especially necessary if we're ever going to make it to the
point where we actually have heterogeneous systems.
Fix the logic in the LSQ that determines if there are any stores to
write back. In the commit stage, check for thread specific writebacks
instead of just any writeback.
These functions keep trying to read and write until all data has been
transferred, or an error occurrs. In the case where an end of file
hasn't been reached, but all of the bytes have not been read/written,
try again. On EINTR, try again.
We haven't used the preprocessor feature of the inifile stuff in a
very long time, so let's get rid of it since it would otherwise take
effort to maintain.
python type of a latency. In addition, the multiple definitions of profile in the different cpu models caused
problems for intialization of the interval value. If a child class's profile value was defined, the parent
BaseCPU::ProfileEvent interval field would be initialized with a garbage value. The fix was to remove the
multiple redifitions of profile in the child CPU classes.
A whole bunch of stuff has been converted to use the new params stuff, but
the CPU wasn't one of them. While we're at it, make some things a bit
more stylish. Most of the work was done by Gabe, I just cleaned stuff up
a bit more at the end.
When invoking several copies of m5 on the same machine at the same
time, there can be a race for TCP ports for the terminal connections
or remote gdb. Expose a function to disable those ports, and have the
regression scripts disable them. There are some SimObjects that have
no other function than to be used with ports (NativeTrace and
EtherTap), so they will panic if the ports are disabled.
This should allow m5 to be more easily embedded into other simulators.
The m5 binary adds a simple main function which then calls into the m5
libarary to start the simulation. In order to make this work
correctly, it was necessary embed python code directly into the
library instead of the zipfile hack. This is because you can't just
append the zipfile to the end of a library the way you can a binary.
As a result, Python files that are part of the m5 simulator are now
compile, marshalled, compressed, and then inserted into the library's
data section with a certain symbol name. Additionally, a new Importer
was needed to allow python to get at the embedded python code.
Small additional changes include:
- Get rid of the PYTHONHOME stuff since I don't think anyone ever used
it, and it just confuses things. Easy enough to add back if I'm wrong.
- Create a few new functions that are key to initializing and running
the simulator: initSignals, initM5Python, m5Main.
The original code for creating libm5 was inspired by a patch Michael
Adler, though the code here was done by me.
