[Qemu-devel] patch for qemu with newer gcc-3.4.x (support repz retq optimization for amd processors correctly)

2005-11-09 Thread Igor Kovalenko
Hi! It turned out that newer gcc produces very interesting code for op_goto_tbX and possibly other functions used by dyngen; in that it adds 'rep' prefix to return instruction. I have the following code in i386-softmmu/op.o: 84c0 : 84c0: 8b 05 00 00 00 00 mov0(%ri

Re: [Qemu-devel] patch for qemu with newer gcc-3.4.x (support repz retq optimization for amd processors correctly)

2005-11-09 Thread Paul Brook
> 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

Re: [Qemu-devel] patch for qemu with newer gcc-3.4.x (support repz retq optimization for amd processors correctly)

2005-11-09 Thread Igor Kovalenko
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

Re: [Qemu-devel] patch for qemu with newer gcc-3.4.x (support repz retq optimization for amd processors correctly)

2005-11-09 Thread Julian Seward
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 Novembe

Re: [Qemu-devel] patch for qemu with newer gcc-3.4.x (support repz retq optimization for amd processors correctly)

2005-11-09 Thread Jamie Lokier
> > 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 It should be trivial to take the _currently_ generated GCC code for all the architectures

Re: [Qemu-devel] patch for qemu with newer gcc-3.4.x (support repz retq optimization for amd processors correctly)

2005-11-09 Thread Jim C. Brown
On Thu, Nov 10, 2005 at 01:33:55AM +, Julian Seward wrote: > > 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 futu

Re: [Qemu-devel] patch for qemu with newer gcc-3.4.x (support repz retq optimization for amd processors correctly)

2005-11-09 Thread Jim C. Brown
On Thu, Nov 10, 2005 at 01:44:04AM +, Jamie Lokier wrote: > > > > 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 > > It should be tr

Re: [Qemu-devel] patch for qemu with newer gcc-3.4.x (support repz retq optimization for amd processors correctly)

2005-11-10 Thread Igor Kovalenko
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

Re: [Qemu-devel] patch for qemu with newer gcc-3.4.x (support repz retq optimization for amd processors correctly)

2005-11-11 Thread John R. Hogerhuis
On Thu, 2005-11-10 at 01:44 +, Jamie Lokier wrote: > > > > 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 > > It should be trivial t