qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH 09/13] TARGET_ARCH2 is already known at conf


From: Stuart Brady
Subject: Re: [Qemu-devel] Re: [PATCH 09/13] TARGET_ARCH2 is already known at configure time and it is called target_cpu Remove re-construction in Makefile.target
Date: Wed, 1 Jul 2009 20:30:38 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

On Wed, Jul 01, 2009 at 08:21:12PM +0200, Juan Quintela wrote:
> TARGET_BASE_ARCH: architecture name (mips, sparc, ppc)
> TARGET_ARCH: Actual architecture
> TARGET_SUBARCH: change about TARGET_ARCH (sparc32plus, little/big endian
>                 variants) (was TARGET_ARCH2 and target_cpu)
> TARGET_ABI: call ABI for this TARGET_SUBARCH
> cpu = canonical name for the cpu, not sure how to relate this one with ARCH
> ARCH: where are we building, it is always the same than 'cpu' on
>       configure, it is only used on the Makefiles, but I would preffer
>       to only use one name for the same meaning.

Perhaps TARGET_CPU as the 'CPU architecture' (i.e. the name in the
target-* directory), and TARGET_ARCH as the 'subarch' (i.e. taking
big vs little-endian and 32 vs 64-bit into account)?

BTW, the handling of these definitions is duplicated in the configure
script for config.h and config.mak, and it'd be good to fix that.

I think it might be nicer to specify target_bigendian in the same way
that target_phys_bits is dealt with (and to cease assuming little-endian
by default).  The same probably applied to softfloat, although I do not
know whether defaulting to '$target_softfloat = "yes"' and then setting
that to "no" for the targets where it is not wanted would be preferred.

FWIW, the list of architectures that currently don't define
CONFIG_SOFTFLOAT seems to be:

   i386
   x86_64
   alpha
   sh4
   sh4eb

Also, I'm not sure whether setting target_has_{kqemu,kvm,xen} variables
where target_phys_bits is set would also be slightly cleaner... although
perhaps those particular architecture lists are unlikely to grow much...

I'm not sure how much of this you're interested in fixing, but I'll be
happy to post patches for any changes that you don't see as essential.

Cheers,
-- 
Stuart Brady




reply via email to

[Prev in Thread] Current Thread [Next in Thread]