Ideally, we could force gcc to implement switch statements as indirect
jumps with jump tables inline with the code. However, this may not be
possible.
I think Nathaniel was just saying that gcc is likely generating
several hundred sequential if-else blocks for large switch statements.
This gives
http://fabrice.bellard.free.fr/qemu/kqemu-doc.html indicates kqemu is
only for x86 Linux 2.4.x and Linux 2.6.x, not PPC Xnu 7.9.x. Qemu
0.6.0 might also be too old to take advantage of kqemu.
If he used the installer from Free OS Zoo, this would seem to indicate
he doesn't know which compile opt
> (SDL is more-or-less considered obsolete in general, iiuc Fabrice wants the
> windows port of qemu to use the Win32API natively to handle graphics, while
> on *nix systems an X toolkit (such as Qt or GTK) is preferred.)
Out of curiosity, has GTK on Win32 been considered?
-Karl
__
> VMware handles kernel code. You are right that x86 code can't be 100%
> virtualized
> (even at the userland level) but VMware uses a lot of nasty disgusting tricks
> in order to work around them. (For example, playing with shadow pagetables
> so that a page of modified code is run but if the cod
> >
> Alright, but here's the rub. If a drive can be booted by a machine. Why
> can't it boot from Qemu if it's accessing the raw disk via the windows
> interface? This needs no messing with bios or disksize to boot of a
> regular machine.
>
I hope someone else will chime in, but my guess is that
I wrote:
> In order to pass the "D drive" to qemu, and actually give QEMU access
> to the entire raw HD, the "D drive" partition would have to fill the entire
> HD, and MS Windows would have to make the MBR available as part
> of the first (only, in this case) partition on the HD.
Here I'm of cour
gcc 4.x is known not to compile qemu, due to a register allocation bug in gcc.
Also, the current qemu code generator is an ugly hack that relies on some
specifics of gcc 3.x function implementation. There is work being done
on a _real_ code generator for qemu.
-Karl
On 11/1/05, Julien Lancien
Depends on if you're using the LP64 model (64-bit Linux, many other
*NIX) or the LLP64 model (Win64).
I guess Microsoft decided there was more code written for their system
that assumed longs were 32-bit than code that assumed pointers could
be stored in (unsigned) longs. For 64-bit MS Windows
