[Qemu-devel] Interpreter for QEMU

[Qemu-devel] Interpreter for QEMU

[malc]

Hello,

http://www.boblycat.org/~malc/1_iqemu.patch.gz conatains patch against CVS
version of QEMU that adds interpreted i386 target. Im hoping that someone
more apt than me can somehow breed it together with dynamic translator, so
that QEMU will be more viable for DOS emulation (interpreter can help some
with self-modifying code (so loved by DOS programmers) and/or highly
interleaved code/data, when host'spage faults take too much time)

I was able to boot FreeDOS and run some applications with this purely
interpreted target, though apparently there are still some bugs lurking.

To apply the patch:
$ cd cvs/version/of/qemu
$ zcat patch/location/1_iqemu.patch.gz | patch -p1
$ ./configure --target-list="i386-softmmu i386-interp"
$ gmake

Note that: interpreter is currently x86 specific and there is no FPU
support whatsoever.

Sincerely,
malc

-- 
mailto:malc@pulsesoft.com

Re: [Qemu-devel] Interpreter for QEMU

[Fabrice Bellard]

It would be interesting to find a way to generate both the dynamic 
translator and the interepreter from the same description. I see that 
you are using ML to generate the interpreter. This is an original choice!

It is true that a solution must be found to accelerate the DOS programs, 
especially when soft mmu is not in use. [When soft mmu is in use, it is 
possible to examine exactly each write access to see if the translated 
code is modified with a byte granularity].

Fabrice.

malc wrote:
> Hello,
> 
> http://www.boblycat.org/~malc/1_iqemu.patch.gz conatains patch against CVS
> version of QEMU that adds interpreted i386 target. Im hoping that someone
> more apt than me can somehow breed it together with dynamic translator, so
> that QEMU will be more viable for DOS emulation (interpreter can help some
> with self-modifying code (so loved by DOS programmers) and/or highly
> interleaved code/data, when host'spage faults take too much time)
> 
> I was able to boot FreeDOS and run some applications with this purely
> interpreted target, though apparently there are still some bugs lurking.
> 
> To apply the patch:
> $ cd cvs/version/of/qemu
> $ zcat patch/location/1_iqemu.patch.gz | patch -p1
> $ ./configure --target-list="i386-softmmu i386-interp"
> $ gmake
> 
> Note that: interpreter is currently x86 specific and there is no FPU
> support whatsoever.
> 
> Sincerely,
> malc
> 

Re: [Qemu-devel] Interpreter for QEMU

[malc]

On Tue, 4 Nov 2003, Fabrice Bellard wrote:

> It would be interesting to find a way to generate both the dynamic
> translator and the interepreter from the same description. I see that
> you are using ML to generate the interpreter. This is an original choice!

It was a _natural_ choice for me... (Well after i got really tired of
fighting my _first_ choice - AWK (when iconvert was still a throwaway toy)
;)

>
> It is true that a solution must be found to accelerate the DOS programs,
> especially when soft mmu is not in use. [When soft mmu is in use, it is
> possible to examine exactly each write access to see if the translated
> code is modified with a byte granularity].

I have tried running some demos with softmmu, it provides no noticable
benefit over hard one. If not pagefaults then constant translation block
generation/recycling will take its toll (but this probably covers mostly
real-mode or before watcom came into fashion p-mode programs, not that
i havent seen quite ingenious SMC in DOS4G/W applications)

Sincerely,
malc

-- 
mailto:malc@pulsesoft.com

Re: [Qemu-devel] Interpreter for QEMU

[Fabrice Bellard]

malc wrote:

>>It is true that a solution must be found to accelerate the DOS programs,
>>especially when soft mmu is not in use. [When soft mmu is in use, it is
>>possible to examine exactly each write access to see if the translated
>>code is modified with a byte granularity].
> 
> 
> I have tried running some demos with softmmu, it provides no noticable
> benefit over hard one. 

Write accesses are not verified with a byte granularity yet, but I will 
add it soon. It should accelerate the case where code and data are 
intermixed.

> If not pagefaults then constant translation block
> generation/recycling will take its toll (but this probably covers mostly
> real-mode or before watcom came into fashion p-mode programs, not that
> i havent seen quite ingenious SMC in DOS4G/W applications)

For self-modifying code, I agree that the translation/recycling stuff is 
_very_ slow...

Fabrice.