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
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
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
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
>
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
> > possibil
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.
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
> > > 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
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 mo
> 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 "jm
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=qem
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:
> 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 impleme
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:
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 c
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
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 t
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 w
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 o
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] part
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]>
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 wel
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:
h
>
> 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 networ
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:
> > > .
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
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 thi
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 s
28 matches
Mail list logo
