qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stuart Brady <sdbrady@ntlworld.com>
To: qemu-devel@nongnu.org
Cc: Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] [5949] target-ppc: memory load/store rework
Date: Sat, 13 Dec 2008 01:18:03 +0000	[thread overview]
Message-ID: <20081213011803.GC9457@miranda.arrow> (raw)
In-Reply-To: <E1L9kZm-0001Qw-HN@cvs.savannah.gnu.org>

On Mon, Dec 08, 2008 at 06:11:22PM +0000, Aurelien Jarno wrote:
> - Don't swap values twice for bit-reverse load/store functions
>   in little endian mode.

If I've read this correctly, it seems to me that we would still swap
twice on little endian hosts when when emulating little endian mode or
performing bit-reverse loads/stores.  Bit-reverse loads/stores under
little endian emulation on a little endian host would have actually
resulted in *three* byteswaps!

I'm not sure what the performance impact of this would be, but it's 
something that I've been wondering about while working on PA-RISC
emulation, which will also need to provide a little endian mode.

BTW, I'm wondering if it would be possible to optimise loads/stores with
a different endianness to the host on targets that require word aligned
addresses.  Instead of swapping bytes when loading/storing words,
addresses would be modified when loading/storing bytes.  For 32-bit
targets, what I'm suggesting is something similar to this (although I'm
not saying that the casting is a good idea!) :-

extern uint8_t memory[];

uint32_t ldul(target_ulong addr) {
  return *(uint32_t)&memory[addr];
}

uint32_t lduw(target_ulong addr) {
  return *(uint16_t)&memory[addr ^ 2];
}

uint32_t ldub(target_ulong addr) {
  return memory[addr ^ 3];
}

(It looks as though MIPS Magnum emulation might require something like
this for emulation of its big endian mode, anyway...)

Cheers,
-- 
Stuart Brady

  reply	other threads:[~2008-12-13  1:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-08 18:11 [Qemu-devel] [5949] target-ppc: memory load/store rework Aurelien Jarno
2008-12-13  1:18 ` Stuart Brady [this message]
2008-12-13  7:25   ` Blue Swirl
2008-12-13 11:17     ` Aurelien Jarno
2008-12-13 11:15   ` Aurelien Jarno

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=20081213011803.GC9457@miranda.arrow \
    --to=sdbrady@ntlworld.com \
    --cc=aurelien@aurel32.net \
    --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).