Re: [Qemu-devel] compile error ( translate-op.c:36 -op.h:In function `dyng..)
Sim wrote: > Here my last test for build QEmu :-( > > > ./configure --disable-gfx-check --target-list=i386-user --disable-sdl > --disable-audio > > g -fno-strict-aliasing -fomit-frame-pointer > -mpreferred-stack-boundary=2 -falign-functions=0 -fno-gcse > -fno-reorder-blocks -fno-optimize-sibling-calls -I. -I.. > -I/usr/local/src/qemu-0.8.1/target-i386 -I/usr/local/src/qemu-0.8.1 > -I/usr/local/src/qemu-0.8.1/linux-user > [...] You're still not using the most up-to-date version (from CVS*). Additionally more information on your host system would be helpful. With regards, Jan *) http://savannah.nongnu.org/cvs/?group=qemu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] compile error ( translate-op.c:36 -op.h:In function `dyng..)
You're still not using the most up-to-date version (from CVS*). Additionally more information on your host system would be helpful. Hi Jan ! Thanks for your reply and CVS address. Here my configure and make per CVS version. -- # ./configure --disable-gfx-check --disable-sdl --disable-audio --target-list=i386-softmmu which: no texi2html in (/sbin:/usr/sbin:/usr/ucb:/bin:/usr/bin:/etc:/usr/local/bin:/opt/xsentry/sbin:/root/bin) Install prefix/usr/local BIOS directory/usr/local/share/qemu binary directory /usr/local/bin Manual directory /usr/local/share/man ELF interp prefix /usr/gnemul/qemu-%M Source path /usr/local/src/qemu C compilergcc Host C compiler gcc make make install install host CPU i386 host big endian no target list i386-softmmu gprof enabled no profiler no static build no SDL support no mingw32 support no Adlib support no CoreAudio support no ALSA support no DSound supportno FMOD support no kqemu support yes Documentation no -- # make gcc -DQEMU_TOOL -Wall -O2 -g -fno-strict-aliasing -I. -g -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o qemu-img qemu-img.c block.c block-cow.c block-qcow.c aes.c block-vmdk.c block-cloop.c block-dmg.c block-bochs.c block-vpc.c block-vvfat.c -lz gcc -Wall -O2 -g -fno-strict-aliasing -I. -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o dyngen dyngen.c make -C i386-softmmu all make[1]: Entering directory `/usr/local/src/qemu/i386-softmmu' gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. -I.. -I/usr/local/src/qemu/target-i386 -I/usr/local/src/qemu -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/usr/local/src/qemu/fpu -DHAS_AUDIO -I/usr/local/src/qemu/slirp -c -o vl.o /usr/local/src/qemu/vl.c /usr/local/src/qemu/vl.c: In function `init_get_clock': /usr/local/src/qemu/vl.c:547: error: `CLOCK_MONOTONIC' undeclared (first use in this function) /usr/local/src/qemu/vl.c:547: error: (Each undeclared identifier is reported only once /usr/local/src/qemu/vl.c:547: error: for each function it appears in.) /usr/local/src/qemu/vl.c: In function `get_clock': /usr/local/src/qemu/vl.c:559: error: `CLOCK_MONOTONIC' undeclared (first use in this function) make[1]: *** [vl.o] Error 1 make[1]: Leaving directory `/usr/local/src/qemu/i386-softmmu' make: *** [subdir-i386-softmmu] Error 2 [EMAIL PROTECTED] /usr/local/src/qemu# vi /usr/local/src/qemu/vl.c Now the error is different! -- My host is a Trustix Linux version 2.2 ( http://www.trustix.org ) The packages installed are: # rpm -qa | grep gcc gcc-cpp-3.3.4-3tr gcc-c++-devel-3.3.4-3tr gcc-runtime-3.3.4-3tr gcc-3.3.4-3tr gcc-c++-runtime-3.3.4-3tr # uname -a Linux test 2.4.32-1tr #1 Wed Feb 8 12:58:36 GMT 2006 i686 i686 i386 GNU/Linux For my test I'm using VmWare and HP DL380: Performance - Xeon 3.4 GHz Fattore di forma Montabile in rack - 2 U Dimensioni (LxPxH) 44.5 cm x 66.1 cm x 8.6 cm Processore 2 x Intel Xeon 3.4 GHz RAM 2 GB (installati) / 12 GB (max) - DDR II SDRAM - ECC - 400 MHz - PC2-3200 Storage controller RAID ( Ultra320 SCSI ) ( Smart Array 6i Controller ) Controller grafico ATI RAGE XL - 8 MB Networking Scheda di rete - PCI-X - Ethernet, Fast Ethernet, Gigabit Ethernet Cache per processore 1 MB If you need more info don't esitate to contact me. Thanks! ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] compile error ( translate-op.c:36 -op.h:In function `dyng..)
Hi! And this whit ./configure --disable-gfx-check --disable-sdl --disable-audio --target-list=i386-user ../dyngen -o op.h op.o ../dyngen -c -o opc.h op.o gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. -I.. -I/usr/local/src/qemu/target-i386 -I/usr/local/src/qemu -I/usr/local/src/qemu/linux-user -I/usr/local/src/qemu/linux-user/i386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/usr/local/src/qemu/fpu -DHAS_AUDIO -I/usr/local/src/qemu/slirp -c -o translate-op.o /usr/local/src/qemu/translate-op.c In file included from /usr/local/src/qemu/translate-op.c:36: op.h: In function `dyngen_code': op.h:5704: error: parse error before ')' token op.h:5781: error: parse error before ')' token op.h:5812: error: parse error before ')' token op.h:5831: error: parse error before ')' token op.h:5862: error: parse error before ')' token op.h:5881: error: parse error before ')' token op.h:6513: error: parse error before ')' token op.h:6535: error: parse error before ')' token op.h:6556: error: parse error before ')' token op.h:6577: error: parse error before ')' token op.h:6601: error: parse error before ')' token op.h:7378: error: parse error before ')' token op.h:7396: error: parse error before ')' token op.h:7413: error: parse error before ')' token op.h:7431: error: parse error before ')' token op.h:7980: error: parse error before ')' token op.h:7999: error: parse error before ')' token op.h:8018: error: parse error before ')' token op.h:8037: error: parse error before ')' token op.h:8056: error: parse error before ')' token op.h:8075: error: parse error before ')' token op.h:8095: error: parse error before ')' token op.h:8114: error: parse error before ')' token op.h:8133: error: parse error before ')' token op.h:8152: error: parse error before ')' token op.h:8172: error: parse error before ')' token make[1]: *** [translate-op.o] Error 1 make[1]: Leaving directory `/usr/local/src/qemu/i386-user' make: *** [subdir-i386-user] Error 2 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] QEMU GUI-Frontend based on Libvert API
Hi All, I know there's been several thread discussions regarding GUI-Frontend for QEMU and there already exist some projects that offers GUI for QEMU. But, recently, I've come to learn about an open source project called libvert which is actively being developed at http://www.libvirt.org. Below is a short description and the goal for this project: *(Note: The content below was taken from the following link: http://www.devx.com/amd/Article/31817/1763) libVirt, an open source project stewarded and driven by Red Hat, with contributions from Red Hat, IBM, Novell, Bull, VMware, and others. The libVirt project is a community-sponsored project that aims to bring more simplicity and standards to the Linux VM world. At its core, libVirt is a C toolkit that provides interaction with virtualization capabilities of the Linux operating system (and those related to Linux). The goal of libVirt is to provide the lowest possible generic and stable layer to manage VMs running on a machine. To accomplish this goal, libVirt will not try to be all things related to virtualization—instead libVirt will provide consistent and stable APIs to enable other tools to be built and used on top of the libVirt layer. Although the premise for libVirt seems pretty simple, the project has turned out some very mature features and tools, including: * Local administration tools—including a shell (virsh), a GNOME application, and a GNOME monitoring applet. * Plenty of control interfaces—shell scripting, Python and Perl bindings, and robust APIs. * Monitoring interfaces—feeding stats and states to applications, daemons, and the API hooks for other applications to utilize * A robust policy framework—enabling complex policies to monitor, control, and correct domains running on the node. * An XML structure for defining domains—portable, easily parsed, and human readable. A big advantage of libVirt's vendor-neutral stance is that you can define a framework for your VMs, applications, and policies that will run with most of the popular VMMs (XEN or QEMU). Code once—a somewhat unique aspect in the development space. Currently, there is a project called Virt-Manager that is building a GUI-Frontend using the LibVirt API. More info on the Virt-Manager project can be found here: http://people.redhat.com/berrange/virt-manager/ For me, I personally like the idea and focus of libVirt project and would like to see if any QEMU developers from the list would have an interest to team up with me to develop an open source GUI-Frontend based on the LibVirt API. I must admit here, that I do have a personal interest and motivation for developing such a project - The reasons are: I am planning to launch (soon) an open source community web site called OpenSourceDemo.com (OSD)... The site will make available DEMO's for some of the most popular Free Open Source Software applications. The site will make available 2 types of demo's. One type of demo will be online web based demos. The other will come in the form of a "Software Appliance" which is a pre-built and pre-configured software that is packaged in a single image file that can be downloaded and run on users local PC using a product like VMware Player or QEMU. Initially, before learning much about QEMU, I had plans to offer VMware Player to users on the site to run and demo the appliances. However, since the site promotes open source, I would prefer to offer an open source alternative to VMware Player and think QEMU is the best option. However, I need to have a GUI product that would make it easy for users to adopt and use - especially those that are already use to VMware product. It is this idea that has motivated me to start a GUI project that supports QEMU. And, I would like to leverage the LibVirt project for this. I invite and welcome developers from the list who would have interest to contribute in the development of a QEMU GUI based on the libVirt API. Evan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: QEMU GUI-Frontend based on Libvert API
On Fri, 21 Jul 2006 14:37:10 -0400, Evan Paul wrote: > > The libVirt project is a community-sponsored project that aims to bring > more simplicity and standards to the Linux VM world. At its core, > libVirt is a C toolkit that provides interaction with virtualization > capabilities of the Linux operating system (and those related to Linux). You make it sound so professional :-) > Currently, there is a project called Virt-Manager that is building a > GUI-Frontend using the LibVirt API. More info on the Virt-Manager > project can be found here: > http://people.redhat.com/berrange/virt-manager/ > > For me, I personally like the idea and focus of libVirt project and > would like to see if any QEMU developers from the list would have an > interest to team up with me to develop an open source GUI-Frontend based > on the LibVirt API. Why would you create a second GUI interface when virt-manager already exists as a libvirt GUI front-end? As far as I know, the big hurdle for QEMU and libvirt right now is not any GUI aspects (VNC would work just fine). It's interacting with QEMU. Xen provides an XML-RPC interface to managing instances whereas QEMU only really provides the monitor interface. Of course, there's still a bit of work to do before libvirt uses actually uses that interface (it currently uses the older S-Expression/HTTP interface). Basically, there's quite a bit of work to do in libvirt before you could even start writing a GUI for QEMU. I have toyed around with the idea of writing an XML-RPC front-end to QEMU (with the idea of bridging the gap for libvirt). DV also had a patch floating around to add a socket management interface to QEMU (although now there is a TCP character device so I presume his patch is unnecessary). My first cut at an XML-RPC front-end for QEMU: http://hg.codemonkey.ws/qemu-rpcd/ Regards, Anthony Liguori ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: QEMU GUI-Frontend based on Libvert API
Anthony Liguori wrote: On Fri, 21 Jul 2006 14:37:10 -0400, Evan Paul wrote: The libVirt project is a community-sponsored project that aims to bring more simplicity and standards to the Linux VM world. At its core, libVirt is a C toolkit that provides interaction with virtualization capabilities of the Linux operating system (and those related to Linux). You make it sound so professional :-) Currently, there is a project called Virt-Manager that is building a GUI-Frontend using the LibVirt API. More info on the Virt-Manager project can be found here: http://people.redhat.com/berrange/virt-manager/ For me, I personally like the idea and focus of libVirt project and would like to see if any QEMU developers from the list would have an interest to team up with me to develop an open source GUI-Frontend based on the LibVirt API. Why would you create a second GUI interface when virt-manager already exists as a libvirt GUI front-end? As far as I know, the big hurdle for QEMU and libvirt right now is not any GUI aspects (VNC would work just fine). It's interacting with QEMU. Xen provides an XML-RPC interface to managing instances whereas QEMU only really provides the monitor interface. Of course, there's still a bit of work to do before libvirt uses actually uses that interface (it currently uses the older S-Expression/HTTP interface). Basically, there's quite a bit of work to do in libvirt before you could even start writing a GUI for QEMU. I have toyed around with the idea of writing an XML-RPC front-end to QEMU (with the idea of bridging the gap for libvirt). DV also had a patch floating around to add a socket management interface to QEMU (although now there is a TCP character device so I presume his patch is unnecessary). My first cut at an XML-RPC front-end for QEMU: http://hg.codemonkey.ws/qemu-rpcd/ Regards, Anthony Liguori ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel Why would you create a second GUI interface when virt-manager already exists as a libvirt GUI front-end? Well, first let me say I am not a programmer and know very little about GUI development and their toolkits. But, I have been reading up and learning about what's out there. Having said that, I think "Virt-Manager" is built using GTK/Glade with Python and I am not quite sure if that would meet the requirements to having a cross-platform GUI for users. And, something that would offer a native look & feel to the OS platform they use. As mentioned in my previous email, for OpenSourceDemo.com, I'd like to make available a VM software product with a GUI that can be used by users using windows, linux, and mac-os. Therefore, I don't know if GTK/Glade is the best choice for this. If it is, using virt-manager would be great! Basically, there's quite a bit of work to do in libvirt before you could even start writing a GUI for QEMU. Hmm, really didn't know how much work would be involved. But, I think it would be good to start, if people like the idea of having a QEMU support for libVirt. I just think it would great to harrness and leverage the work behind libVirt and have support for QEMU. The GUI part would be easy to add on. Also, if it would take a long time to have support for QEMU using libvirt, I was wondering if anyone can help me come up with an interim solution to have a gui that I can make available on the site. Would greatly appreciate the help with this. Ideally, I am looking for a solution where the GUI can package QEMU with it. So, as a user installs the GUI on there PC it also installs QEMU in one install. This would remove the complexity of having to install QEMU and then the GUI. This is how I see most of the available GUI that exist work. Evan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: Re: QEMU GUI-Frontend based on Libvert API
On Fri, 21 Jul 2006 15:58:41 -0400, Joe Lee wrote: > Well, first let me say I am not a programmer and know very little about > GUI development and their toolkits. But, I have been reading up and > learning about what's out there. Having said that, I think "Virt-Manager" > is built using GTK/Glade with Python and I am not quite sure if that would > meet the requirements to having a cross-platform GUI for users. And, > something that would offer a native look & feel to the OS platform they > use. I don't wish to start a flame war, but the idea of a "cross-platform GUI" is somewhat of a myth. If nothing else, VMware and Parallels are both examples of having multiple interfaces optimized for all the platforms they support. > As mentioned in my previous email, for OpenSourceDemo.com, I'd like to > make available a VM software product with a GUI that can be used by users > using windows, linux, and mac-os. Therefore, I don't know if GTK/Glade is > the best choice for this. If it is, using virt-manager would be great! See above. >> Basically, there's quite a bit of work to do in libvirt before you could >> even start writing a GUI for QEMU. > Hmm, really didn't know how much work would be involved. But, I think it > would be good to start, if people like the idea of having a QEMU support > for libVirt. I just think it would great to harrness and leverage the work > behind libVirt and have support for QEMU. The GUI part would be easy to > add on. Supporting QEMU in libvirt has been on the libvirt TODO list for a while. There is quite a lot on the list though. Feel free to send patches to libvirt-devel though :-) > Also, if it would take a long time to have support for QEMU using libvirt, > I was wondering if anyone can help me come up with an interim solution to > have a gui that I can make available on the site. Would greatly appreciate > the help with this. Ideally, I am looking for a solution where the GUI can > package QEMU with it. So, as a user installs the GUI on there PC it also > installs QEMU in one install. This would remove the complexity of having > to install QEMU and then the GUI. This is how I see most of the available > GUI that exist work. I posted some patches earlier to implement some of the basic support for having a GUI bundled with QEMU. Hopefully that's the first step. Regards, Anthony Liguori > Evan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: Re: QEMU GUI-Frontend based on Libvert API
Anthony Liguori wrote: > I posted some patches earlier to implement some of the basic support for > having a GUI bundled with QEMU. Hopefully that's the first step. As a developer of an old-style GUI front-end [1] to QEMU, I am very interested in this. Where can I find more information on this? Duplicate work is the least I want to do. [1] https://gna.org/projects/qemulaunch/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: Re: Re: QEMU GUI-Frontend based on Libvert API
On Sat, 22 Jul 2006 00:15:21 +0300, Linas Žvirblis wrote: > Anthony Liguori wrote: > >> I posted some patches earlier to implement some of the basic support for >> having a GUI bundled with QEMU. Hopefully that's the first step. > > As a developer of an old-style GUI front-end [1] to QEMU, I am very > interested in this. Where can I find more information on this? Duplicate > work is the least I want to do. > > [1] https://gna.org/projects/qemulaunch/ Look at the archives from the 16th. Fabrice hasn't said yet whether he likes this approach. He also hasn't said he dislikes it though :-) Regards, Anthony Liguori ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: Re: Re: QEMU GUI-Frontend based on Libvert API
Anthony Liguori wrote: > Look at the archives from the 16th. Fabrice hasn't said yet whether he > likes this approach. He also hasn't said he dislikes it though :-) I looked trough the GUI part of the patch and this seems to be what I have always missed in QEMU. Great, really. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-arm helper.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 06/07/21 22:39:58 Modified files: target-arm : helper.c Log message: Fix Arm cp15 c13 (Process ID) register writes. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/helper.c?cvsroot=qemu&r1=1.5&r2=1.6 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Add special MIPS multiply instructions
This is an update of MIPS NEC VR5400 special instruction
patch [1]. It is necessary because of MIPS instruction set
configuration patch. Therefore this patch has to be applied
on top of
http://lists.gnu.org/archive/html/qemu-devel/2006-07/msg00158.html
Best regards
Dirk
[1]
http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00375.html
--- ./target-mips/op_helper.c_orig 2006-07-22 07:32:51.0 +0200
+++ ./target-mips/op_helper.c 2006-07-22 08:01:16.0 +0200
@@ -128,6 +128,134 @@ void do_msubu (void)
tmp = ((uint64_t)T0 * (uint64_t)T1);
set_HILO(get_HILO() - tmp);
}
+
+#ifdef MIPS_USES_NEC_VR5400
+void do_muls (void)
+{
+int64_t tmp;
+
+tmp = 0 - ((int64_t)(int32_t)T0 * (int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+}
+
+void do_mulsu (void)
+{
+uint64_t tmp;
+
+tmp = 0 - ((uint64_t)(uint32_t)T0 * (uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+}
+
+void do_macc (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) + ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+}
+
+void do_macchi (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) + ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+
+void do_maccu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) + ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+}
+
+void do_macchiu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) + ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+
+void do_msac (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) - ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+}
+
+void do_msachi (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) - ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+
+void do_msacu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) - ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+}
+
+void do_msachiu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) - ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+
+void do_mulhi (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)(int32_t)T0 * (int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+
+void do_mulhiu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)(uint32_t)T0 * (uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+
+void do_mulshi (void)
+{
+int64_t tmp;
+
+tmp = 0 - ((int64_t)(int32_t)T0 * (int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+
+void do_mulshiu (void)
+{
+uint64_t tmp;
+
+tmp = 0 - ((uint64_t)(uint32_t)T0 * (uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+}
+#endif /* MIPS_USES_NEC_VR5400 */
#endif
#if defined(CONFIG_USER_ONLY)
@@ -159,6 +287,149 @@ void do_tlbr (void)
{
cpu_abort(env, "tlbr\n");
}
+
+#ifdef MIPS_USES_NEC_VR5400
+void op_muls (void)
+{
+int64_t tmp;
+
+tmp = 0 - ((int64_t)(int32_t)T0 * (int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+RETURN();
+}
+
+void op_mulsu (void)
+{
+uint64_t tmp;
+
+tmp = 0 - ((uint64_t)(uint32_t)T0 * (uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+RETURN();
+}
+
+void op_macc (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) + ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+RETURN();
+}
+
+void op_macchi (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) + ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+RETURN();
+}
+
+void op_maccu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) + ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+RETURN();
+}
+
+void op_macchiu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) + ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+RETURN();
+}
+
+void op_msac (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) - ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+RETURN();
+}
+
+void op_msachi (void)
+{
+int64_t tmp;
+
+tmp = ((int64_t)get_HILO()) - ((int64_t)(int32_t)T0 *
(int64_t)(int32_t)T1);
+set_HILO(tmp);
+T0 = tmp >> 32;
+RETURN();
+}
+
+void op_msacu (void)
+{
+uint64_t tmp;
+
+tmp = ((uint64_t)get_HILO()) - ((uint64_t)(uint32_t)T0 *
(uint64_t)(uint32_t)T1);
+set_HILO(tmp);
+T0 = tmp & 0x;
+RETURN();
+}
+
+void op_msachiu (void)
+{
+uint64_t tmp;
+
+
Re: [Qemu-devel] QuickStartGuide on QEMU Wiki
Fabrice Bellard wrote: Thank you for the advices. I modified the web site: tell me if you see other problems. Great! Many thanks! I'm not sure, but I think I can remember that in the download area there was a link to the QEMU daily snapshots (I think called "mirror"?) at http://qemu.dad-answers.com/download/qemu/ Do I overlooked anyhting or is it gone? Yes, I know, under "Links" there is a link to qemu.dad-answers.com, but there I wasn't able to find a link to the download area with the snapshots as well. Only my bookmark list helped me here ;) Best regards Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Updated QEMU binary with fixed invisible wall?
Hi, sorry if this is a FAQ, but while playing with installing Win under Linux (you know, the quick start guide) I found that I have the "invisible wall" mouse problem as well. I used the binary qemu-0.8.1-i386.tar.gz from QEMU's download area. Recent CVS seems to contain [1] already. Is there anywhere an updated binary version available? Regards Dirk [1] http://lists.gnu.org/archive/html/qemu-devel/2006-05/msg00112.html ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
