* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed.
*
Now that I'm making the branch microop always use a fixed absolute
micropc, the only place I wasn't already using it, the CPUID
instruction, needs to change. The problem is, as things are implemented,
it really has to be able to compute it's target. The CPUID instruction
basically queries
OK, I see... the combination of only branching to the start of a quad and
not being able to generate more than one quad combinationally makes
branching in a combinational sequence meaningless on the real machine.
Is there an upper bound on the number of microops you can generate in m5
through the
This is the mail system at host daystrom.m5sim.org.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete
If it's that complicated, why not just do it in C++ inside of M5, and have a
special microop that just calls that function and lets it do the dirty
work? I don't think performance fidelity is an issue here, and even if it
were, we could always just make that single microop take longer.
Steve
On
I kind of ran into a similar thing with sparc. There is configuration
code that needed to inform the system about the speed/size/type of
various objects. It would be good to have a C++ interface to easily
query the object tree to be able to make those determinations.
Ali
On Sep 20, 2008,
Collecting the necessary information in Python up front seems reasonable to
me.
As far as where the C++ code would go, it seems to me it could either be a
method on the BaseCPU object or a global function in the x86 ISA namespace.
The latter makes sense if we're trying not to pollute the CPU
I have the microbranches ready to go, so now we need to figure out the
details of how you switch to and from the ROM. I think something like
fromRom and nextFromRom would work, although the names aren't that
great. If anyone has a suggestion for a different mechanism or better
names, please
