Hi,
2008/2/5, Fabrice Bellard [EMAIL PROTECTED]:
This is an SDL related issue (i.e. SDL may or may not use OpenGL to
display graphics). Fixing SDL for Mac OS X would also be interesting.
I think SDL trunk (1.3) supports OpenGL rendering more specifically
for various platforms.
Besides, on my
Hi,
2007/6/26, Karl Magdsick [EMAIL PROTECTED]:
With proper support from the compiler, it's theoretically possible on
x86-64 systems to use 32-bit pointers in long mode (16 general purpose
64-bit registers). (There's an instruction prefix that will cause the
CPU to perform 32-bit pointer
Hi,
2007/6/29, Paul Brook [EMAIL PROTECTED]:
I'd expect the overhead of SIGSEGV+mmap to be prohibitive. I don't have
numbers to back this up, but experience with MIPS system emulation shows that
TLB miss cost can have significant effect on overall performance.
I'd say this can't be worse than
Hi,
I'm sure someone's probably had a similar idea before, and it's
probably not
practical for some reason I'm overlooking-- but is there a reason
Qemu can't
dynamically translate library calls to use the native libraries
instead of
requiring emulated libraries as well?
It should be
-only) }
- host CPU (compiled as): { i386, x86_64 }
PS: I have not tested yet on MacOS X.
Regards,
Gwenole
2007-04-20 Gwenole Beauchesne [EMAIL PROTECTED]
* gcc4 host support.
--- qemu-0.9.0/target-i386/ops_template.h.gcc4 2005-02-21 20:23:59.0
+
+++ qemu-0.9.0/target
Hi,
The following patch increases max kernel size to 8 MB when qemu is invoked
with -kernel and -initrd. Otherwise, x86_64 kernel panics when loading the
initrd (e.g. Cooker/x86_64/isolinux/alt0/{vmlinuz,all.rdz}).
Thanks,
Gwenole.
2007-03-27 Gwenole Beauchesne [EMAIL PROTECTED
On Fri, 2 Feb 2007, Paul Robinson wrote:
But the T0, T1, and T2 registers are being saved for the benefit of the
host not the target.
FWIW, I use the following patch for Virtual Box on x86_64. The proper fix
would be to not globally allocate registers for the whole program but only
for the
Hi,
Patches and test binaries are here:
http://www.gibix.net/projects/qemu/
A screenshot:
http://www.gibix.net/projects/qemu/files/qemu-osx.png
I have not really tested graphically. But the owner of the iMac I was
using tried Windows ME and it worked:
http://toshi3.cocolog-nifty.com/blog/
Hi,
With those changes in place, the same boot-to-kdm process
requires only about 57 translations to be made, and 2
cache flushes to happen. Of course the cost is an extra
48M of memory use.
I faced a similar problem in Basilisk II. MacOS 8.x had a tendency to
invalidate the code cache
Hi,
This tries to enforce one single exit point per function. Mostly useful
with gcc4 patches.
--- qemu-0.8.0/target-i386/op.c.i386-FORCE_RET 2005-12-19 23:51:53.0
+0100
+++ qemu-0.8.0/target-i386/op.c 2006-02-12 17:51:40.0 +0100
@@ -1032,6 +1032,7 @@ void OPPROTO op_aaa(void)
Hi,
Case in point : I distinctly reember reading a convoluted thread in one
of the Debian lists about this /etc/alternative issue for gcc... Was I
drunk ? Or what ?
I don't know what all this rant is about but it's always best to keep the
system compiler as chosen by the distributor. If
Hi,
On 21/11/05, Richard Neill [EMAIL PROTECTED] wrote:
Dear All,
I thought you might like to know the following:
Neither Qemu 0.7.2 nor 0.7.1 will compile under gcc 4.0.1, which is
the default under Mandrake 2006. It works fine with the older 3.3.6
though.
i don't understand why it is
Hi,
The inlined patch hereunder adds more auxv entries, namely AT_PLATFORM and
AT_HWCAP. This e.g. makes it possible to use Mandriva Linux provided glibc
libraries.
Plain patch available at:
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/qemu/qemu-0.7.2-auxv.patch
2005-10-23 Gwenole
On Sun, 14 Aug 2005, Paul Brook wrote:
This is sufficient to run single-threaded NPTL enabled binaries. I've not yet
implemented the futex syscalls, so multithreaded applications probaby won't
work.
I followed another approach for our packages: don't use NPTL libraries.
On Sun, 9 Oct 2005, Michel Pelletier wrote:
A copule others on this thread mentioned that you can compile the kqemu
module with gcc 4 and the rest of qemu with gcc 3.x. Did this work for
you? Did it create a performance boost?
I don't think you'd gain much since most of the time is spent
On Fri, 26 Aug 2005, Pascal Terjan wrote:
do you use the same package version of qemu and dkms-qvm86 ?
Actually also make sure you don't have a stale qvm86 module already prior
to the dkms'ed variant from MDK. e.g. one you manually built and placed in
a more prioritized location than the output
On Wed, 3 Aug 2005, Herbert Poetzl wrote:
I update them almost each time I update the cooker packages.
but unfortunately I could not find a src rpm for
those binary mandriva rpms of qemu :/
cooker/SRPMS/contrib on any mirror you may find. Except proxad.net at this
time, which is a little
On Sun, 31 Jul 2005, Paul Brook wrote:
The gcc4 changes are a different matter. I discusses this with Fabrice on
IRC
shortly after submitting the patch. The patch is pretty invasive, high risk,
and potentially hard to debug and maintain.
Talking of which, I don't know if I have sent you
Hi,
From what I can tell, I can't see how the code
would ever work on any 64 bit machine - can anyone here confirm if this
is indeed the case?
AFAICS, slirp code in qemu cvs and other projects works on x86_64.
Really try CVS instead of 0.7.0. ;-)
Bye,
Gwenolé.
: I probably should have simply used the extern char __dot_sym
__asm__(.sym) trick from the HOST_SPARC case, which this patch clobbers.
What dot symbols were emitted on sparc host?
2005-06-02 Gwenole Beauchesne [EMAIL PROTECTED]
* dyngen.c: handle .LCn symbols.
--- qemu-0.7.0
20 matches
Mail list logo
