The use of gcc to generate the back end in QEMU's early days was a
clever way to get the project up and running quickly. But surely
now it would be better to transition to a handwritten backend, so
as to be independent future changes in gcc, and generally more robust?
J
On Wednesday 09 November 2005 19:51, Igor Kovalenko wrote:
> Paul Brook wrote:
> >> Notice the 'repz mov' sequence, which seems to be undocumented
> >> instruction. It seems to work somehow but chokes valgrind decoder.
> >> The following patch (against current CVS) fixes this problem,
> >
> > This patch is incorrect.
> >
> > It could match any number of other instructions that happen to end in
> > 0xf3. eg
> >
> > 0: c7 45 00 00 00 00 f3 movl $0xf3000000,0x0(%ebp)
> > 7: c3 ret
> >
> > IIRC the "rep; ret" sequence is to avoid a pipeline stall on Athlon CPUs.
> > Try tuning for a different CPU.
> >
> > Paul
> >
> >> Index: dyngen.c
> >> ===================================================================
> >> RCS file: /cvsroot/qemu/qemu/dyngen.c,v
> >> retrieving revision 1.40
> >> diff -u -r1.40 dyngen.c
> >> --- dyngen.c 27 Apr 2005 19:55:58 -0000 1.40
> >> +++ dyngen.c 9 Nov 2005 19:12:38 -0000
> >> @@ -1387,6 +1387,12 @@
> >> error("empty code for %s", name);
> >> if (p_end[-1] == 0xc3) {
> >> len--;
> >> + /* This can be 'rep ; ret' optimized return sequence,
> >> + * need to check further and strip the 'rep' prefix
> >> + */
> >> + if (len != 0 && p_end[-2] == 0xf3) {
> >> + len--;
> >> + }
> >> } else {
> >> error("ret or jmp expected at the end of %s", name);
> >> }
>
> OK I missed that...
> Then a discussion about gcc-4 turns into something much more interesting :)
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
