Am 04.10.2012 12:36, schrieb Avi Kivity:
The hassle and compile time overhead of maintaining both 32-bit and 64-bit
capable source isn't worth the tiny performance advantage which is seen on
a minority of configurations. Switch to compiling libhw only once, with
target_phys_addr_t unconditionally typedefed to uint64_t.
Signed-off-by: Avi Kivity <a...@redhat.com>
---
v2: no changes, but copied the maintainers of architectures that will
see their target_phys_addr_t changed as a result. Please view and/or
test.
.gitignore | 1 +
Makefile | 2 +-
Makefile.hw | 1 -
Makefile.target | 3 ---
configure | 34 ++++------------------------------
cpu-common.h | 2 +-
dma.h | 2 +-
hw/hw.h | 2 +-
hw/intel-hda.c | 8 +-------
hw/rtl8139.c | 6 +-----
monitor.c | 4 ----
target-ppc/mmu_helper.c | 4 +---
targphys.h | 19 +------------------
13 files changed, 13 insertions(+), 75 deletions(-)
Hi,
I noticed that you replaced target_phys_addr_t by uint64_t in two lines.
Are there plans to replace target_phys_addr_t everywhere?
Should new code use uint64_t, or should it continue to use
target_phys_addr_t?
Using target_phys_addr_t might make support for 128 bit in some years easier
because it allows identifying critical code,
although I think it will be difficult to avoid wrong use of either
target_phys_addr_t
or uint64_t as long as both are the same size.
Regards
Stefan W.
-#if TARGET_PHYS_ADDR_BITS > 32
- return low | ((target_phys_addr_t)high << 32);
-#else
- return low;
-#endif
+ return low | ((uint64_t)high << 32);
- *raddrp |= (target_phys_addr_t)(tlb->RPN & 0xF) << 32;
+ *raddrp |= (uint64_t)(tlb->RPN & 0xF) << 32;
