Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-...

[J. Mayer]

On Fri, 2007-11-23 at 22:23 +0000, Paul Brook wrote:
> > > I think what you mean is that they work the way that ppc64 is defined, to
> > > remain compatible with ppc32.  IMHO this is entirely irrelevant as we're
> > > emulating a ppc32. You could replace the high bits with garbage and
> > > nothing would ever be able to tell the difference.
> >
> > PowerPC is a 64 bits architecture. PowerPC 32 on 32 bits host is
> > optimized not to compute the 32 highest bits, the same way it's allowed
> > to cut down the GPR when implementing a CPU that would not support the
> > 64 bits mode (but this is a tolerance, this is not the architecture is
> > defined).
> 
> No. PowerPC is defined as a 64-bit archirecure. However there is a subset of 
> this architecture (aka ppc32) that is a complete 32-bit architecture in its 
> own right. 

It used to be defined this way... years ago. The latest specifications
say that there is one 64 bits architecture with 2 computational modes.
They also say that an embedded implementation can avoid implementating
some parts or the whole 64 bits computation mode. To complicate the
situation, it's also required that "standard" implementation do all
computations on 64 bit values but that embedded implementations that
implement SPE extension do never modify the highest 32 bits of GPR if
they do not implement the 64 bits computation mode (but this restriction
do not exists if the implementation implements the 2 computation modes),
which explains why I added the gprh registers to be able to handle all
cases without ifdefs.

>  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).

> The qemu ppc32 emulation is implemented in such a way that on 64-bit hosts it 
> looks a lot like a ppc64 implementation. However this need not, and should 
> not be exposed to the user.
> 
> > OK. Those are real bugs to be fixed. I'll take a look.... But I'll try
> > not to break the GPR dump. In fact, GPR should always dumped as 64 bits,
> > even when runnig on 32 bits hosts. This would be more consistent with
> > the specification.
> 
> I disagree. qemu is implementing ppc32.

which does not exists.

>  Showing more than 32 bits of register 
> is completely bogus.

No. It's showing the full CPU state, which can be more than what the
application (or the OS, when running virtualized on a real CPU) could
see. The OS cannot see the whole CPU state, but Qemu must implement more
than the OS can see and is then able to dump it. 64 bits GPR is just a
specific case of a general behavior.

>  Any differences between a 32-bit host and a 64-bit host 
> are a qemu bug. If you display 64 bits, then those 64 bits had better be the 
> same when run on 32-bit hosts.

Why ? The idea is that it costs too much to keep the whole state when
running on a 32 bits host, then we act as a restricted embedded
implementation. When the host CPU allows it without any extra cost, we
act as the specification defines we should. This is a choice. Once
again, this choice can be discussed and may be changed if I get
convinced it would be better not to act this way. But this behavior is
sure not bugged, it exactly follows (or may say should exactly if well
implemented) the PowerPC specification.

-- 
J. Mayer <address@hidden>
Never organized