qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 2/2] ppc: Use uintptr_t for arguments of ppc_tb_


From: malc
Subject: Re: [Qemu-devel] [PATCH 2/2] ppc: Use uintptr_t for arguments of ppc_tb_set_jmp_target
Date: Tue, 20 Mar 2012 03:16:51 +0400 (MSK)
User-agent: Alpine 2.00 (LNX 1167 2008-08-23)

On Mon, 19 Mar 2012, Andreas F?rber wrote:

> Am 19.03.2012 22:33, schrieb malc:
> > On Mon, 19 Mar 2012, Stefan Weil wrote:
> > 
> >> The previous commit changed function tb_set_jmp_target1 and is needed
> >> for w64 hosts.
> >>
> >> This patch is not needed for w64, but it synchronizes tb_set_jmp_target1
> >> and ppc_tb_set_jmp_target so that both functions have the same signature.

[..snip..]

> > 
> > This should become intptr_t then..
> 
> > That said ppc32 code assumes 32bit addresses, and ppc64 tcg_taget_long
> > wide ones.. IOW needs some thinking.
> 
> Hm? On both host platforms relevant here, Linux and Darwin, long and
> intptr_t should have the same width, on both ppc and ppc64, so no
> practical difference. I was about to add my Acked-by - where do you see
> issues? Or do you just see room for further code improvements elsewhere?
> 
> Andreas

There's AIX and BSDs. long and intpr_t having same width is not the 
issue, the issue is(can be/whatever) careless replacement, for instance
ppc64 defines tb_set_jmp_target in terms of tcg_out_b and it's argument
is tcg_target_long, and quoting[1]

  Elsewhere I have opinioned that the only purpose for having 
  more than one type of integer in your programming language is so that 
  programmers can pick the wrong one.

What i'm saying is - the mere fact that i have to think about the
issue at all is telling.

There's no doubt that x86_64 change is a good thing (fixes win64), here
too many types are involved already, makes me uncomfortable.

[1] http://permalink.gmane.org/gmane.comp.lang.caml.inria/36258

-- 
mailto:address@hidden



reply via email to

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