Re: [Qemu-devel] [PATCH v2] Make target_phys_addr_t 64 bits unconditionally

[Stefan Weil <sw@weilnetz.de>]

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 <avi@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;