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
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
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
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
>
> 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
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
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
> 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
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
