summaryrefslogtreecommitdiff
path: root/src/arch/x86/memhelpers.hh
AgeCommit message (Collapse)Author
2018-10-12x86: Use little endian packet accessors.Gabe Black
We know data is little endian, so we can use those accessors explicitly. Change-Id: I09aa7f1e525ad1346e932ce4a772b64bf59dc350 Reviewed-on: https://gem5-review.googlesource.com/c/13456 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Gabe Black <gabeblack@google.com>
2017-12-13x86: Rework how "split" loads/stores are handled.Gabe Black
Explicitly separate the way the data is represented in the underlying representation from how it's represented in the instruction. In order to make the ISA parser happy, the Mem operand needs to have a single, particular type. To handle that with scalar types, we just used uint64_ts and then worked with values that were smaller than the maximum we could hold. To work with these new array values, we also use an underlying uint64_t for each element. To make accessing the underlying memory system more natural, when we go to actually read or write values, we translate the access into an array of the actual, correct underlying type. That way we don't have non-exact asserts which confuse gcc, or weird endianness conversion which assumes that the data should be flipped 8 bytes at a time. Because the functions involved are generally inline, the syntactic niceness should all boil off, and the final implementation in the binary should be simple and efficient for the given data types. Change-Id: I14ce7a2fe0dc2cbaf6ad4a0d19f743c45ee78e26 Reviewed-on: https://gem5-review.googlesource.com/6582 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com>
2017-11-02alpha,arm,mips,power,riscv,sparc,x86,isa: De-specialize ExecContexts.Gabe Black
The ISA parser used to generate different copies of exec functions for each exec context class a particular CPU wanted to use. That's since been changed so that those functions take a pointer to the base ExecContext, so the code which would generate those extra functions can be removed, and some functions which used to be templated on an ExecContext subclass can be untemplated, or minimally less templated. Now that some functions aren't going to be instantiated multiple times with different signatures, there are also opportunities to collapse templates and make many instruction definitions simpler within the parser. Since those changes will be less mechanical, they're left for later changes and will probably be done in smaller increments. Change-Id: I0015307bb02dfb9c60380b56d2a820f12169ebea Reviewed-on: https://gem5-review.googlesource.com/5381 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
2016-08-15cpu, arch: fix the type used for the request flagsNikos Nikoleris
Change-Id: I183b9942929c873c3272ce6d1abd4ebc472c7132 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
2016-02-06arch, x86: add support for arrays as memory operandsSteve Reinhardt
Although the cache models support wider accesses, the ISA descriptions assume that (for the most part) memory operands are integer types, which makes it difficult to define instructions that do memory accesses larger than 64 bits. This patch adds some generic support for memory operands that are arrays of uint64_t, and specifically a 'u2qw' operand type for x86 that is an array of 2 uint64_ts (128 bits). This support is unused at this point, but will be needed shortly for cmpxchg16b. Ideally the 128-bit SSE memory accesses will also be rewritten to use this support. Support for 128-bit accesses could also have been added using the gcc __int128_t extension, which would have been less disruptive. However, although clang also supports __int128_t, it's still non-standard. Also, more importantly, this approach creates a path to defining 256- and 512-byte operands as well, which will be useful for eventual AVX support.
2016-01-17cpu. arch: add initiateMemRead() to ExecContext interfaceSteve Reinhardt
For historical reasons, the ExecContext interface had a single function, readMem(), that did two different things depending on whether the ExecContext supported atomic memory mode (i.e., AtomicSimpleCPU) or timing memory mode (all the other models). In the former case, it actually performed a memory read; in the latter case, it merely initiated a read access, and the read completion did not happen until later when a response packet arrived from the memory system. This led to some confusing things, including timing accesses being required to provide a pointer for the return data even though that pointer was only used in atomic mode. This patch splits this interface, adding a new initiateMemRead() function to the ExecContext interface to replace the timing-mode use of readMem(). For consistency and clarity, the readMemTiming() helper function in the ISA definitions is renamed to initiateMemRead() as well. For x86, where the access size is passed in explicitly, we can also get rid of the data parameter at this level. For other ISAs, where the access size is determined from the type of the data parameter, we have to keep the parameter for that purpose.
2016-01-17arch: don't call *Timing functions from *Atomic versionsSteve Reinhardt
The readMemAtomic/writeMemAtomic helper functions were calling readMemTiming/writeMemTiming respectively. This is functionally correct, since the *Timing functions are doing the same access initiation operation as the *Atomic functions (just that the *Atomic versions also complete the access in line). It also provides for some (very minimal) code reuse. Unfortunately, it's potentially pretty confusing, since it makes it look like the atomic accesses are somehow being converted to timing accesses. It also gets in the way of specializing the timing interface (as will be done in a future patch).
2014-10-16arch: Use shared_ptr for all FaultsAndreas Hansson
This patch takes quite a large step in transitioning from the ad-hoc RefCountingPtr to the c++11 shared_ptr by adopting its use for all Faults. There are no changes in behaviour, and the code modifications are mostly just replacing "new" with "make_shared".
2011-07-02ExecContext: Rename the readBytes/writeBytes functions to readMem and writeMem.Gabe Black
readBytes and writeBytes had the word "bytes" in their names because they accessed blobs of bytes. This distinguished them from the read and write functions which handled higher level data types. Because those functions don't exist any more, this change renames readBytes and writeBytes to more general names, readMem and writeMem, which reflect the fact that they are how you read and write memory. This also makes their names more consistent with the register reading/writing functions, although those are still read and set for some reason.
2011-07-02ISA: Use readBytes/writeBytes for all instruction level memory operations.Gabe Black