Discussion:
Hand written code generator #2
Paul Brook
2005-05-31 15:23:28 UTC
Permalink
I've made available a new version of my hand-written code generator for qemu.
The patch is getting rather large, so I've put it on a web server to avoid
spamming the list:
https://nowt.dyndns.org/patch.qemu_qop.gz

In principle it's very similar to the previous patch. The main difference is
that it now supports all target architectures, including 64-bit targets.

The i386 changes have been tested by booting knoppix and win2k and win98.
x86-64 tested by booting a debian amd64 install cd.
ppc chanages tested by booting a debina install cd and running nbench under
ppc-user.
My sparc debian cd doesn't boot under qemu (stops responding just after
loading the kernel). Does anyone have any images I could use for testing
sparc emulation?

To support 64-bit targets each qreg now has a "mode" which determines its
size. 64-bit qregs can be implemented using pairs of host registers on 32-bit
hosts, or single registers on 64-bit hosts.

ppc and sparc targets only have nominal support. I've done the bare minimum
needed to make them work. Arm is still the only target that really takes
advantage of any of the new functionality.

Next on my todo list is support for ppc and x86-64 hosts.

Paul
Jens Arm
2005-06-01 05:40:33 UTC
Permalink
Hi Paul

I get a compile errorif I try with latest qemu cvs:

../dyngen -o op.h op.o
../dyngen -c -o opc.h op.o
gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. -I/home/tux/tmp/qemu/target-sparc -I/home/tux/tmp/qemu -I/home/tux/tmp/qemu/host-i386 -I/home/tux/tmp/qemu/linux-user -I/home/tux/tmp/qemu/linux-user/sparc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/home/tux/tmp/qemu/fpu -I/home/tux/tmp/qemu/slirp -c -o translate-op.o /home/tux/tmp/qemu/translate-op.c
make[1]: *** Keine Regel vorhanden, um das Target »qregs.def«,
benötigt von »translate-qop.o«, zu erstellen. Schluss.
make[1]: Leaving directory `/home/tux/tmp/qemu/sparc-user'
make: *** [all] Fehler 1


Jens




On Tue, 31 May 2005 16:23:28 +0100
Post by Paul Brook
I've made available a new version of my hand-written code generator for qemu.
The patch is getting rather large, so I've put it on a web server to avoid
https://nowt.dyndns.org/patch.qemu_qop.gz
In principle it's very similar to the previous patch. The main difference is
that it now supports all target architectures, including 64-bit targets.
The i386 changes have been tested by booting knoppix and win2k and win98.
x86-64 tested by booting a debian amd64 install cd.
ppc chanages tested by booting a debina install cd and running nbench under
ppc-user.
My sparc debian cd doesn't boot under qemu (stops responding just after
loading the kernel). Does anyone have any images I could use for testing
sparc emulation?
To support 64-bit targets each qreg now has a "mode" which determines its
size. 64-bit qregs can be implemented using pairs of host registers on 32-bit
hosts, or single registers on 64-bit hosts.
ppc and sparc targets only have nominal support. I've done the bare minimum
needed to make them work. Arm is still the only target that really takes
advantage of any of the new functionality.
Next on my todo list is support for ppc and x86-64 hosts.
Paul
_______________________________________________
Qemu-devel mailing list
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Herbert Poetzl
2005-06-01 09:53:59 UTC
Permalink
Post by Jens Arm
Hi Paul
../dyngen -o op.h op.o
../dyngen -c -o opc.h op.o
gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. -I/home/tux/tmp/qemu/target-sparc -I/home/tux/tmp/qemu -I/home/tux/tmp/qemu/host-i386 -I/home/tux/tmp/qemu/linux-user -I/home/tux/tmp/qemu/linux-user/sparc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/home/tux/tmp/qemu/fpu -I/home/tux/tmp/qemu/slirp -c -o translate-op.o /home/tux/tmp/qemu/translate-op.c
make[1]: *** Keine Regel vorhanden, um das Target »qregs.def«,
benötigt von »translate-qop.o«, zu erstellen. Schluss.
make[1]: Leaving directory `/home/tux/tmp/qemu/sparc-user'
make: *** [all] Fehler 1
if you are more comfortable with a localized error message,
that's probably fine, but for postings to an english spoken
ml you should really use LANG=C LC_ALL=C ....

