search for: dyngen

I downloaded the "QEMU 0.8.2 CVS20070120 + patches snapshot January 20th 2007" and it was compiled ok for "ppc-softmmu" but failed in the "sparc-softmmu" with the message: ../dyngen -o op.h op.o dyngen: ret; restore; not found at end of op_ldstub_kernel can someone tell me what to do or where can I find a QEMU software running on solaris/sparc to lunch linux processes? -- This message posted from opensolaris.org

Ralph Corderoy wrote: > Hi Tilmann, > > >> Nevertheless, it is unlikely that llvm-qemu will ever be much faster >> than regular qemu (by replacing its code generator completely, which >> it currently does), which is due to the fact that regular qemu has a >> very lightweight code generator (it basically only copies blocks of >> memory and performs some

Hi Tilmann, > Nevertheless, it is unlikely that llvm-qemu will ever be much faster > than regular qemu (by replacing its code generator completely, which > it currently does), which is due to the fact that regular qemu has a > very lightweight code generator (it basically only copies blocks of > memory and performs some patching to them and only does static > register

Hello > I'm implementing an LLVM backend for qemu-arm (by creating an ARM frontend > for LLVM - from what I understand a slightly different approach than the > original llvm-qemu project) I don't see the difference so far. Could you please explain? > and I've got to the point where I have to deal with Qemu's use of global register variables. Why? The whole point of

> > > Are there particular reasons why you want to translate to LLVM IR? > (E.g. the authors of the paper wanted to be able to use KLEE with > machine code) > > Hi Tilmann I want to do the same. Using KLEE with machine code. With such a framework, I could try to do the same that what is explained here :

Hi all, I'm implementing an LLVM backend for qemu-arm (by creating an ARM frontend for LLVM - from what I understand a slightly different approach than the original llvm-qemu project) and I've got to the point where I have to deal with Qemu's use of global register variables. From what I've read LLVM doesn't support GCC style register variables and the workaround was to

...u don't need to > go with all that hacks and workarounds The point of this is to provide an alternative backend to QEMU that can be run in a separate thread to generate optimised blocks, while working as transparently as possible. A nice property of TCG (QEMU's current JIT, which was dyngen when llvm-qemu was written) is that it's extremely fast at generating reasonable code - this approach keeps it in place while we do extra, possibly more expensive work out of sight. It might not be a pretty idea, but LLVM does generate some very tight code :) It's an experiment - humour...

I have uploaded a current source drop from the qemu subversion repository, to the download area. Additionally, there is a new Kernel kqemu module that will allow a 32-bit guest to run on a 64-bit host. The current source base uses a different code generator from the orignial Dyngen one. The new one is called "TCG" for "The Code Generator" and is supposed to fix the depenedency on gcc-3.x. This means that gcc4 and studio 11/12 could be used. Lastly, I''ve put up instructions on how to compile on OpenSolaris (OS200805) There is a known issue wi...

²Š'