This expands those functions into code which extracts the virt proxy
and then uses the appropriate method on it. This has two benefits.
First, the Copy* functions where mostly redundant wrappers around the
methods the proxy port already had. Second, using them forced a
particular port which might not actually be what the user wanted.
Change-Id: I62084631dd080061e3c74997125164f40da2d77c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18575
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These selected their behavior based on ifdefs and had to be disabled
when on the NULL ISA. The versions which take an explicit endianness
have been renamed to just read/write instead of readGtoH and writeHtoG
since the direction of the translation is obvious from context.
Change-Id: I6cfbfda6c4481962d442d3370534e50532d41814
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18372
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch optimises the passing of StaticInstPtr by avoiding copying
the reference-counting pointer. This avoids first incrementing and
then decrementing the reference-counting pointer.
This patch is adding a clearer design intent to all objects that would
not be complete without a port proxy by making the proxies members
rathen than dynamically allocated. In essence, if NULL would not be a
valid value for the proxy, then we avoid using a pointer to make this
clear.
The same approach is used for the methods using these proxies, such as
loadSections, that now use references rather than pointers to better
reflect the fact that NULL would not be an acceptable value (in fact
the code would break and that is how this patch started out).
Overall the concept of "using a reference to express unconditional
composition where a NULL pointer is never valid" could be done on a
much broader scale throughout the code base, but for now it is only
done in the locations affected by the proxies.
Port proxies are used to replace non-structural ports, and thus enable
all ports in the system to correspond to a structural entity. This has
the advantage of accessing memory through the normal memory subsystem
and thus allowing any constellation of distributed memories, address
maps, etc. Most accesses are done through the "system port" that is
used for loading binaries, debugging etc. For the entities that belong
to the CPU, e.g. threads and thread contexts, they wrap the CPU data
port in a port proxy.
The following replacements are made:
FunctionalPort > PortProxy
TranslatingPort > SETranslatingPortProxy
VirtualPort > FSTranslatingPortProxy
--HG--
rename : src/mem/vport.cc => src/mem/fs_translating_port_proxy.cc
rename : src/mem/vport.hh => src/mem/fs_translating_port_proxy.hh
rename : src/mem/translating_port.cc => src/mem/se_translating_port_proxy.cc
rename : src/mem/translating_port.hh => src/mem/se_translating_port_proxy.hh
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.