best,
Herbert
Post by Jens Arm
Jens
On Tue, 31 May 2005 16:23:28 +0100
Post by Paul Brook
I've made available a new version of my hand-written code generator for qemu.
The patch is getting rather large, so I've put it on a web server to avoid
https://nowt.dyndns.org/patch.qemu_qop.gz
In principle it's very similar to the previous patch. The main difference is
that it now supports all target architectures, including 64-bit targets.
The i386 changes have been tested by booting knoppix and win2k and win98.
x86-64 tested by booting a debian amd64 install cd.
ppc chanages tested by booting a debina install cd and running nbench under
ppc-user.
My sparc debian cd doesn't boot under qemu (stops responding just after
loading the kernel). Does anyone have any images I could use for testing
sparc emulation?
To support 64-bit targets each qreg now has a "mode" which determines its
size. 64-bit qregs can be implemented using pairs of host registers on 32-bit
hosts, or single registers on 64-bit hosts.
ppc and sparc targets only have nominal support. I've done the bare minimum
needed to make them work. Arm is still the only target that really takes
advantage of any of the new functionality.
Next on my todo list is support for ppc and x86-64 hosts.
Paul
_______________________________________________
Qemu-devel mailing list
http://lists.nongnu.org/mailman/listinfo/qemu-devel
_______________________________________________
Qemu-devel mailing list
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Paul Brook
2005-06-01 12:36:44 UTC
Permalink
Post by Jens Arm
Hi Paul
../dyngen -o op.h op.o
../dyngen -c -o opc.h op.o
gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I.
-I/home/tux/tmp/qemu/target-sparc -I/home/tux/tmp/qemu
-I/home/tux/tmp/qemu/host-i386 -I/home/tux/tmp/qemu/linux-user
-I/home/tux/tmp/qemu/linux-user/sparc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -I/home/tux/tmp/qemu/fpu -I/home/tux/tmp/qemu/slirp -c
-o translate-op.o /home/tux/tmp/qemu/translate-op.c make[1]: *** Keine
Regel vorhanden, um das Target »qregs.def«,
benötigt von »translate-qop.o«, zu erstellen. Schluss.
make[1]: Leaving directory `/home/tux/tmp/qemu/sparc-user'
make: *** [all] Fehler 1
This seems to be an issue with subversion. The patches it generates don't
correctly create empty files. Create the file manually
"touch target-sparc/qregs.def"
and it should work ok.

Paul
Christian MICHON
2005-06-02 10:53:10 UTC
Permalink
Paul,

on mingw32/x86-XP host, I see no difference on benchs with i386-softmmu.
You mentionned around 30% improvements. Any special compiler flags to
use, or compiler version?

I applied the patch on a fresh 0.7.0 version.
Christian
Post by Paul Brook
I've made available a new version of my hand-written code generator for qemu.
The patch is getting rather large, so I've put it on a web server to avoid
https://nowt.dyndns.org/patch.qemu_qop.gz
In principle it's very similar to the previous patch. The main difference is
that it now supports all target architectures, including 64-bit targets.
Paul Brook
2005-06-02 13:31:00 UTC
Permalink
Post by Christian MICHON
Paul,
on mingw32/x86-XP host, I see no difference on benchs with i386-softmmu.
You mentionned around 30% improvements. Any special compiler flags to
use, or compiler version?
I also said that the arm-user emulation was the only target that had been
converted enough to benefit from the new code. The optimization passes
only work on the new qops. Existing dyngen based ops are not touched.

On rereading the results I did the math wrong, I actually got a 15% speedup
(2.3 vs. 2.0), but everything else still holds.

To get the latest copy of my code you can do

svn co https://nowt.dyndns.org/svn/qemu/trunk qemu

Or for a diff of just my changes

svn diff https://nowt.dyndns.org/svn/qemu/cvs https://nowt.dyndns.org/svn/qemu/trunk

Paul
Christian MICHON
2005-06-02 13:36:53 UTC
Permalink
"Arm is still the only target that really takes advantage of any of
the new functionality."
Sorry I missed this line :(

I hope you will still consider x86 target before x86-64. You'd get a broader
audience for testing/debug.

If so, let us know. I haven't switched to svn yet...

Thanks anyway
Christian
Post by Paul Brook
I also said that the arm-user emulation was the only target that had been
converted enough to benefit from the new code. The optimization passes
only work on the new qops. Existing dyngen based ops are not touched.
On rereading the results I did the math wrong, I actually got a 15% speedup
(2.3 vs. 2.0), but everything else still holds.
Loading...