From: "J. Mayer" <l_indien@magic.fr>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-...
Date: Sat, 24 Nov 2007 02:55:54 +0100 [thread overview]
Message-ID: <1195869354.24893.72.camel@rapid> (raw)
In-Reply-To: <1195867970.24893.66.camel@rapid>
On Sat, 2007-11-24 at 02:32 +0100, J. Mayer wrote:
> On Sat, 2007-11-24 at 00:52 +0000, Paul Brook wrote:
> > > > By your own admission, we can get away with not calculating the
> > > > high 32 bit of the register. If follows that the high bits are completely
> > > > meaningless.
> > >
> > > Not completelly. There are even some way to do 64 bits computations when
> > > running in 32 bits mode... Some may see this as an architecture hack,
> > > but this gives the only way to switch from 32 bits to 64 bits mode (as
> > > the sixty-four MSR bits lies in the highest bits of the register).
> >
> > Anything that involves switching to 64-bit mode to see th results is irelevant
> > because we don't implement that.
> >
> > You can't have it both ways. Either you need to implement the full 64-bit gpr
> > for correctness, in which case I guess we're most of the way to scrapping
> > ppc-softmmu and using ppc64-softmmu all the time, or the high bits are not
> > part of the interesting CPU state.
>
> Yes, when running on a 64 bits host, we could avoid compiling
> ppc-softmmu. It's still interresting to use it on 32 bits host, as an
> optimisation, because it runs much faster than the ppc64-softmmu
> version.
>
> > I can believe that on some hosts it's cheaper to use a 64-bit gpr_t, and the
> > architecture/implementation is such that it gives the same results as a
> > 32-bit gpr_t. However this is an implementation detail, and should not be
> > exposed to the user.
I did forget one important point: it's not exposed to the qemu user.
The qemu log is a qemu developper tool.Most of the trace involved has to
be explicitally activated with specific defines in the Qemu code. The
qemu log is not to be of any help for a end-user, it's a tool for Qemu
development and bug reports.
>From the end-user side, the fact that GPR are implemented as 64 bits
values is never visible, even from the gdb stub. Then...
[...]
--
J. Mayer <l_indien@magic.fr>
Never organized
next prev parent reply other threads:[~2007-11-24 1:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-23 17:33 [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target- Paul Brook
2007-11-23 17:51 ` Jocelyn Mayer
2007-11-23 18:22 ` Paul Brook
2007-11-23 18:42 ` Jocelyn Mayer
2007-11-23 18:46 ` Jocelyn Mayer
2007-11-23 19:10 ` Paul Brook
2007-11-23 19:19 ` Jocelyn Mayer
2007-11-23 20:08 ` Jocelyn Mayer
2007-11-23 21:36 ` Paul Brook
2007-11-23 22:05 ` J. Mayer
2007-11-23 22:23 ` Paul Brook
2007-11-23 23:36 ` Thiemo Seufer
2007-11-24 19:39 ` Fabrice Bellard
2007-11-23 23:36 ` J. Mayer
2007-11-24 0:18 ` Thiemo Seufer
2007-11-24 0:52 ` Paul Brook
2007-11-24 1:02 ` Julian Seward
2007-11-24 1:32 ` J. Mayer
2007-11-24 1:55 ` J. Mayer [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-11-23 22:16 Jocelyn Mayer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1195869354.24893.72.camel@rapid \
--to=l_indien@magic.fr \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).