From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=41176 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PBNub-0001md-W7
	for qemu-devel@nongnu.org; Thu, 28 Oct 2010 04:32:42 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <tg@gmplib.org>) id 1PBNua-0001mg-JL
	for qemu-devel@nongnu.org; Thu, 28 Oct 2010 04:32:41 -0400
Received: from gmplib-02.nada.kth.se ([130.237.222.242]:47937
	helo=shell.gmplib.org) by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <tg@gmplib.org>) id 1PBNua-0001mS-D8
	for qemu-devel@nongnu.org; Thu, 28 Oct 2010 04:32:40 -0400
Subject: Re: [Qemu-devel] Which qemu ports actually work?
References: <86sjzssydf.fsf@shell.gmplib.org>
	<8642FB76-3D0B-4326-9C8B-B7ED8802B761@suse.de>
	<86r5fc22wx.fsf@shell.gmplib.org>
	<A48CA2D7-D9C3-4FA6-9C6E-15D3360ECEB8@suse.de>
	<86iq0o20lh.fsf@shell.gmplib.org>
	<DAD49D9A-902B-4011-9E25-56ABF8919288@suse.de>
	<8662wo112y.fsf@shell.gmplib.org>
	<55EA6A25-A935-4FFE-A610-D40E9E6F787A@suse.de>
From: Torbjorn Granlund <tg@gmplib.org>
Sender: tg@gmplib.org
Date: Thu, 28 Oct 2010 10:32:38 +0200
In-Reply-To: <55EA6A25-A935-4FFE-A610-D40E9E6F787A@suse.de> (Alexander Graf's
	message of "Wed\, 27 Oct 2010 01\:51\:25 -0700")
Message-ID: <868w1i4t09.fsf@shell.gmplib.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alexander Graf <agraf@suse.de>
Cc: qemu-devel Developers <qemu-devel@nongnu.org>

Alexander Graf <agraf@suse.de> writes:

  >  Please also keep in mind that PPC emulation is _very_ slow.
  >=20
  > Why is it slow?
=20=20
  Because we're flushing the TLB on almost every MMU opcode.

OK.  Does that mean the TLB never gets more than a single entry?
(I mean, do you flush the TLB before inserting a new entry into it?)

What is the reason for this flushing?

A related thing, related to cross endianess: I wrote a simulator many
years ago (around 1990) that turned memory "upside down" for cross
endianess.  I.e., a reference to address x was simulated as
*(memend-opsize-x), where memend points to the end of the area
simulating memory, opsize of the size in bytes of the operation.

The point of this is that one can use full-size native load or store
instructions, instead of many byte operations and shifts.

I never published this idea, but I assume it has been rediscovered and
is now a standard trick?

[Alex, excuse the duplicate, this message was bounced by nongnu.org's
MTA for bogus reasons.  It never appeared on the list.]

--=20
Torbj=F6rn