| Age | Commit message (Collapse) | Author |
|---|
|
The specializations need to be online only and not static, but the
template itself is static and inline.
Originally they were in an anonymous namespace, but that causes
warnings when building on clang or with certain versions of gcc because
the functions may not be used in every .cc.
Change-Id: Iff127337f7bf0c18755de07a49d6e7a9ce6f2f0a
Reviewed-on: https://gem5-review.googlesource.com/9581
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
This way printing bitunions with, for instance, DPRINTF actually prints
something useful. More specialized overloads will still allow printing
particular bitunion types in ways that might make more sense for that
particular type.
Change-Id: I92beb0ce07683ba8b318cf25aa73e0057e4a60ef
Reviewed-on: https://gem5-review.googlesource.com/9461
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
<iostream> isn't actually used anywhere in bitunion.hh. The templated
hash struct type is defined in <functional> and should be included
explicitly.
Change-Id: I8691ccb2f9e28a01610ae8bb4d9591b07cb7320b
Reviewed-on: https://gem5-review.googlesource.com/7781
Reviewed-by: Matthias Jung <jungma@eit.uni-kl.de>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
clang was getting very upset and interpretting a member function
pointer as a call to the actual underlying function, and then
complaining that it was a non-static function call without an instance.
It seems what it was really upset about was that the class who's scope
the member function pointer belonged to (the current class) wasn't done
being defined. This *should* be ok as far as I can tell, but clang was
having none of it.
This change reworks how the type of the setter function arguments are
determined to work around that limitation. The bitunion test was run
with clang++ and g++ and both pass, and I've built gem5.opt for ARM
successfully.
Change-Id: Ib9351784a897af4867fe08045577e0247334ea11
Reviewed-on: https://gem5-review.googlesource.com/7581
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Since this type is now accessible through a clean interface, hide it
from anybody that tries to peak around the curtain.
Change-Id: I1257b6675a45b8648be459ad8e8d0f27a6feee6b
Reviewed-on: https://gem5-review.googlesource.com/7205
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The ARM types.hh file defined an STL style hash structure to operate
on the ExtMachInst, but it referred to the underlying storage type
using internal typedefs in the BitUnion types. To avoid having to do
that, this change adds a hash structure to bitunion.hh which will work
on any BitUnion, and gets rid of the ARM ExtMachInst version.
Change-Id: I7c1c84d61b59061fec98abaaeab6becd06537dee
Reviewed-on: https://gem5-review.googlesource.com/7204
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Previously these relied on reaching into private internal definitions
in the BitUnion types.
Change-Id: Ia6c94de92986b85ec9e5fcb197459d450111fb36
Reviewed-on: https://gem5-review.googlesource.com/7202
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
They are now oriented around a class which makes it easy to provide
custom setter/getter functions which let you set or read bits in an
arbitrary way.
Future additions may add the ability to add custom bitfield methods,
and index-able bitfields.
Change-Id: Ibd6d4d9e49107490f6dad30a4379a8c93bda9333
Reviewed-on: https://gem5-review.googlesource.com/7201
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Used cppclean to help identify useless includes and removed them. This
involved erroneously included headers, but also cases where forward
declarations could have been used rather than a full include.
|
|
Make best use of the compiler, and enable -Wextra as well as
-Wall. There are a few issues that had to be resolved, but they are
all trivial.
|
|
If two bitfields are of the same type, also implying that they have the same
first and last bit positions, the existing implementation would copy the
entire bitfield. That includes the __data member which is shared among all the
bitfields, effectively overwritting the entire bitunion.
This change also adjusts the write only signed bitfield assignment operator to
be like the unsigned version, using "using" instead of implementing it again
and calling down to the underlying implementation.
|
|
If a bit field in a bit union specified as Bitfield<LSB, MSB> instead
of Bitfield<MSB, LSB> the code silently fails and the field is read as
zero. This changeset introduces a static assert that tests, at compile
time, that the bit order is correct.
|
|
|
|
|
|
should configure their editors to not insert tabs
|
|
classes.
|
|
--HG--
extra : convert_revision : 1c003f9fc9ef3a57c9199d692d172e747581f383
|
|
--HG--
extra : convert_revision : aad9388afe81ba6541d0b18fa9777e6ffcfd871c
|
|
Previously, the bitunion would need to be declared and then assigned to separately.
--HG--
extra : convert_revision : d229bd83bc7baeca2259d4e7b080f359915015f3
|
|
--HG--
extra : convert_revision : 8d55ca9645ee4e357b7f4595435542eb72490331
|
