> > 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 tar
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
> 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
> 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 t
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
> > >
> > 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 secon
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 eve
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 usi
> > > +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,
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
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 h
On Sat, 2007-10-13 at 20:07 +0100, Thiemo Seufer 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.
> >
>
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 w
> > > > > 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
> > &
> > > > 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
> 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 <[EM
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
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 r
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 r
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 sp
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 alread
21 matches
Mail list logo
