On Mon, 2007-10-15 at 23:42 +0100, Paul Brook wrote:
VLE targets (x86, m68k) can translate almost a full page of instructions,
and a page boundary can be anywhere within that block. Once we've spanned
multiple pages there's not point stopping translation immediately. We may
as well
Well, we got the same behavior on PowerPC. What I was thinking of is
that if we fix the VLE problems, the fix, if done in a proper way, could
also allow benefit to RISC targets. What I don't know is; would we
really have a benefit not stopping translation on page boundaries ?
For VLE
Well, we got the same behavior on PowerPC. What I was thinking of is
that if we fix the VLE problems, the fix, if done in a proper way, could
also allow benefit to RISC targets. What I don't know is; would we
really have a benefit not stopping translation on page boundaries ?
[ I meant to say
On Tue, 2007-10-16 at 23:00 +0100, Paul Brook wrote:
Well, we got the same behavior on PowerPC. What I was thinking of is
that if we fix the VLE problems, the fix, if done in a proper way, could
also allow benefit to RISC targets. What I don't know is; would we
really have a benefit not
I suspect the best solution is to backtrack (remove the generated ops)
after decoding the insn if we discover we've passed a page boundary. The
ld*_code routines can simply return garbage (e.g. zero) if the read is
not on the first page.
The incorrect returned value may be target
On Mon, 2007-10-15 at 03:30 +0100, Paul Brook wrote:
On Sunday 14 October 2007, J. Mayer wrote:
Here's an updated version of the code fetch optimisation patch against
current CVS.
As a remainder, this patch avoid use of softmmu helpers to fetch the
code in most case. A new target define
+unsigned long phys_pc;
+unsigned long phys_pc_start;
These are ram offsets, not physical addresses. I recommend naming them as
such to avoid confusion.
Well, those are host addresses. Fabrice even suggested me to replace
them with void * to prevent confusion, but I kept
Paul Brook wrote:
[...]
The code itself looks ok, though I'd be surprised if it made a
significant difference. We're always going to hit the fast-path TLB
lookup case anyway.
It seems that the generated code for the code fetch is much more
efficient than the one generated when we get when
On Mon, 2007-10-15 at 17:01 +0100, Paul Brook wrote:
+unsigned long phys_pc;
+unsigned long phys_pc_start;
These are ram offsets, not physical addresses. I recommend naming them as
such to avoid confusion.
Well, those are host addresses. Fabrice even suggested me to
VLE targets (x86, m68k) can translate almost a full page of instructions,
and a page boundary can be anywhere within that block. Once we've spanned
multiple pages there's not point stopping translation immediately. We may
as well translate as many instructions as we can on the second page.
Here's an updated version of the code fetch optimisation patch against
current CVS.
As a remainder, this patch avoid use of softmmu helpers to fetch the
code in most case. A new target define TARGET_HAS_VLE_INSNS has been
added which is used to handle the case of an instruction that span 2
pages,
On Sunday 14 October 2007, J. Mayer wrote:
Here's an updated version of the code fetch optimisation patch against
current CVS.
As a remainder, this patch avoid use of softmmu helpers to fetch the
code in most case. A new target define TARGET_HAS_VLE_INSNS has been
added which is used to
On Sat, 2007-10-13 at 10:11 +0300, Blue Swirl wrote:
On 10/13/07, J. Mayer [EMAIL PROTECTED] wrote:
Forwarded Message
From: Jocelyn Mayer [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED], qemu-devel@nongnu.org
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] RFC
-devel@nongnu.org
Subject: Re: [Qemu-devel] RFC: Code fetch optimisation
Date: Fri, 12 Oct 2007 20:24:44 +0200
On Fri, 2007-10-12 at 18:21 +0300, Blue Swirl wrote:
On 10/12/07, J. Mayer [EMAIL PROTECTED] wrote:
Here's a small patch that allow an optimisation for code fetch
-To: [EMAIL PROTECTED], qemu-devel@nongnu.org
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] RFC: Code fetch optimisation
Date: Fri, 12 Oct 2007 20:24:44 +0200
On Fri, 2007-10-12 at 18:21 +0300, Blue Swirl wrote:
On 10/12/07, J. Mayer [EMAIL PROTECTED] wrote
J. Mayer wrote:
[snip]
My idea of always using the ldx_code_p function is that we may have the
occasion to make it more cleaver and make the slow case handle code
execution in mmio areas, when it will be possible.
Here's an updated patch. I added a definition TARGET_HAS_VLE_INSNS which
Here's a small patch that allow an optimisation for code fetch, at least
for RISC CPU targets, as suggested by Fabrice Bellard.
The main idea is that a translated block is never to span over a page
boundary. As the tb_find_slow routine already gets the physical address
of the page of code to be
On 10/12/07, J. Mayer [EMAIL PROTECTED] wrote:
Here's a small patch that allow an optimisation for code fetch, at least
for RISC CPU targets, as suggested by Fabrice Bellard.
The main idea is that a translated block is never to span over a page
boundary. As the tb_find_slow routine already
Blue Swirl wrote:
On 10/12/07, J. Mayer [EMAIL PROTECTED] wrote:
Here's a small patch that allow an optimisation for code fetch, at least
for RISC CPU targets, as suggested by Fabrice Bellard.
The main idea is that a translated block is never to span over a page
boundary. As the tb_find_slow
Blue Swirl wrote:
On 10/12/07, J. Mayer [EMAIL PROTECTED] wrote:
Here's a small patch that allow an optimisation for code fetch, at least
for RISC CPU targets, as suggested by Fabrice Bellard.
The main idea is that a translated block is never to span over a page
boundary. As the tb_find_slow
On Fri, 2007-10-12 at 18:21 +0300, Blue Swirl wrote:
On 10/12/07, J. Mayer [EMAIL PROTECTED] wrote:
Here's a small patch that allow an optimisation for code fetch, at least
for RISC CPU targets, as suggested by Fabrice Bellard.
The main idea is that a translated block is never to span over
Forwarded Message
From: Jocelyn Mayer [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED], qemu-devel@nongnu.org
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] RFC: Code fetch optimisation
Date: Fri, 12 Oct 2007 20:24:44 +0200
On Fri, 2007-10-12 at 18:21 +0300, Blue Swirl
22 matches
Mail list logo
