Rather than print the errno, print the result of strerror so the user
doesn't have to look up what each error code does. Don't duplicate
descriptors needlessly which have been returned by pipe(). Use panic_if
instead of if () panic. Check each call to a standard library function
instead of calling multiple and then only knowing that one of them
failed (but not which one). Close the far side of our pipes for both
the gem5 process, and the process that will become diod. Remove some
stray #undef-s which undefine macros that were never defined. Don't
try to force the descriptors going to diod to be particular numbers.
Slightly reduce nesting in the if which checks the results of fork.
Drop unnecessary \n-s in calls to panic, inform, etc. Minor spacing
related style fixes. Use nullptr instead of NULL.
Change-Id: I48d93778a1e139ef624876a0b316486aac774d7f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43083
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
For newer versions of libstdc++ (Like the one in the
ubuntu-20.04_all-dependencies docker image), the variables used when
rehashing, e.g., std::unordered_maps have been extended. This resulted
in the rehashing function using different, unimplemented, instructions.
Because these instructions are unimplemented, it resulted in a
std::bad_alloc exception when inserting into an unordered_map
This patchset implements the following instructions:
FCOMI, a floating point comparison instruction, using the compfp
microop. The implementation mirrors that of the FUCOMI instruction
(another floating point comparison instruction)
FSUBRP, a reverse subtraction instruction, is implemented using the
subfp microop like the FSUBP does, but with the operands flipped
accordingly.
FISTP, an instruction to convert a float to int and then store, is
implemented by using a conversion microop (cvtf_d2i) and then a store.
The cvtf_d2i microop is re-written to handle multple data sizes, as is
required by the FISTP instruction.
Change-Id: I85c57acace1f7a547b0a97ec3a0f0500909c5d2a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42443
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This was an inline function defined for each ISA, but really it makes
more sense for it to be defined by the instruction classes. The actual
return address for any given instruction can best be calculated when you
know what that instruction actually does, and also the instructions will
know about ISA level PC management.
Change-Id: I2c5203aefa90f2f26ecd94e82b925c6b552e33d3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39324
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Since gtest's SUCCEED() just throws away output sent to it, there needs
to be an alternative way to capture non-fatal warn, hack, or inform
messages. This change adds a stringstream called gtestLogOutput which
will accumulate all log messages so they can be inspected later. If you
want to see what output occurs as a result of a specific action, you can
flush out the stringstream with .str(""), perform that action, and then
check the stream's contents.
The stream also records the output of exiting logs like fatal and panic.
It's not 100% clear that these messages would be retrievable or useful,
but this at least maintains consistency between the two classes of
messages.
To avoid threading/locking issues, the stream is thread local. To
prevent tests from affecting each other and to make the output more
predictable for test assertions, it also automatically installs an event
hook which will be called each time a test starts which will clear out
the contents of the stream.
Change-Id: I9d6650feb77b676a5b2b1fc2542cdebf3c60ed34
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42181
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These currently only hold the number of registers in a particular class,
but can be extended in the future to hold other information about each
class. The ISA class holds a vector of descriptors which other parts of
gem5 can retrieve to set up storage for each class, etc.
Currently, the RegClass enum is used to explicitly index into the vector
of descriptors to get information about a particular class. Once enough
information is stored in the descriptors, the other parts of gem5 should
be able to set up for each register class generically, and the ISAs will
be able to leave out or create new register classes without having to
set up global plumbing for it.
The more immediate benefit is that this should (mostly) parameterize
away the ISA register constants to break another TheISA style
dependency. Currently a global set of descriptors are set up in the
BaseISA class using the old TheISA constants, but it should be easy to
break those out and make the ISAs set up their own descriptors. That
will bring arch/registers.hh significantly closer to being eliminated.
Change-Id: I6d6d1256288f880391246b71045482a4a03c4198
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41733
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This was set to 1, the same as SSrcReg1. That value is used to order the
registers in the source operand array. Other code then expects to find
operands in that order when, for example, looking up an index to pick
sub-parts of a register out, or to print a register name.
Since the index value of SSrcReg1 and SSrcReg2 were the same, they
wouldn't be sorted in a predictable way, meaning the code looking for
SSrcReg2's index might have found SSrcReg1's index instead and done the
wrong thing.
Change-Id: I75045e64595e249802f57d22023a7eeb7b8ac5c6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42342
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Override ParseParam<>::parse and ShowParam<>::parse directly. This will
allow using a different format for serializing and displaying registers.
Also get rid of the print() methods. When any cprintf based mechanism is
used (like DPRINTF), the underlying mechanism will use << to output the
value. Since we already override <<, there's no reason to wrap that in a
method which calls csprintf which calls << anyway.
Change-Id: Id65b9a657507f2f2cdf9673fd961cfeb0590f48c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41994
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
This function causes problems with gcc 5 which incorrectly complains
about the call to warn_if inside a constexpr function. That should only
be an error if a call to a non-constexpr is unavoidable, and even then
the compiler isn't required to emit a diagnostic.
Rather than drop the warning, or add ifdefs to deal with these defective
versions of gcc, this change eliminates the power() function entirely.
Most inputs to this function would overflow anyway, which is reportedly
why no integer version of an exponentiation function is defined in the
standard library, and all uses of this function can easily and more
efficiently be replaced by simple left and right shifts.
Finally, by eliminating the power() function, we also remove the
dependence on base/logging.hh.
Change-Id: I4d014163883d12db46da4ee752696c8225534ee8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42504
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The existing sext function is a bit of a misnomer since it doesn't
actually sign extend its input, it just extends the sign if the sign bit
was zero.
This change adds a new szext function which truly sign extends the
value, although with a tiny amount of additional overhead.
Change-Id: I562ce479b771be8a3319934aeff55e797126a146
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42384
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Like in the nomali library, this bug is in some code making a bitmask
where what bits are enabled depends on some conditions. It used ?: to
evaluate the conditions and | to aggregate the bits, but didn't use any
()s, so the | happened first, then the ?:s. This would generate an
incorrect bitmask.
Change-Id: Iabcc8a9fd38cde5de3c0627a3b143407247c0c0e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40955
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
The yieldThread function implements MIPS's yield instruction, and had a
if condition in it, (src_reg && !yield_mask != 0), which upset clang. When
originally committed, this check read (src_reg & !yield_mask != 0), but
apparently as part of a cleanup sweep a long time ago, it was assumed
that the & was being used as a logical operator and was turned into &&.
Reading the actual description of what the yield instruction is supposed
to do, if src_reg is positive (it is at this point in the function),
then it's supposed to be treated as a bitvector. The YQMask register,
what gets passed in as yield_mask, can have bits set in it which mask
bits that might be set in src_reg, and if any are still set, the an
interrupt should happen, as implemented by the body of the if.
From this description, it's apparent that what the original code was
*trying* to do was to use yield_mask to mask any set bits in src_reg,
and then if any bits were left go into the body. The original author
used ! as a bitwise negating operator since what they *wanted* to do was
to block any bits in src_reg where yield_mask *is* set, and let through
any where yield_mask *is not* set. The & would do that, but only with a
bitwise negated yield_mask. Hence:
if ((src_reg & ~yield_mask) != 0) {
...
}
Change-Id: I30d0a47992750adf78c8aa0c28217da187e0cbda
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40957
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Due the compute unit pipeline being executed in reverse order, there
exists a scenario where a compute unit will execute an extra
instruction when it's supposed to be stopped at a barrier. It occurs
as follows:
* The ScheduleStage sets a barrier instruction ready to execute.
* The ScoreboardCheckStage adds another instruction to the readyList.
This is where the barrier is checked, but because the barrier isn't
executing yet, the instruction can be passed along to ScheduleStage
* The barrier executes, and stalls
* The ScheduleStage sees that there's a new instruction and schedules
it to be executed.
* Only now will the ScoreboardCheckStage realize a barrier is active
and stall accordingly
* The subsequent instruction executes
This patch sets the wavefront status to be S_BARRIER in ScheduleStage
instead of in the barrier instruction execution in order to have
ScoreboardCheckStage realize that we're going to execute a barrier,
preventing it from marking another instruciton as ready.
Change-Id: Ib683e2c68f361d7ee60a3beaf53b4b6c888c9f8d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41573
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Instead of using recursively applied templates to accumulate a series of
wrapper lambdas which dispatch to a call, use pure parameter pack
expansion. This has two benefits. One, it makes the code simpler(ish) and
easier to understand. The parameter pack machinery is still intrinsically
fairly tricky, but there's less of it and it's a fairly straightforward
application of that mechanism.
Also, a nice side benefit is that the template for simcall dispatch will
expand to a small fixed number of functions which do all their work
locally, instead of having a new function for each layer of the onion,
one per parameter, and no calls through lambdas. That should hopefully
make debugging easier, and produce less bookkeeping overhead as far as
really long names, lots of functions, etc.
This code, specifically the code in dispatch.hh, can be simplified even
further in the future once we start using c++17 which is if constexpr,
and std::apply which explodes a tuple and uses its components as
arguments to a function, something I'm doing manually here.
Change-Id: If7c9234cc1014101211474c2ec20362702cf78c2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41600
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
