Re: [Qemu-devel] [RFC PATCH] s390x-linux-user

[Blue Swirl <blauwirbel@gmail.com>]

On 6/26/09, Paul Brook <paul@codesourcery.com> wrote:
> On Friday 26 June 2009, Blue Swirl wrote:
>  > On 6/26/09, Paul Brook <paul@codesourcery.com> wrote:
>  > > On Friday 26 June 2009, Blue Swirl wrote:
>  > >  > On 6/26/09, Ulrich Hecht <uli@suse.de> wrote:
>  > >  > >  There is a very peculiar S/390 instruction called "EXECUTE". What
>  > >  > > it does is to take another instruction stored somewhere in memory,
>  > >  > > logical-OR the second byte of the instruction with the LSB of R0 and
>  > >  > > then execute the result, without changing the instruction in memory
>  > >  > > or the program counter. Any idea how to implement this in QEMU?
>  > >  > > Currently, I'm interpreting the couple of instructions that GCC uses
>  > >  > > EXECUTE with, but in the long run that would amount to implementing
>  > >  > > a second emulator...
>  > >  >
>  > >  > Maybe something like this: Make a special TB of the EXECUTE
>  > >  > instruction and add LSB of R0 to TB flags for these TBs. Then you can
>  > >  > examine R0, OR and generate code at translation time. The TBs linking
>  > >  > to EXECUTE TB may need to be special too in order to track for R0.
>  > >
>  > > That's not sufficient. The results also depend on the referenced
>  > > instruction.
>  >
>  > Then add the second byte of the referenced instruction to TB flags? Or
>  > maybe just the result of the OR operation for compactness?
>
>
> No. You need the whole instruction. Which is fetched from memory, so is not
>  easily available when you're checking TB flags.
>  To do it this way, I think you'd need to split the instruction in two. The
>  first part would load the whole instruciton from memory, or with r0, then
>  store the result in an internal CPU pseudo-register to the whole instruction,
>  and cuse annother TB lookup. The second would generate code that cleared the
>  pseudo-register then executed the code that was stored in it.
>  You'd have to include the whole of the pseudo-register in TB_FLAGS, and I
>  doubt you've got enough bits for that.

How about cs_base then?

>  OTOH, tweaking the TCG interface so that it works as an interpreter shouldn't
>  be all that hard. It's something I've been considering to do for a while, and
>  would mean that you can build both interpreter and translator from the same
>  source.

Like by adding an interpreter TCG target? If it were in C only, it
could also serve as a portable (low performance) translator runtime.