[Qemu-devel] Help needed: how to boot qemu arm image on i386 host pc
hi, can anyone provide me some help? how to boot qemu arm image on i386 target? i have 2 observations. 1. On qemu-0.8.2, uncompressing starts and then stops at booting kernel. 2. On qemu-0.9.1, nothing happens, no messages on the console. regards, sathish. Meet people who discuss and share your passions. Go to http://in.promos.yahoo.com/groups
Re: [Qemu-devel] Using multiple cores in qemu was Re: threads on qemu
I'm just trying to think of ways to improve, so don't hurt me too much. What about splitting up the CPU and other functions into their own threads? The CPU emulation is probably the biggest thing that uses the CPU, the second biggest the display(?). From reading the past e-mails, the only thing that might stop this from working is the virtual timing, right? In what way could this be fixed, and will it make qemu faster? - Original Message - From: "William Pearson" <[EMAIL PROTECTED]> To: Sent: Monday, January 21, 2008 10:59 AM Subject: [Qemu-devel] Using multiple cores in qemu was Re: threads on qemu > Still, is there a way to make qemu take advantage of multiple cores? They are pretty commonplace in new computers (is there any selling computer that doesn't have multiple cores?). It depends on what you want to do. You could always run two or more copies of qemu and set up a small networked cluster of the architecture you want to emulate. Each emulator should go on to a different core. Might be useful when compiling things in qemu or doing other processor bound tasks. Will Pearson
Re: [Qemu-devel] PS/2 mouse support for FC4 guest broken in QEMU 0.9.1
Thanks for the tutorial on how to use git bisection ;-)
In fact, whatever version control system you use, I think you spend most of
time recompiling and testing stuff...
Anyway, on the core problem I'm pointing out, does someone have any clue on
what should be done ? Should the revision 1.24 of
hw/pckbd.c ("QEMU keyboard issue with Gujin-2.2") be reverted ? Is there a way
to get FC4 to work again, and "Gujin" at the same time ? Is the patch of
revision 1.24 the right fix for Gujin and another additionnal fix is required
for the FC4 issue (presumably related to Linux kernel version 2.6.11) or
should it be reverted and a better fix found for Gujin ?
I tried to follow the discussion about that topic
(http://www.mail-archive.com/qemu-devel%40nongnu.org/msg12455.html) but I'm
afraid I'm lost in the details.
Best regards
Le Monday 21 January 2008 00:54:27, vous avez écrit :
> Hi,
>
> On Sun, 20 Jan 2008, Even Rouault wrote:
> > After quite a lot of CVS bisection, [...]
>
> Not wanting to advertise git, but to help other people needing to bisect
> efficiently: here is a recipe how to do this with git.
>
> 1. get git (obviously)
>
> 2. $ git clone git://repo.or.cz/qemu.git/
>(it is a git mirror of git://git.kernel.dk/data/git/qemu.git, so if you
> do not want to be nice to Jens' server, you can go there directly)
>
> 3. Find out what was the last good revision. If you have an approximate
>date take the first "commit" of the output of
>
> $ cd qemu/
> $ git log --until="2007/09/07"
>
>(It would show a line beginning with "commit " and followed by a
> 40-character hex sequence; copy that sequence)
>
> 4. Start the bisection
>
> $ git bisect start
> $ git bisect bad HEAD
> $ git bisect good 85f8a4e8bae4df3983a5f1efd62b7942417bb89b
>
>Obviously, you have to use the sequence you copied in 3.
>
> 5. Compile, test, and call
>
> $ git bisect good
>
>or
>
> $ git bisect bad
>
>after the test, depending if the tested revision is good or -- you
>guessed it -- bad.
>
> 6. Repeat 5. until git tells you which is probably the bad commit. Then
>scrap this clone, or go back to the CVS HEAD with
>
> $ git bisect reset
>
> You are literally guaranteed to test the minimal amount of revisions with
> this procedure.
>
> Hth,
> Dscho
Re: [Qemu-devel] qemu softmmu_header.h
Hi, On Mon, 21 Jan 2008, Fabrice Bellard wrote: > Johannes Schindelin wrote: > > > On Mon, 21 Jan 2008, Fabrice Bellard wrote: > > > > > CVSROOT: /sources/qemu > > > Module name: qemu > > > Changes by: Fabrice Bellard08/01/21 15:07:18 > > > > > > Modified files: > > > . : softmmu_header.h > > > Log message: > > > fixed register constraint > > > > > > CVSWeb URLs: > > > http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_header.h?cvsroot=qemu&r1=1.18&r2=1.19 > > > > As has been pointed out already, this breaks compilation _at least_ > > with gcc 3.4.2 on MinGW. > > If it does, it is a very weird gcc bug. The previous code was clearly > incorrect. Ha! Your code compiles. And you know why? Because you only said "#if DATA_SIZE == 1", and did not add " || DATA_SIZE == 2". Now, I am out of my depth here; no idea what _should_ be correct. Ciao, Dscho P.S.: Oh, and I ran a small Linux image with it, too, so it appears that your patch does _not_ break anything. IOW I was wrong. Sorry.
[Qemu-devel] Using multiple cores in qemu was Re: threads on qemu
> > Still, is there a way to make qemu take advantage of multiple cores? They > are pretty commonplace in new computers (is there any selling computer that > doesn't have multiple cores?). It depends on what you want to do. You could always run two or more copies of qemu and set up a small networked cluster of the architecture you want to emulate. Each emulator should go on to a different core. Might be useful when compiling things in qemu or doing other processor bound tasks. Will Pearson
Re: [Qemu-devel] qemu softmmu_header.h
Johannes Schindelin wrote: Hi, On Mon, 21 Jan 2008, Fabrice Bellard wrote: CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard 08/01/21 15:07:18 Modified files: . : softmmu_header.h Log message: fixed register constraint CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_header.h?cvsroot=qemu&r1=1.18&r2=1.19 As has been pointed out already, this breaks compilation _at least_ with gcc 3.4.2 on MinGW. If it does, it is a very weird gcc bug. The previous code was clearly incorrect. Fabrice.
Re: [Qemu-devel] threads on qemu
On Mon, Jan 21, 2008 at 09:57:54AM -0700, C.W. Betts wrote: > Still, is there a way to make qemu take advantage of multiple cores? They > are pretty commonplace in new computers (is there any selling computer that > doesn't have multiple cores?). If you've got recent x86 CPUs, then they may well have hardware virtualization support, in which case you can use KVM which can take advantage of multiple cores. At least for native host/guest i686 & x86_64 combos. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Re: [Qemu-devel] threads on qemu
Still, is there a way to make qemu take advantage of multiple cores? They are pretty commonplace in new computers (is there any selling computer that doesn't have multiple cores?). - Original Message - From: "Johannes Schindelin" <[EMAIL PROTECTED]> To: "C.W. Betts" <[EMAIL PROTECTED]> Cc: Sent: Monday, January 21, 2008 9:10 AM Subject: Re: [Qemu-devel] threads on qemu Hi, On Mon, 21 Jan 2008, C.W. Betts wrote: I was thinking, maybe qemu could use threads for at least every processor it emulates (on emulated smp computers) and, at the most, every single device emulated. This would help users who have multiple cores, but it might impact performance on those of us who don't. This is an idea that comes up every once in a while: http://lists.gnu.org/archive/html/qemu-devel/2007-07/msg00369.html Ciao, Dscho
[Qemu-devel] [patch] cocoa.m - Core Graphics support
This is a complete rewrite of cocoa.m to support Core Graphics.
As mentioned in earlier threads, the QuickDraw API is depreciated
starting with OS X 10.4.
Now with OS X 10.5 it won't even compile QuickDraw code on x86_64.
This implementation of cocoa.m has the following features:
[new] partial drawing of the window as needed, implemented with CG.
[new] fullscreen support
[new] tablet support
[new] View menu and item to enter Fullscreen (cmd-f)
[new] Help menu and items to show qemu-doc.html (cmd-?) and qemu-
tec.html in the OS X "Help Viewer"
[new] -name is shown in Title-bar of window
[fix] Application menu creation for 10.4+ (API is private as of 10.4)
[fix] Mouse-clicks on the guests window widgets are no longer
intercepted
[fix] apple keyboard shortcuts forwarded (minimize (cmd-m), hide QEMU
(cmd-h), quit QEMU (cmd-q))
It should compile on ppc/intel starting form 10.3 (10.2 with the known
workarounds).
Please test and comment
Mike
File as .gz
http://www.kberg.ch/qemu/091patches/cocoa.m.gz
/*
* QEMU Cocoa CG display driver
*
* Copyright (c) 2008 Mike Kronenberg
*
* Permission is hereby granted, free of charge, to any person
obtaining a copy
* of this software and associated documentation files (the
"Software"), to deal
* in the Software without restriction, including without limitation
the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/
or sell
* copies of the Software, and to permit persons to whom the Software
is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be
included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN
* THE SOFTWARE.
*/
#import
#include "qemu-common.h"
#include "console.h"
#include "sysemu.h"
//#define DEBUG
#ifdef DEBUG
#define COCOA_DEBUG(...) { (void) fprintf (stdout, __VA_ARGS__); }
#else
#define COCOA_DEBUG(...) ((void) 0)
#endif
#define cgrect(nsrect) (*(CGRect *)&(nsrect))
#define COCOA_MOUSE_EVENT \
if (isTabletEnabled) { \
kbd_mouse_event((int)(p.x * 0x7FFF / screen.width), (int)
((screen.height - p.y) * 0x7FFF / screen.height), 0, buttons); \
} else if (isMouseGrabed) { \
kbd_mouse_event((int)[event deltaX], (int)[event deltaY],
0, buttons); \
} else { \
[NSApp sendEvent:event]; \
}
typedef struct {
int width;
int height;
int bitsPerComponent;
int bitsPerPixel;
} QEMUScreen;
int qemu_main(int argc, char **argv); // main defined in qemu/vl.c
NSWindow *normalWindow;
id cocoaView;
static void *screenBuffer;
int gArgc;
char **gArgv;
// keymap conversion
int keymap[] =
{
// SdlImacImacHSdlH104xtH 104xtC sdl
30, // 0 0x000x1eA QZ_a
31, // 1 0x010x1fS QZ_s
32, // 2 0x020x20D QZ_d
33, // 3 0x030x21F QZ_f
35, // 4 0x040x23H QZ_h
34, // 5 0x050x22G QZ_g
44, // 6 0x060x2cZ QZ_z
45, // 7 0x070x2dX QZ_x
46, // 8 0x080x2eC QZ_c
47, // 9 0x090x2fV QZ_v
0, // 10 0x0AUndefined
48, // 11 0x0B0x30B QZ_b
16, // 12 0x0C0x10Q QZ_q
17, // 13 0x0D0x11W QZ_w
18, // 14 0x0E0x12E QZ_e
19, // 15 0x0F0x13R QZ_r
21, // 16 0x100x15Y QZ_y
20, // 17 0x110x14T QZ_t
2, // 18 0x120x021 QZ_1
3, // 19 0x130x032 QZ_2
4, // 20 0x140x043 QZ_3
5, // 21 0x150x054 QZ_4
7, // 22 0x160x076 QZ_6
6, // 23 0x170x065 QZ_5
13, // 24 0x180x0d= QZ_EQUALS
10, // 25 0x190x0a9 QZ_9
8, // 26 0x1A0x087 QZ_7
12, // 27 0x1B0x0c- QZ_MINUS
9, // 28 0x1C0x098 QZ_8
11, // 29 0x1D0x0b0 QZ_0
27, // 30 0x1E0x1b]
Re: [Qemu-devel] threads on qemu
Hi, On Mon, 21 Jan 2008, C.W. Betts wrote: > I was thinking, maybe qemu could use threads for at least every > processor it emulates (on emulated smp computers) and, at the most, > every single device emulated. This would help users who have multiple > cores, but it might impact performance on those of us who don't. This is an idea that comes up every once in a while: http://lists.gnu.org/archive/html/qemu-devel/2007-07/msg00369.html Ciao, Dscho
Re: [Qemu-devel] qemu softmmu_header.h
Hi, On Mon, 21 Jan 2008, C.W. Betts wrote: > Builds fine on MinGW gcc 3.4.5 Maybe it was a combination of changes? I don't remember. Just to make sure, I will recompile and test again, but that will have to wait until after work. Ciao, Dscho P.S.: do other posters also get that SMTP error while sending to [EMAIL PROTECTED]
Re: [Qemu-devel] threads on qemu
On Monday 21 January 2008, C.W. Betts wrote: > I was thinking, maybe qemu could use threads for at least every processor > it emulates (on emulated smp computers) and, at the most, every single > device emulated. This would help users who have multiple cores, but it > might impact performance on those of us who don't. Please read previous discussions on this mailing list. I'd be surprised if putting device emulation in a separate thread makes much difference. The really slow bits (waiting for IO to complete) are already asynchronous. Most other device accesses are very short, so you'd waste more time through synchronisation than you gain from putting them is a separate thread. Splitting multiple CPUs into multiple threads is extremely hard to get right, especially when your host system provides less strict ordering and atomicity guarantees than those required by the guest system. Paul
[Qemu-devel] threads on qemu
I was thinking, maybe qemu could use threads for at least every processor it emulates (on emulated smp computers) and, at the most, every single device emulated. This would help users who have multiple cores, but it might impact performance on those of us who don't. Just an idea I'm throwing out.
[Qemu-devel] USB reset device
My question is connected with the following: /* specific usb messages, also sent in the 'pid' parameter */ #define USB_MSG_ATTACH 0x100 #define USB_MSG_DETACH 0x101 #define USB_MSG_RESET0x102 This is some lines, in "usb.h" file in qemu sources. Is this some type of standard, and where I can read documentation, about? I want to ask also the following. If some device is connected to USB port, and I reset the port - what happen? In qemu sources we have: 1. Something (non interesting for me) ... 2. Reset all devices. 3. Change the state of devices from "reset" to "attached". Is this normal? To enumerate device (i.e. SET_ADDRESS) it is necessary to reset explicitly device first (reset port is not *enough*). R.
Re: [Qemu-devel] qemu softmmu_header.h
Builds fine on MinGW gcc 3.4.5 - Original Message - From: "Johannes Schindelin" <[EMAIL PROTECTED]> To: "Fabrice Bellard" <[EMAIL PROTECTED]> Cc: Sent: Monday, January 21, 2008 8:23 AM Subject: Re: [Qemu-devel] qemu softmmu_header.h Hi, On Mon, 21 Jan 2008, Fabrice Bellard wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Fabrice Bellard 08/01/21 15:07:18 Modified files: . : softmmu_header.h Log message: fixed register constraint CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_header.h?cvsroot=qemu&r1=1.18&r2=1.19 As has been pointed out already, this breaks compilation _at least_ with gcc 3.4.2 on MinGW. Thanks, Dscho
Re: [Qemu-devel] WE NEED GCC 4 please
> Well, what about adding a new backend phase to gcc generating what we > expect for our purpose? Ok, it is rather easy to have a branch in gcc, > harder to have it accepted in the main-stream gcc... :-) With a good > argumentation... IMHO (as a full time gcc developer) it's easier to just implement a code generator from scratch. Paul
Re: [Qemu-devel] qemu softmmu_header.h
Hi, On Mon, 21 Jan 2008, Fabrice Bellard wrote: > CVSROOT: /sources/qemu > Module name: qemu > Changes by: Fabrice Bellard08/01/21 15:07:18 > > Modified files: > . : softmmu_header.h > > Log message: > fixed register constraint > > CVSWeb URLs: > http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_header.h?cvsroot=qemu&r1=1.18&r2=1.19 As has been pointed out already, this breaks compilation _at least_ with gcc 3.4.2 on MinGW. Thanks, Dscho
[Qemu-devel] qemu softmmu_header.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard08/01/21 15:07:18 Modified files: . : softmmu_header.h Log message: fixed register constraint CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_header.h?cvsroot=qemu&r1=1.18&r2=1.19
Re: [Qemu-devel] WE NEED GCC 4 please
> On Mon, 21 Jan 2008 11:18:53 + (GMT), Johannes Schindelin <[EMAIL > PROTECTED]> said: Johannes> The miniops right now are implemented as plain C commands. Johannes> If the "good" gcc guys would not have insisted on not having Johannes> an option to force the "ret" or "jmp" statement at the end Johannes> of the function, we could use them for _all_ processors. Well, what about adding a new backend phase to gcc generating what we expect for our purpose? Ok, it is rather easy to have a branch in gcc, harder to have it accepted in the main-stream gcc... :-) With a good argumentation... -- Ronan KERYELL |\/ Tel:(+33|0) 2.29.00.14.15 Département Informatique |/) Fax:(+33|0) 2.29.00.12.82 TÉLÉCOM Bretagne, CS 83818KGSM:(+33|0) 6.13.14.37.66 F-29238 PLOUZANÉ CEDEX 3 |\ E-mail: [EMAIL PROTECTED] FRANCE| \ http://enstb.org/~keryell
Re: [Qemu-devel] qemu new is release, changelog ?
Jérôme PRIOR wrote: > Hi, qemu 0.9.1 is released, but the changelog is complete ? > > On irc I read : use -disc ... so I launch my new qemu and I see lot of > news options ! > > Is there other corrections done, not writting on che ChangeLog on the > site, like better usage of qcow2 ? Only the most notable changes are mentioned in the ChangeLog. It seems some of them (-like -drive) were forgotten. Thiemo
Re: [Qemu-devel] WE NEED GCC 4 please
> > > As it is, Fabrice's code generator will most likely be something > > > similar to Paul's qops, which means that you have to invent a > > > "primitive C" in which to write the miniops, and you will have to > > > write a backend for _each_ and _every_ host CPU you support. It's not a terribly big deal. Writing backends is a lot easier than writing front ends, since the back end can just emit some small convenient subset of target instructions, whereas the front ends have to deal with every stupid, obscure, weird-ass instruction that ever shows up. QEMU is not the first project to post-process gcc's output. The Glasgow Haskell Compiler (http://en.wikipedia.org/wiki/Glasgow_Haskell_Compiler) did that for many years and it was always an immense amount of hassle tracking the changes to gcc's code generation. Having a completely-independent-of-everything, standalone code generator is definitely a lot easier in the end. > Given the unwillingness of Fabrice to rely on some external project, > though, I gave up even before I had something even rudimentary. Perhaps Fabrice could commit this code generator on a branch, even if it is not perfect yet. That would at least provide something "real" to assess; so far all we have is rumour and speculation. J
Re: [Qemu-devel] WE NEED GCC 4 please
Hi, On Mon, 21 Jan 2008, Andreas Färber wrote: > Am 21.01.2008 um 12:18 schrieb Johannes Schindelin: > > > The miniops right now are implemented as plain C commands. If the > > "good" gcc guys would not have insisted on not having an option to > > force the "ret" or "jmp" statement at the end of the function, we > > could use them for _all_ processors. > > > > As it is, Fabrice's code generator will most likely be something > > similar to Paul's qops, which means that you have to invent a > > "primitive C" in which to write the miniops, and you will have to > > write a backend for _each_ and _every_ host CPU you support. > > Has anyone looked into the idea of manually generating machine > instructions through preprocessor macros at runtime, then jumping there? > That's what the Mono JIT does, leaving C compilers completely out of the > picture. I had looked at GNU lightning briefly (but it only supports x86, SPARC and PowerPC), and at LLVM (but it was too complex, and only supports JITting for X86, X86-64, PowerPC and PowerPC-64; although they have "An easily retargettable code generator, which currently supports X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, and IA-64.). Given the unwillingness of Fabrice to rely on some external project, though, I gave up even before I had something even rudimentary. Ciao, Dscho
Re: [Qemu-devel] WE NEED GCC 4 please
Am 21.01.2008 um 12:18 schrieb Johannes Schindelin: The miniops right now are implemented as plain C commands. If the "good" gcc guys would not have insisted on not having an option to force the "ret" or "jmp" statement at the end of the function, we could use them for _all_ processors. As it is, Fabrice's code generator will most likely be something similar to Paul's qops, which means that you have to invent a "primitive C" in which to write the miniops, and you will have to write a backend for _each_ and _every_ host CPU you support. Has anyone looked into the idea of manually generating machine instructions through preprocessor macros at runtime, then jumping there? That's what the Mono JIT does, leaving C compilers completely out of the picture. But apart from it being lots of work to start from scratch and for each and every host CPU, if translating at instruction level rather than method level it would require lots of jumps between instruction decoding and generated instructions though. Andreas
Re: AW: Re: [Qemu-devel] VMport patch
Mark Williamson wrote: > > > I think it would be great to maintain compatibility with the binary-only > > > versions of the vm tools though. > > > > But you're changing the semantics of the x86 instruction set. You > > potentially break a real operating system. It also eliminates the > > possibility of nesting with something like kqemu because you can't trap > > all PIO operations. > > Maybe have a commandline flag, and have it switched off by default? > Or, even better, would be to detect valid vmware tools behaviour and > switch it on iff that happened; the default being to behave normally > for OSes that aren't running the VMware tools.. When nesting with kqemu/kvm, and you run a VMware tool inside the inner emulator, the question is should the tool control the inner emulator or the outer one? Most often you'll want the inner one. But _at the same time_, tools run in the outer emulator should not trap, but control the outer one. So neither of the simple defaults gives the desired behaviour. Those defaults being (1) disallow the VMware I/Os from bypassing privilege checking, or (2) allow the VMware I/Os to bypass privilege checking We can get sensible behaviour when nesting, but it's a little more complicated: (a) Allow VMware tools to do their thing with I/O, bypassing I/O privelege checking. (b) Add a function (it must be per-emulated-CPU) where something like kqemu/kvm run inside the outer emulator can request to disable the special function of those I/O ports while it is running - so the kqemu/kvm receives traps for them instead, and the VMware tools run inside the inner emulator are handled by the inner emulator. VMware tools run inside the outer emulator will continue to be handled by the outer emulator - because this function to trap them is only active them kqemu/kvm are running. (c) It might be possible that the function in (b) could be automatic, without requiring changes to kqemu/kvm/(many others), if there's a reliable way for the outer emulator to detect an emulator. At least, it should be possible in the case of kvm and anything else using Pacifica/VT because there is already a CPU state for it, and vm86 should be counted too so that DOS and DPMI emulators also work automatically. An explicit switch should be available, though, for others. Despite the above, I'm not convinced that VMware tools should be able to bypass privilege checking at all. It's perfect reasonable that they should request privilege for controlling the machine, just like any other tools that control the machine (real or virtual), e.g. hwclock. However, if there's a consensus that privilege checking should be allowed, to behave more like VMware, either by default or by a command line option, then please think about the suggested approach to making sure that nestable emulators work (or can work) without affecting the behaviour of tools in either level of emulator. -- Jamie
Re: [Qemu-devel] WE NEED GCC 4 please
Hi... On Jan 21, 2008 6:18 PM, Johannes Schindelin <[EMAIL PROTECTED]> wrote: > As it is, Fabrice's code generator will most likely be something similar > to Paul's qops, which means that you have to invent a "primitive C" in > which to write the miniops, and you will have to write a backend for > _each_ and _every_ host CPU you support. > > Things clearer now? Loud and clear, thanks Johannes :) regards, Mulyadi.
Re: [Qemu-devel] WE NEED GCC 4 please
Hi, On Mon, 21 Jan 2008, Mulyadi Santosa wrote: > If I may jump into the pool... > > > I plan to work around the MinGW issue by guarding the offending part > > by "#ifdef GCC...", even if I have been told that it works only by > > chance (but it works, whereas any other option I tried does not). Thanks for not saying who you quote. > Ehm, should we better wait a bit for fabrice to complete his code code > generator? I said "work around", didn't I? And so far I have not seen anything but an announcement that Fabrice will start "in the next days". > but I just think it will save us from more work in the future (making it > always gcc 3 compatible) and thus progress to more demanding area like > truly support SVM/VT, better SMP and so on. Most unlikely will it save us more work. The miniops right now are implemented as plain C commands. If the "good" gcc guys would not have insisted on not having an option to force the "ret" or "jmp" statement at the end of the function, we could use them for _all_ processors. As it is, Fabrice's code generator will most likely be something similar to Paul's qops, which means that you have to invent a "primitive C" in which to write the miniops, and you will have to write a backend for _each_ and _every_ host CPU you support. Things clearer now? Hth, Dscho
Re: [Qemu-devel] [RESEND] [PATCH] Make use of temporaries as registers conditional (fixes gcc4 i386 host)
On Jan 21, 2008, at 9:19 AM, Mulyadi Santosa wrote: On 1/21/08, Alexander Graf <[EMAIL PROTECTED]> wrote: Hi.. Alexander Graf wrote: Oops, wrong version :-) Here we go again... Bummer! Almost applied that...:) Sure it's the right one? :D Pretty sure, yes ;-). It still doesn't fix x86_64 target for me though. Nevertheless it's a step in the right direction as far as I'm concerned. Regards, Alex
Re: [Qemu-devel] [RESEND] [PATCH] Make use of temporaries as registers conditional (fixes gcc4 i386 host)
On 1/21/08, Alexander Graf <[EMAIL PROTECTED]> wrote: Hi.. > Alexander Graf wrote: > Oops, wrong version :-) > > Here we go again... Bummer! Almost applied that...:) Sure it's the right one? :D regards, Mulyadi
