[Qemu-devel] Splitting vl.h
The attached patch starts splitting vl.h up a bit.
I've pulled out the i2c, disk and irq code.
Because I picked some of the easier ones, they can also be built once, rather
than for every target.
Obviously there's a lot left to do, but my grand plan is to get rid of vl.h
altogether. A few files will probably end up effectively including
everything, but hopefully most files should disentangle reasonably well. The
more gets split out, the better things should get. e.g. scsi-disk.c doesn't
need vl.h because I already split out the block API.
I want to check this seems a reasonable approach before I go too much further.
Comments?
Paul
Index: Makefile
===
RCS file: /sources/qemu/qemu/Makefile,v
retrieving revision 1.130
diff -u -p -r1.130 Makefile
--- Makefile 11 Nov 2007 02:51:15 - 1.130
+++ Makefile 11 Nov 2007 04:18:14 -
@@ -1,5 +1,7 @@
# Makefile for QEMU.
+VPATH=$(SRC_PATH):$(SRC_PATH)/hw
+
include config-host.mak
.PHONY: all clean distclean dvi info install install-doc tar tarbin \
@@ -50,6 +52,10 @@ OBJS=$(BLOCK_OBJS)
OBJS+=readline.o console.o
OBJS+=block.o
+OBJS+=irq.o
+OBJS+=i2c.o smbus.o smbus_eeprom.o max7310.o max111x.o wm8750.o
+OBJS+=scsi-disk.o cdrom.o
+
ifdef CONFIG_WIN32
OBJS+=tap-win32.o
endif
Index: Makefile.target
===
RCS file: /sources/qemu/qemu/Makefile.target,v
retrieving revision 1.222
diff -u -p -r1.222 Makefile.target
--- Makefile.target 11 Nov 2007 02:51:15 - 1.222
+++ Makefile.target 11 Nov 2007 04:18:14 -
@@ -399,7 +399,6 @@ endif
VL_OBJS=vl.o osdep.o monitor.o pci.o loader.o isa_mmio.o
# XXX: suppress QEMU_TOOL tests
VL_OBJS+=block-raw.o
-VL_OBJS+=irq.o
ifdef CONFIG_ALSA
LIBS += -lasound
@@ -421,10 +420,8 @@ CPPFLAGS += $(CONFIG_VNC_TLS_CFLAGS)
LIBS += $(CONFIG_VNC_TLS_LIBS)
endif
-VL_OBJS += i2c.o smbus.o
-
# SCSI layer
-VL_OBJS+= scsi-disk.o cdrom.o lsi53c895a.o
+VL_OBJS+= lsi53c895a.o
# USB layer
VL_OBJS+= usb.o usb-hub.o usb-linux.o usb-hid.o usb-ohci.o usb-msd.o
@@ -444,7 +441,7 @@ ifeq ($(TARGET_BASE_ARCH), i386)
VL_OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o
VL_OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o
VL_OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o
-VL_OBJS+= usb-uhci.o smbus_eeprom.o vmmouse.o vmport.o vmware_vga.o
+VL_OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o
CPPFLAGS += -DHAS_AUDIO -DHAS_AUDIO_CHOICE
endif
ifeq ($(TARGET_BASE_ARCH), ppc)
@@ -468,7 +465,7 @@ VL_OBJS+= mips_r4k.o mips_malta.o mips_p
VL_OBJS+= mips_timer.o mips_int.o dma.o vga.o serial.o i8254.o i8259.o
VL_OBJS+= jazz_led.o
VL_OBJS+= ide.o gt64xxx.o pckbd.o ps2.o fdc.o mc146818rtc.o usb-uhci.o acpi.o ds1225y.o
-VL_OBJS+= piix_pci.o smbus_eeprom.o parallel.o cirrus_vga.o $(SOUND_HW)
+VL_OBJS+= piix_pci.o parallel.o cirrus_vga.o $(SOUND_HW)
VL_OBJS+= mipsnet.o
CPPFLAGS += -DHAS_AUDIO
endif
@@ -498,8 +495,8 @@ VL_OBJS+= armv7m.o armv7m_nvic.o stellar
VL_OBJS+= ssd0323.o pl061.o
VL_OBJS+= arm-semi.o
VL_OBJS+= pxa2xx.o pxa2xx_pic.o pxa2xx_gpio.o pxa2xx_timer.o pxa2xx_dma.o
-VL_OBJS+= pxa2xx_lcd.o pxa2xx_mmci.o pxa2xx_pcmcia.o max111x.o max7310.o
-VL_OBJS+= spitz.o ads7846.o ide.o serial.o nand.o ecc.o wm8750.o
+VL_OBJS+= pxa2xx_lcd.o pxa2xx_mmci.o pxa2xx_pcmcia.o
+VL_OBJS+= spitz.o ads7846.o ide.o serial.o nand.o ecc.o
VL_OBJS+= omap.o omap_lcdc.o omap1_clk.o omap_mmc.o omap_i2c.o
VL_OBJS+= palm.o tsc210x.o
CPPFLAGS += -DHAS_AUDIO
Index: exec.c
===
RCS file: /sources/qemu/qemu/exec.c,v
retrieving revision 1.113
diff -u -p -r1.113 exec.c
--- exec.c 10 Nov 2007 15:15:50 - 1.113
+++ exec.c 11 Nov 2007 04:18:15 -
@@ -1278,11 +1278,9 @@ int cpu_str_to_log_mask(const char *str)
return mask;
}
-void cpu_abort(CPUState *env, const char *fmt, ...)
+static void __attribute__((noreturn))
+cpu_abortv(CPUState *env, const char *fmt, va_list ap)
{
-va_list ap;
-
-va_start(ap, fmt);
fprintf(stderr, "qemu: fatal: ");
vfprintf(stderr, fmt, ap);
fprintf(stderr, "\n");
@@ -1308,10 +1306,27 @@ void cpu_abort(CPUState *env, const char
fflush(logfile);
fclose(logfile);
}
-va_end(ap);
abort();
}
+void cpu_abort(CPUState *env, const char *fmt, ...)
+{
+va_list ap;
+
+va_start(ap, fmt);
+cpu_abortv(env, fmt, ap);
+va_end(ap);
+}
+
+void qemu_abort(CPUState *env, const char *fmt, ...)
+{
+va_list ap;
+
+va_start(ap, fmt);
+cpu_abortv(env, fmt, ap);
+va_end(ap);
+}
+
CPUState *cpu_copy(CPUState *env)
{
#if 0
Index: qemu-common.h
===
RCS file: /sources/qemu/qemu/qemu-common.h,v
retrieving revision 1.1
diff -u -p -r1.1 qemu-common.h
--- qemu-common.h 11 Nov 2007 02:51:16 - 1.1
+++ qemu-common.h 11 Nov 2007 04:18:15 -
@@ -80,4 +80,10 @@ int strstart(co
[Qemu-devel] qemu qemu-img.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/11/11 03:33:14 Modified files: . : qemu-img.c Log message: Cleanup qemu-img.c. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-img.c?cvsroot=qemu&r1=1.24&r2=1.25
[Qemu-devel] qemu Makefile Makefile.target aes.c block-bochs...
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/11/11 02:51:17 Modified files: . : Makefile Makefile.target aes.c block-bochs.c block-cloop.c block-cow.c block-dmg.c block-parallels.c block-qcow.c block-qcow2.c block-raw.c block-vmdk.c block-vpc.c block-vvfat.c block.c block_int.h cutils.c qemu-img.c vl.h Added files: . : block.h qemu-common.h Log message: Split block API from vl.h. Remove QEMU_TOOL. Replace with QEMU_IMG and NEED_CPU_H. Avoid linking qemu-img against whole system emulatior. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemu&r1=1.129&r2=1.130 http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.221&r2=1.222 http://cvs.savannah.gnu.org/viewcvs/qemu/aes.c?cvsroot=qemu&r1=1.3&r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/block-bochs.c?cvsroot=qemu&r1=1.5&r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/block-cloop.c?cvsroot=qemu&r1=1.6&r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/block-cow.c?cvsroot=qemu&r1=1.9&r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/block-dmg.c?cvsroot=qemu&r1=1.7&r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/block-parallels.c?cvsroot=qemu&r1=1.1&r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/block-qcow.c?cvsroot=qemu&r1=1.14&r2=1.15 http://cvs.savannah.gnu.org/viewcvs/qemu/block-qcow2.c?cvsroot=qemu&r1=1.9&r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/block-raw.c?cvsroot=qemu&r1=1.25&r2=1.26 http://cvs.savannah.gnu.org/viewcvs/qemu/block-vmdk.c?cvsroot=qemu&r1=1.17&r2=1.18 http://cvs.savannah.gnu.org/viewcvs/qemu/block-vpc.c?cvsroot=qemu&r1=1.6&r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/block-vvfat.c?cvsroot=qemu&r1=1.11&r2=1.12 http://cvs.savannah.gnu.org/viewcvs/qemu/block.c?cvsroot=qemu&r1=1.46&r2=1.47 http://cvs.savannah.gnu.org/viewcvs/qemu/block_int.h?cvsroot=qemu&r1=1.13&r2=1.14 http://cvs.savannah.gnu.org/viewcvs/qemu/cutils.c?cvsroot=qemu&r1=1.3&r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-img.c?cvsroot=qemu&r1=1.23&r2=1.24 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.293&r2=1.294 http://cvs.savannah.gnu.org/viewcvs/qemu/block.h?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-common.h?cvsroot=qemu&rev=1.1
Re: [Qemu-devel] QEMU - macaddr= does not work - HELP
Sorry, I found the problem, I was appending the "macaddr=" parameter to the "-net tap" options instead of the "-net nic" options as documented :( e.g. qemu -boot c -hda /hd1 -m 1024 -localtime -net nic -net tap,macaddr1=52:54:00:12:34:01 instead of qemu -boot c -hda /hd1 -m 1024 -localtime -net nic,macaddr1=52:54:00:12:34:01 -net tap Thanks. Albert. Albert Graham wrote: I'm trying to get the macaddr= parameter to work (with -net tap), but it does not seem to pass the specified MAC address to the underlying virtual NIC (in my case ne2000 pci using) This would not normally be required for a single instance if QEMU, but I want multiple instances per server as well as across multiple machines. Ths MAC is what the DHCP server keys off and I want to control the IP address of the guests via DHCP. I'm using Fedora Core 6 as a HOST and Fedora 8 as guests. The guest ifcfg-eth0 looks like this: DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes Note, the HWADDR= parameter is removed. I've tested this with 0.8.2 (latest version for Fedora 6) x86 I also compiled the 0.9.0 source and that had the same results - i.e. it did not work. The problem is that whatever MAC address is used via the macaddr= parameter, it is ignore and using "info network" via the QEMU monitor (CTRL+ALT+2) shows the original hard coded "52:54:00:12:34:56" instead of the one that I specified. You should note that I am only using a single virtual NIC per guest, and I imagine that using multiple NICs in a guest DOES allow you to set the MAC address, but I have not tested this. I'm pretty sure this is a BUG in the code. How can I solve this problem ? Thanks in Advance. Albert. ps. Also, the latest kernel-kqemu panics Fedora 8 - just after compressing kernel.. (and as such I do not use kqemu).
[Qemu-devel] qemu vl.c hw/pc.c hw/ppc_chrp.c hw/ppc_oldworld...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/11/11 01:50:45 Modified files: . : vl.c hw : pc.c ppc_chrp.c ppc_oldworld.c ppc_prep.c Log message: More generic boot devices specification, allowing more devices to be specified and avoiding per-target hardcoded limitations. The machine implementations can then check if the given devices match the actual hardware implementation and firmware API. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.358&r2=1.359 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pc.c?cvsroot=qemu&r1=1.91&r2=1.92 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_chrp.c?cvsroot=qemu&r1=1.49&r2=1.50 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_oldworld.c?cvsroot=qemu&r1=1.5&r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_prep.c?cvsroot=qemu&r1=1.52&r2=1.53
[Qemu-devel] QEMU - macaddr= does not work - HELP
I'm trying to get the macaddr= parameter to work (with -net tap), but it does not seem to pass the specified MAC address to the underlying virtual NIC (in my case ne2000 pci using) This would not normally be required for a single instance if QEMU, but I want multiple instances per server as well as across multiple machines. Ths MAC is what the DHCP server keys off and I want to control the IP address of the guests via DHCP. I'm using Fedora Core 6 as a HOST and Fedora 8 as guests. The guest ifcfg-eth0 looks like this: DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes Note, the HWADDR= parameter is removed. I've tested this with 0.8.2 (latest version for Fedora 6) x86 I also compiled the 0.9.0 source and that had the same results - i.e. it did not work. The problem is that whatever MAC address is used via the macaddr= parameter, it is ignore and using "info network" via the QEMU monitor (CTRL+ALT+2) shows the original hard coded "52:54:00:12:34:56" instead of the one that I specified. You should note that I am only using a single virtual NIC per guest, and I imagine that using multiple NICs in a guest DOES allow you to set the MAC address, but I have not tested this. I'm pretty sure this is a BUG in the code. How can I solve this problem ? Thanks in Advance. Albert. ps. Also, the latest kernel-kqemu panics Fedora 8 - just after compressing kernel.. (and as such I do not use kqemu).
[Qemu-devel] qemu Makefile.target
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/11/11 01:18:28 Modified files: . : Makefile.target Log message: Remove duplicate i2c.o. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.220&r2=1.221
[Qemu-devel] s390 host support
Hi folks
Thimo Seufer asked me to check if the s390 host supports works at all.
It did not even build, dyngen failed. I digged into the problem and
found the following:
gcc for s390 generates a data table after each function if necessary
instead of immediate loads. (g5, the oldest supported processor only
suports one halfword immediate load.) dyngen is not prepared for that
and fails. I found that gcc moves this data into the .rodata section if
generating code for z900 and above, which looked like a possible way to
support this.
The attached patch makes qemu build on a s390 host and able to run i386
kernels and userspace. powerpc did not boot, mips failed to start new
processes, the process reports illegal instruction, but the qemu log
does not reflect this.
It does the following changes:
- Hardcode -march=z900 to generate usable op code.
- Add redirection for parameter expansion in op code.
- Cleanup GOTO_LABEL_PARAM.
- Accept any return from function (like "br %r5").
- Support R_390_PC32DBL relocation, including relocations into sections.
- Disable special GOTO_TB handler, it segfaults.
Bastian
--
Each kiss is as the first.
-- Miramanee, Kirk's wife, "The Paradise Syndrome",
stardate 4842.6
? diff
? host-op.h
? img
? trace
Index: check_ops.sh
===
RCS file: /sources/qemu/qemu/check_ops.sh,v
retrieving revision 1.1
diff -u -r1.1 check_ops.sh
--- check_ops.sh7 Jan 2007 19:38:08 - 1.1
+++ check_ops.sh10 Nov 2007 20:23:52 -
@@ -35,6 +35,9 @@
mips*)
ret='\tjr.*ra'
;;
+ s390*)
+ret='\tbr.*'
+;;
*)
echo "Unknown machine `uname -m`"
;;
Index: configure
===
RCS file: /sources/qemu/qemu/configure,v
retrieving revision 1.169
diff -u -r1.169 configure
--- configure 8 Nov 2007 18:05:36 - 1.169
+++ configure 10 Nov 2007 20:23:53 -
@@ -341,6 +341,9 @@
ARCH_LDFLAGS="${SP_LDFLAGS}"
fi
;;
+s390)
+ ARCH_CFLAGS="-march=z900"
+ ;;
esac
if [ "$solaris" = "yes" -a "$cpu" = "x86_64" ] ; then
Index: dyngen-exec.h
===
RCS file: /sources/qemu/qemu/dyngen-exec.h,v
retrieving revision 1.38
diff -u -r1.38 dyngen-exec.h
--- dyngen-exec.h 16 Sep 2007 21:07:49 - 1.38
+++ dyngen-exec.h 10 Nov 2007 20:23:53 -
@@ -38,7 +38,7 @@
// Linux/Sparc64 defines uint64_t
#if !(defined (__sparc_v9__) && defined(__linux__))
/* XXX may be done for all 64 bits targets ? */
-#if defined (__x86_64__) || defined(__ia64)
+#if defined (__x86_64__) || defined(__ia64) || defined(__s390x__)
typedef unsigned long uint64_t;
#else
typedef unsigned long long uint64_t;
@@ -55,7 +55,7 @@
typedef signed int int32_t;
// Linux/Sparc64 defines int64_t
#if !(defined (__sparc_v9__) && defined(__linux__))
-#if defined (__x86_64__) || defined(__ia64)
+#if defined (__x86_64__) || defined(__ia64) || defined(__s390x__)
typedef signed long int64_t;
#else
typedef signed long long int64_t;
@@ -205,7 +205,7 @@
#define stringify(s) tostring(s)
#define tostring(s)#s
-#ifdef __alpha__
+#if defined(__alpha__) || defined(__s390__)
/* the symbols are considered non exported so a br immediate is generated */
#define __hidden __attribute__((visibility("hidden")))
#else
@@ -224,6 +224,13 @@
#define PARAM1 ({ int _r; asm("" : "=r"(_r) : "0" (&__op_param1)); _r; })
#define PARAM2 ({ int _r; asm("" : "=r"(_r) : "0" (&__op_param2)); _r; })
#define PARAM3 ({ int _r; asm("" : "=r"(_r) : "0" (&__op_param3)); _r; })
+#elif defined(__s390__)
+extern int __op_param1 __hidden;
+extern int __op_param2 __hidden;
+extern int __op_param3 __hidden;
+#define PARAM1 ({ int _r; asm("bras %0,8; .long " ASM_NAME(__op_param1) ";
larl %0,-4; l %0,0(%0)" : "=r"(_r) : ); _r; })
+#define PARAM2 ({ int _r; asm("bras %0,8; .long " ASM_NAME(__op_param2) ";
larl %0,-4; l %0,0(%0)" : "=r"(_r) : ); _r; })
+#define PARAM3 ({ int _r; asm("bras %0,8; .long " ASM_NAME(__op_param3) ";
larl %0,-4; l %0,0(%0)" : "=r"(_r) : ); _r; })
#else
#if defined(__APPLE__)
static int __op_param1, __op_param2, __op_param3;
@@ -254,7 +261,7 @@
#define GOTO_LABEL_PARAM(n) asm volatile ("b " ASM_NAME(__op_gen_label) #n)
#elif defined(__s390__)
#define EXIT_TB() asm volatile ("br %r14")
-#define GOTO_LABEL_PARAM(n) asm volatile ("bras %r7,8; .long "
ASM_NAME(__op_gen_label) #n "; l %r7, 0(%r7); br %r7")
+#define GOTO_LABEL_PARAM(n) asm volatile ("larl %r7,12; l %r7,0(%r7); br %r7;
.long " ASM_NAME(__op_gen_label) #n)
#elif defined(__alpha__)
#define EXIT_TB() asm volatile ("ret")
#elif defined(__ia64__)
Index: dyngen.c
===
RCS file: /sources/qemu/qemu/dyngen.c,v
retrieving revision 1.57
diff -u -r1.57 dyngen.c
--- dyngen.c7 Nov 2007 16:0
[Qemu-devel] qemu/target-ppc op.c op_helper.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/11/11 00:33:09 Modified files: target-ppc : op.c op_helper.c Log message: Fix POWER abs & abso computation. Fix PowerPC SPE evabs & evneg (thanks to Fabrice Bellard for reporting the bug) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemu&r1=1.63&r2=1.64 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.c?cvsroot=qemu&r1=1.64&r2=1.65
[Qemu-devel] qemu/target-ppc op.c op_helper.c op_helper.h tr...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/11/11 00:18:34 Modified files: target-ppc : op.c op_helper.c op_helper.h translate.c Log message: Optimize PowerPC overflow flag computation in most useful cases. Use the same routines to check overflow for addo, subfo and PowerPC 405 multiply and add cases. Fix carry reset in addme(o) and subfme(o) cases. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemu&r1=1.62&r2=1.63 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.c?cvsroot=qemu&r1=1.63&r2=1.64 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.h?cvsroot=qemu&r1=1.26&r2=1.27 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemu&r1=1.102&r2=1.103
[Qemu-devel] qemu Changelog
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/11/11 00:16:10 Modified files: . : Changelog Log message: Fix typo. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Changelog?cvsroot=qemu&r1=1.147&r2=1.148
[Qemu-devel] qemu Changelog Makefile.target cpu-exec.c qemu-...
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/11/11 00:04:50 Modified files: . : Changelog Makefile.target cpu-exec.c qemu-doc.texi vl.c vl.h fpu: softfloat-native.h softfloat.c softfloat.h hw : arm_boot.c arm_gic.c arm_sysctl.c integratorcp.c pl011.c pxa2xx.c realview.c versatilepb.c target-arm : cpu.h exec.h helper.c op.c op_helper.c op_mem.h translate.c Added files: hw : armv7m.c armv7m_nvic.c mpcore.c pl022.c pl061.c realview_gic.c ssd0303.c ssd0323.c stellaris.c target-arm : op_addsub.h op_neon.h Log message: ARMv7 support. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Changelog?cvsroot=qemu&r1=1.146&r2=1.147 http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.219&r2=1.220 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemu&r1=1.122&r2=1.123 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemu&r1=1.164&r2=1.165 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.357&r2=1.358 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.292&r2=1.293 http://cvs.savannah.gnu.org/viewcvs/qemu/fpu/softfloat-native.h?cvsroot=qemu&r1=1.11&r2=1.12 http://cvs.savannah.gnu.org/viewcvs/qemu/fpu/softfloat.c?cvsroot=qemu&r1=1.6&r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/fpu/softfloat.h?cvsroot=qemu&r1=1.8&r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/arm_boot.c?cvsroot=qemu&r1=1.9&r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/arm_gic.c?cvsroot=qemu&r1=1.7&r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/arm_sysctl.c?cvsroot=qemu&r1=1.4&r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/integratorcp.c?cvsroot=qemu&r1=1.23&r2=1.24 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl011.c?cvsroot=qemu&r1=1.8&r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx.c?cvsroot=qemu&r1=1.19&r2=1.20 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/realview.c?cvsroot=qemu&r1=1.13&r2=1.14 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/versatilepb.c?cvsroot=qemu&r1=1.19&r2=1.20 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/armv7m.c?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/armv7m_nvic.c?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mpcore.c?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl022.c?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl061.c?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/realview_gic.c?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ssd0303.c?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ssd0323.c?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/stellaris.c?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/cpu.h?cvsroot=qemu&r1=1.37&r2=1.38 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/exec.h?cvsroot=qemu&r1=1.14&r2=1.15 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/helper.c?cvsroot=qemu&r1=1.25&r2=1.26 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/op.c?cvsroot=qemu&r1=1.27&r2=1.28 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/op_helper.c?cvsroot=qemu&r1=1.8&r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/op_mem.h?cvsroot=qemu&r1=1.2&r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/translate.c?cvsroot=qemu&r1=1.57&r2=1.58 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/op_addsub.h?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/op_neon.h?cvsroot=qemu&rev=1.1
[Qemu-devel] qemu/target-ppc cpu.h translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer 07/11/10 23:51:03 Modified files: target-ppc : cpu.h translate_init.c Log message: Allow selection of PowerPC CPU giving a PVR. Remove unused pvr_mask field from CPU definition. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemu&r1=1.89&r2=1.90 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemu&r1=1.57&r2=1.58
Re: [Qemu-devel] [PATCH] Fix NaN handling in softfloat
On Sat, 2007-11-10 at 19:09 +0100, Aurelien Jarno wrote: > J. Mayer a écrit : > > On Sat, 2007-11-10 at 17:15 +0100, Aurelien Jarno wrote: > >> J. Mayer a écrit : > >>> On Sat, 2007-11-10 at 10:35 +0100, Aurelien Jarno wrote: > J. Mayer a écrit : > > On Thu, 2007-11-08 at 00:05 +0100, Aurelien Jarno wrote: > >> On Tue, Nov 06, 2007 at 09:01:13PM +0100, J. Mayer wrote: > >>> On Sat, 2007-11-03 at 22:28 +0100, Aurelien Jarno wrote: > On Sat, Nov 03, 2007 at 02:06:04PM -0400, Daniel Jacobowitz wrote: > > On Sat, Nov 03, 2007 at 06:35:48PM +0100, Aurelien Jarno wrote: > >> Hi all, > >> > >> The current softfloat implementation changes qNaN into sNaN when > >> converting between formats, for no reason. The attached patch fixes > >> that. It also fixes an off-by-one in the extended double precision > >> format (aka floatx80), the mantissa is 64-bit long and not 63-bit > >> long. > >> > >> With this patch applied all the glibc 2.7 floating point tests > >> are successfull on MIPS and MIPSEL. > >>> [...] > >> Anyway there is no way to do that in the target specific code *after > >> the conversion*, as the detection of a mantissa being nul when > >> converting from double to single precision can only be done when both > >> values are still known. In other words when the value is not fixed > >> during the conversion, the value 0x7f80 can either be infinity or a > >> conversion of NaN from double to single precision, and thus is it not > >> possible to fix the value afterwards in the target specific code. > > I don't say you have to return an infinity when the argument is a qNaN. > > I just say you have to return a qNaN in a generic way. Just return sign > > | 0x7f80 | mantissa, which is the more generic form and seems to me > > to even be OK for sNaNs. It's even needed for some target (not to say > 0x7f80 is actually not a NaN, but infinity. > > > PowerPC) that specify that the result have to be equal to the operand > > (in the single precision format, of course) in such a case. This is > > simpler, it ensures that any target could then detect the presence of a > > NaN, know which one, and can then adjust the value according to its > > specification if needed. > > I then still can'tl see any reason of having target specific code in > > that area. > Ok, let's give an example then. On MIPS let's say you want to convert > 0x7ff1 (qNaN) to single precision. The mantissa shifted to > the right become 0, so you have to generate a new value. As you > proposed, let's generate a "generic value" 0x7fc0 in the softfloat > routines. This value has to be converted to 0x7fbf in the MIPS > target code. > >>> OK, the values that can cause a problem is all values that would have a > >>> zero mantissa once rounded to sinlge-precision. As the PowerPC requires > >>> that the result would have a zero mantissa (and the result class set to > >> Are you sure of that? According to IEEE 754 a zero mantissa is not a > >> NaN. And tests on a real machine shows different results. > >> 0x7ff1 is converted to 0x7fc0 on a 740/750 CPU. > > > > First, please note that a PowerPC do not have any single precision > > register nor internal representation. The operation here is "round to > > single precision" (frsp) but the result is still a 64 bits float. Then > > the result is more likely to be 0x7fc0. > > 0x7FF1 seems to be a SNaN, according to what I see in the > > PowerPC specification. Then the result is OK: when no exception is > > raised, SNaN is converted to QNaN during rounding to single operation > > (please see below). > > What about 0x7FF80001, which is a QNaN ? According to the > > PowerPC specification, this should be rounded to 0x7FF8 > > which is also a QNaN, then is also OK. Then rounding the mantissa and > > copying sign || exponent || mantissa would, in fact, always be OK in the > > PowerPC case. > > What seem to appear to me now is that the problems are due to the fact > > Mips have an inverted representation of SNaN / QNaN (if I understood > > well) that do not allow distinction between a rounded QNaN and an > > infinity... > > Nope it is not due to the fact that MIPS uses an "inverted" > representation. It is the same problem on x86 or other target, except > that they can allow the distinction between a rounded SNaN and an > infinity. The problem is present on all targets that can represent a > single precision FP For those targets that can make the distinction between rounded sNaN and infinite case, I don't see why there should be a problem. But, I realize now, as you, that PowerPC is really not a good example for comparison as it does not know about 32 bits floats. And I also realize it cannot use the softm
Re: [Qemu-devel] [PATCH] Fix NaN handling in softfloat
Thiemo Seufer a écrit :
> Aurelien Jarno wrote:
>> On Sat, Nov 03, 2007 at 02:06:04PM -0400, Daniel Jacobowitz wrote:
>>> On Sat, Nov 03, 2007 at 06:35:48PM +0100, Aurelien Jarno wrote:
Hi all,
The current softfloat implementation changes qNaN into sNaN when
converting between formats, for no reason. The attached patch fixes
that. It also fixes an off-by-one in the extended double precision
format (aka floatx80), the mantissa is 64-bit long and not 63-bit
long.
With this patch applied all the glibc 2.7 floating point tests
are successfull on MIPS and MIPSEL.
>>> FYI, I posted a similar patch and haven't had time to get back to it.
>>> Andreas reminded me that we need to make sure at least one mantissa
>>> bit is set. If we're confident that the common NaN format will
>>> already have some bit other than the qnan/snan bit set, this is fine;
>>> otherwise, we might want to forcibly set some other mantissa bit.
>>>
>> Please find an updated patch below. I have tried to match real x86, MIPS,
>> HPPA, PowerPC and SPARC hardware when all mantissa bits are cleared.
>
> The default NaN pattern for MIPS and HPPA were broken. (Fabrice spotted
> this.) I currently have the appended patch, it assumes HPPA is similiar
> to MIPS, which is probably incorrect.
HPPA only generates different NaN values, appart from that it behaves
the same as MIPS. On the other side, target-hppa is not yet implemented
(even if some patches could be found on the web).
>> Index: fpu/softfloat-specialize.h
>> ===
>> RCS file: /sources/qemu/qemu/fpu/softfloat-specialize.h,v
>> retrieving revision 1.3
>> diff -u -d -p -r1.3 softfloat-specialize.h
>> --- fpu/softfloat-specialize.h 11 May 2007 17:10:14 - 1.3
>> +++ fpu/softfloat-specialize.h 3 Nov 2007 21:17:57 -
>> @@ -120,9 +120,17 @@ static commonNaNT float32ToCommonNaN( fl
>>
>> static float32 commonNaNToFloat32( commonNaNT a )
>> {
>> -
>> -return ( ( (bits32) a.sign )<<31 ) | 0x7FC0 | ( a.high>>41 );
>> -
>> +bits32 mantissa = a.high>>41;
>> +if (mantissa)
>> +return ( ( (bits32) a.sign )<<31 ) | 0x7F80 | ( mantissa );
>> +else
>> +#if defined(TARGET_MIPS)
>> +return ( ( (bits32) a.sign )<<31 ) | 0x7FBF | ( mantissa );
>> +#elif defined(TARGET_HPPA)
>> +return ( ( (bits32) a.sign )<<31 ) | 0x7FA0 | ( mantissa );
>> +#else
>> +return ( ( (bits32) a.sign )<<31 ) | 0x7FC0;
>> +#endif
>
> This looks odd. Do MIPS and HPPA really need a specialcase here but none
> for doubles? Could you re-check with my patch applied?
That's because there is no greater precision than double precision on
MIPS and HPPA (for the latter I am not 100% sure), so you can't loose
precision on the mantissa when converting to double precision.
I have looked quickly at your patch, it looks like the right approach to
define target specific things at only one place in the file. I will get
a closer tomorrow.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
Re: [Qemu-devel] [PATCH] sparc32 asi cleanups and debug printf
Blue Swirl wrote:
DPRINTF_ASI would be nice.
Here is a revised patch:
Index: target-sparc/op_helper.c
===
RCS file: /sources/qemu/qemu/target-sparc/op_helper.c,v
retrieving revision 1.51
diff -p -u -r1.51 op_helper.c
--- target-sparc/op_helper.c7 Nov 2007 17:03:37 - 1.51
+++ target-sparc/op_helper.c10 Nov 2007 21:24:04 -
@@ -6,6 +6,7 @@
//#define DEBUG_MXCC
//#define DEBUG_UNALIGNED
//#define DEBUG_UNASSIGNED
+//#define DEBUG_ASI
#ifdef DEBUG_MMU
#define DPRINTF_MMU(fmt, args...) \
@@ -21,6 +22,13 @@ do { printf("MXCC: " fmt , ##args); } wh
#define DPRINTF_MXCC(fmt, args...)
#endif
+#ifdef DEBUG_ASI
+#define DPRINTF_ASI(fmt, args...) \
+do { printf("ASI: " fmt , ##args); } while (0)
+#else
+#define DPRINTF_ASI(fmt, args...)
+#endif
+
void raise_exception(int tt)
{
env->exception_index = tt;
@@ -187,7 +195,7 @@ void helper_ld_asi(int asi, int size, in
{
uint32_t ret = 0;
uint64_t tmp;
-#ifdef DEBUG_MXCC
+#if defined(DEBUG_MXCC) || defined(DEBUG_ASI)
uint32_t last_T0 = T0;
#endif
@@ -199,26 +207,34 @@ void helper_ld_asi(int asi, int size, in
ret = env->mxccregs[3];
T0 = env->mxccregs[3] >> 32;
} else
-DPRINTF_MXCC("%08x: unimplemented access size: %d\n", T0,
size);
+DPRINTF_MXCC("read %08x: unimplemented access size: %d\n", T0,
size);
break;
case 0x01c00a04: /* MXCC control register */
if (size == 4)
ret = env->mxccregs[3];
else
-DPRINTF_MXCC("%08x: unimplemented access size: %d\n", T0,
size);
+DPRINTF_MXCC("read %08x: unimplemented access size: %d\n", T0,
size);
+break;
+case 0x01c00c00: /* Module reset register */
+if (size == 8) {
+ret = env->mxccregs[5];
+T0 = env->mxccregs[5] >> 32;
+// should we do something here?
+} else
+DPRINTF_MXCC("read %08x: unimplemented access size: %d\n", T0,
size);
break;
case 0x01c00f00: /* MBus port address register */
if (size == 8) {
ret = env->mxccregs[7];
T0 = env->mxccregs[7] >> 32;
} else
-DPRINTF_MXCC("%08x: unimplemented access size: %d\n", T0,
size);
+DPRINTF_MXCC("read %08x: unimplemented access size: %d\n", T0,
size);
break;
default:
-DPRINTF_MXCC("%08x: unimplemented address, size: %d\n", T0, size);
+DPRINTF_MXCC("read %08x: unimplemented address, size: %d\n", T0,
size);
break;
}
-DPRINTF_MXCC("asi = %d, size = %d, sign = %d, T0 = %08x -> ret = %08x,"
+DPRINTF_MXCC("read(asi %d, size %d, sign %d) T0 = %08x -> ret = %08x, "
"T0 = %08x\n", asi, size, sign, last_T0, ret, T0);
#ifdef DEBUG_MXCC
dump_mxcc(env);
@@ -355,6 +371,8 @@ void helper_ld_asi(int asi, int size, in
break;
case 0x21 ... 0x2d: /* MMU passthrough, unassigned */
default:
+DPRINTF_ASI("read: %08x asi 0x%02x size %d unsupported address",
+ last_T0, asi, size);
do_unassigned_access(T0, 0, 0, 1);
ret = 0;
break;
@@ -374,6 +392,9 @@ void helper_ld_asi(int asi, int size, in
}
else
T1 = ret;
+
+DPRINTF_ASI("helper_ld_asi(asi 0x%02x, size %d, sign %d) T0 = %08x -> "
+ "T0 = %08x T1 = %08x\n", asi, size, sign, last_T0, T0, T1);
}
void helper_st_asi(int asi, int size)
@@ -385,31 +406,31 @@ void helper_st_asi(int asi, int size)
if (size == 8)
env->mxccdata[0] = ((uint64_t)T1 << 32) | T2;
else
-DPRINTF_MXCC("%08x: unimplemented access size: %d\n", T0,
size);
+DPRINTF_MXCC("write %08x: unimplemented access size: %d\n",
T0, size);
break;
case 0x01c8: /* MXCC stream data register 1 */
if (size == 8)
env->mxccdata[1] = ((uint64_t)T1 << 32) | T2;
else
-DPRINTF_MXCC("%08x: unimplemented access size: %d\n", T0,
size);
+DPRINTF_MXCC("write %08x: unimplemented access size: %d\n",
T0, size);
break;
case 0x01c00010: /* MXCC stream data register 2 */
if (size == 8)
env->mxccdata[2] = ((uint64_t)T1 << 32) | T2;
else
-DPRINTF_MXCC("%08x: unimplemented access size: %d\n", T0,
size);
+DPRINTF_MXCC("write %08x: unimplemented access size: %d\n",
T0, size);
break;
case 0x01c00018: /* MXCC stream data register 3 */
if (size == 8)
env->mxccdata[3] = ((uint64_t)T1 << 32) | T2;
else
-DPRINTF_MXCC("%08x: unimplemented access size: %d\n"
Re: [Qemu-devel] [PATCH] Fix NaN handling in softfloat
Aurelien Jarno wrote:
> On Sat, Nov 03, 2007 at 02:06:04PM -0400, Daniel Jacobowitz wrote:
> > On Sat, Nov 03, 2007 at 06:35:48PM +0100, Aurelien Jarno wrote:
> > > Hi all,
> > >
> > > The current softfloat implementation changes qNaN into sNaN when
> > > converting between formats, for no reason. The attached patch fixes
> > > that. It also fixes an off-by-one in the extended double precision
> > > format (aka floatx80), the mantissa is 64-bit long and not 63-bit
> > > long.
> > >
> > > With this patch applied all the glibc 2.7 floating point tests
> > > are successfull on MIPS and MIPSEL.
> >
> > FYI, I posted a similar patch and haven't had time to get back to it.
> > Andreas reminded me that we need to make sure at least one mantissa
> > bit is set. If we're confident that the common NaN format will
> > already have some bit other than the qnan/snan bit set, this is fine;
> > otherwise, we might want to forcibly set some other mantissa bit.
> >
>
> Please find an updated patch below. I have tried to match real x86, MIPS,
> HPPA, PowerPC and SPARC hardware when all mantissa bits are cleared.
The default NaN pattern for MIPS and HPPA were broken. (Fabrice spotted
this.) I currently have the appended patch, it assumes HPPA is similiar
to MIPS, which is probably incorrect.
> Index: fpu/softfloat-specialize.h
> ===
> RCS file: /sources/qemu/qemu/fpu/softfloat-specialize.h,v
> retrieving revision 1.3
> diff -u -d -p -r1.3 softfloat-specialize.h
> --- fpu/softfloat-specialize.h11 May 2007 17:10:14 - 1.3
> +++ fpu/softfloat-specialize.h3 Nov 2007 21:17:57 -
> @@ -120,9 +120,17 @@ static commonNaNT float32ToCommonNaN( fl
>
> static float32 commonNaNToFloat32( commonNaNT a )
> {
> -
> -return ( ( (bits32) a.sign )<<31 ) | 0x7FC0 | ( a.high>>41 );
> -
> +bits32 mantissa = a.high>>41;
> +if (mantissa)
> +return ( ( (bits32) a.sign )<<31 ) | 0x7F80 | ( mantissa );
> +else
> +#if defined(TARGET_MIPS)
> +return ( ( (bits32) a.sign )<<31 ) | 0x7FBF | ( mantissa );
> +#elif defined(TARGET_HPPA)
> +return ( ( (bits32) a.sign )<<31 ) | 0x7FA0 | ( mantissa );
> +#else
> +return ( ( (bits32) a.sign )<<31 ) | 0x7FC0;
> +#endif
This looks odd. Do MIPS and HPPA really need a specialcase here but none
for doubles? Could you re-check with my patch applied?
Thiemo
Index: qemu-work/fpu/softfloat-specialize.h
===
--- qemu-work.orig/fpu/softfloat-specialize.h 2007-06-26 21:22:50.0
+0100
+++ qemu-work/fpu/softfloat-specialize.h2007-11-10 19:49:37.0
+
@@ -30,6 +30,12 @@
=*/
+#if defined(TARGET_MIPS) || defined(TARGET_HPPA)
+#define SNAN_BIT_IS_ONE1
+#else
+#define SNAN_BIT_IS_ONE0
+#endif
+
/*
| Underflow tininess-detection mode, statically initialized to default value.
| (The declaration in `softfloat.h' must match the `int8' type here.)
@@ -45,9 +51,7 @@
void float_raise( int8 flags STATUS_PARAM )
{
-
STATUS(float_exception_flags) |= flags;
-
}
/*
@@ -61,20 +65,20 @@
/*
| The pattern for a default generated single-precision NaN.
**/
-#if defined(TARGET_MIPS) || defined(TARGET_HPPA)
-#define float32_default_nan 0xFF80
+#if SNAN_BIT_IS_ONE
+#define float32_default_nan 0x7FBF
#else
#define float32_default_nan 0xFFC0
#endif
/*
-| Returns 1 if the single-precision floating-point value `a' is a NaN;
-| otherwise returns 0.
+| Returns 1 if the single-precision floating-point value `a' is a quiet
+| NaN; otherwise returns 0.
**/
int float32_is_nan( float32 a )
{
-#if defined(TARGET_MIPS) || defined(TARGET_HPPA)
+#if SNAN_BIT_IS_ONE
return ( ( ( a>>22 ) & 0x1FF ) == 0x1FE ) && ( a & 0x003F );
#else
return ( 0xFF80 <= (bits32) ( a<<1 ) );
@@ -88,7 +92,7 @@
int float32_is_signaling_nan( float32 a )
{
-#if defined(TARGET_MIPS) || defined(TARGET_HPPA)
+#if SNAN_BIT_IS_ONE
return ( 0xFF80 <= (bits32) ( a<<1 ) );
#else
return ( ( ( a>>22 ) & 0x1FF ) == 0x1FE ) && ( a & 0x003F );
@@ -110,7 +114,6 @@
z.low = 0;
z.high = ( (bits64) a )<<41;
return z;
-
}
/*
@@ -120,9 +123,7 @@
static float32 commonNaNToFloat32( commonNaNT a )
{
-
return
Re: [Qemu-devel] [PATCH] sparc32 asi cleanups and debug printf
On 11/10/07, Robert Reif <[EMAIL PROTECTED]> wrote: > This patch makes debugging asi and mxcc accesses easier to follow. ... and adds a new register. DPRINTF_ASI would be nice.
Re: [Qemu-devel] ES1370 problems with Win98SE
On Fri, 9 Nov 2007, Rick Vernam wrote: On Thursday 08 November 2007 10:51:01 pm Kyle Kilpatrick wrote: Hello. First, let me say that I realize this is not exactly the place for this. Non-developer problems with Qemu should go on the Qemu forum... But they're down right now, so please bear with me here. I apologize for taking up all you developers' time. [..snip..] For some reason, I am thinking that I never got the ES1370 card to work unless I did funny things with commas in it's declaration in the command line. In my shell script, I have this: -soundhw ,es1370, Is that necessary? I have no clue, but that's what I use & it works. No it shouldn't be necessary. I just ran dsl with `-soundhw es1370' and it worked as expected. -- mailto:[EMAIL PROTECTED]
[Qemu-devel] qemu vl.c vl.h cutils.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard07/11/10 19:36:39 Modified files: . : vl.c vl.h cutils.c Log message: always use mktimegm CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.356&r2=1.357 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.291&r2=1.292 http://cvs.savannah.gnu.org/viewcvs/qemu/cutils.c?cvsroot=qemu&r1=1.2&r2=1.3
[Qemu-devel] qemu Makefile
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/11/10 19:30:52 Modified files: . : Makefile Log message: Fix Makefile dependencies. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemu&r1=1.128&r2=1.129
[Qemu-devel] qemu/hw dummy_m68k.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/11/10 19:21:30 Modified files: hw : dummy_m68k.c Log message: Fix build failure. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/dummy_m68k.c?cvsroot=qemu&r1=1.1&r2=1.2
[Qemu-devel] [PATCH] sparc32 asi cleanups and debug printf
This patch makes debugging asi and mxcc accesses easier to follow.
Index: target-sparc/op_helper.c
===
RCS file: /sources/qemu/qemu/target-sparc/op_helper.c,v
retrieving revision 1.51
diff -p -u -r1.51 op_helper.c
--- target-sparc/op_helper.c7 Nov 2007 17:03:37 - 1.51
+++ target-sparc/op_helper.c10 Nov 2007 18:22:34 -
@@ -6,6 +6,7 @@
//#define DEBUG_MXCC
//#define DEBUG_UNALIGNED
//#define DEBUG_UNASSIGNED
+//#define DEBUG_ASI
#ifdef DEBUG_MMU
#define DPRINTF_MMU(fmt, args...) \
@@ -187,7 +188,7 @@ void helper_ld_asi(int asi, int size, in
{
uint32_t ret = 0;
uint64_t tmp;
-#ifdef DEBUG_MXCC
+#if defined(DEBUG_MXCC) || defined(DEBUG_ASI)
uint32_t last_T0 = T0;
#endif
@@ -199,26 +200,34 @@ void helper_ld_asi(int asi, int size, in
ret = env->mxccregs[3];
T0 = env->mxccregs[3] >> 32;
} else
-DPRINTF_MXCC("%08x: unimplemented access size: %d\n", T0,
size);
+DPRINTF_MXCC("read %08x: unimplemented access size: %d\n", T0,
size);
break;
case 0x01c00a04: /* MXCC control register */
if (size == 4)
ret = env->mxccregs[3];
else
-DPRINTF_MXCC("%08x: unimplemented access size: %d\n", T0,
size);
+DPRINTF_MXCC("read %08x: unimplemented access size: %d\n", T0,
size);
+break;
+case 0x01c00c00: /* Module reset register */
+if (size == 8) {
+ret = env->mxccregs[5];
+T0 = env->mxccregs[5] >> 32;
+// should we do something here?
+} else
+DPRINTF_MXCC("read %08x: unimplemented access size: %d\n", T0,
size);
break;
case 0x01c00f00: /* MBus port address register */
if (size == 8) {
ret = env->mxccregs[7];
T0 = env->mxccregs[7] >> 32;
} else
-DPRINTF_MXCC("%08x: unimplemented access size: %d\n", T0,
size);
+DPRINTF_MXCC("read %08x: unimplemented access size: %d\n", T0,
size);
break;
default:
-DPRINTF_MXCC("%08x: unimplemented address, size: %d\n", T0, size);
+DPRINTF_MXCC("read %08x: unimplemented address, size: %d\n", T0,
size);
break;
}
-DPRINTF_MXCC("asi = %d, size = %d, sign = %d, T0 = %08x -> ret = %08x,"
+DPRINTF_MXCC("read(asi %d, size %d, sign %d) T0 = %08x -> ret = %08x, "
"T0 = %08x\n", asi, size, sign, last_T0, ret, T0);
#ifdef DEBUG_MXCC
dump_mxcc(env);
@@ -355,6 +364,10 @@ void helper_ld_asi(int asi, int size, in
break;
case 0x21 ... 0x2d: /* MMU passthrough, unassigned */
default:
+#ifdef DEBUG_ASI
+printf("read: %08x asi 0x%02x size %d unsupported address",
+ last_T0, asi, size);
+#endif
do_unassigned_access(T0, 0, 0, 1);
ret = 0;
break;
@@ -374,6 +387,11 @@ void helper_ld_asi(int asi, int size, in
}
else
T1 = ret;
+
+#ifdef DEBUG_ASI
+printf("helper_ld_asi(asi 0x%02x, size %d, sign %d) T0 = %08x -> "
+ "T0 = %08x T1 = %08x\n", asi, size, sign, last_T0, T0, T1);
+#endif
}
void helper_st_asi(int asi, int size)
@@ -385,31 +403,31 @@ void helper_st_asi(int asi, int size)
if (size == 8)
env->mxccdata[0] = ((uint64_t)T1 << 32) | T2;
else
-DPRINTF_MXCC("%08x: unimplemented access size: %d\n", T0,
size);
+DPRINTF_MXCC("write %08x: unimplemented access size: %d\n",
T0, size);
break;
case 0x01c8: /* MXCC stream data register 1 */
if (size == 8)
env->mxccdata[1] = ((uint64_t)T1 << 32) | T2;
else
-DPRINTF_MXCC("%08x: unimplemented access size: %d\n", T0,
size);
+DPRINTF_MXCC("write %08x: unimplemented access size: %d\n",
T0, size);
break;
case 0x01c00010: /* MXCC stream data register 2 */
if (size == 8)
env->mxccdata[2] = ((uint64_t)T1 << 32) | T2;
else
-DPRINTF_MXCC("%08x: unimplemented access size: %d\n", T0,
size);
+DPRINTF_MXCC("write %08x: unimplemented access size: %d\n",
T0, size);
break;
case 0x01c00018: /* MXCC stream data register 3 */
if (size == 8)
env->mxccdata[3] = ((uint64_t)T1 << 32) | T2;
else
-DPRINTF_MXCC("%08x: unimplemented access size: %d\n", T0,
size);
+DPRINTF_MXCC("write %08x: unimplemented access size: %d\n",
T0, size);
break;
case 0x01c00100: /* MXCC stream source */
if (size == 8)
env->mxccregs[0] = ((uint64_t)T1 << 32) | T2;
else
-
Re: [Qemu-devel] [PATCH] Fix NaN handling in softfloat
J. Mayer a écrit : > On Sat, 2007-11-10 at 17:15 +0100, Aurelien Jarno wrote: >> J. Mayer a écrit : >>> On Sat, 2007-11-10 at 10:35 +0100, Aurelien Jarno wrote: J. Mayer a écrit : > On Thu, 2007-11-08 at 00:05 +0100, Aurelien Jarno wrote: >> On Tue, Nov 06, 2007 at 09:01:13PM +0100, J. Mayer wrote: >>> On Sat, 2007-11-03 at 22:28 +0100, Aurelien Jarno wrote: On Sat, Nov 03, 2007 at 02:06:04PM -0400, Daniel Jacobowitz wrote: > On Sat, Nov 03, 2007 at 06:35:48PM +0100, Aurelien Jarno wrote: >> Hi all, >> >> The current softfloat implementation changes qNaN into sNaN when >> converting between formats, for no reason. The attached patch fixes >> that. It also fixes an off-by-one in the extended double precision >> format (aka floatx80), the mantissa is 64-bit long and not 63-bit >> long. >> >> With this patch applied all the glibc 2.7 floating point tests >> are successfull on MIPS and MIPSEL. >>> [...] >> Anyway there is no way to do that in the target specific code *after >> the conversion*, as the detection of a mantissa being nul when >> converting from double to single precision can only be done when both >> values are still known. In other words when the value is not fixed >> during the conversion, the value 0x7f80 can either be infinity or a >> conversion of NaN from double to single precision, and thus is it not >> possible to fix the value afterwards in the target specific code. > I don't say you have to return an infinity when the argument is a qNaN. > I just say you have to return a qNaN in a generic way. Just return sign > | 0x7f80 | mantissa, which is the more generic form and seems to me > to even be OK for sNaNs. It's even needed for some target (not to say 0x7f80 is actually not a NaN, but infinity. > PowerPC) that specify that the result have to be equal to the operand > (in the single precision format, of course) in such a case. This is > simpler, it ensures that any target could then detect the presence of a > NaN, know which one, and can then adjust the value according to its > specification if needed. > I then still can'tl see any reason of having target specific code in > that area. Ok, let's give an example then. On MIPS let's say you want to convert 0x7ff1 (qNaN) to single precision. The mantissa shifted to the right become 0, so you have to generate a new value. As you proposed, let's generate a "generic value" 0x7fc0 in the softfloat routines. This value has to be converted to 0x7fbf in the MIPS target code. >>> OK, the values that can cause a problem is all values that would have a >>> zero mantissa once rounded to sinlge-precision. As the PowerPC requires >>> that the result would have a zero mantissa (and the result class set to >> Are you sure of that? According to IEEE 754 a zero mantissa is not a >> NaN. And tests on a real machine shows different results. >> 0x7ff1 is converted to 0x7fc0 on a 740/750 CPU. > > First, please note that a PowerPC do not have any single precision > register nor internal representation. The operation here is "round to > single precision" (frsp) but the result is still a 64 bits float. Then > the result is more likely to be 0x7fc0. > 0x7FF1 seems to be a SNaN, according to what I see in the > PowerPC specification. Then the result is OK: when no exception is > raised, SNaN is converted to QNaN during rounding to single operation > (please see below). > What about 0x7FF80001, which is a QNaN ? According to the > PowerPC specification, this should be rounded to 0x7FF8 > which is also a QNaN, then is also OK. Then rounding the mantissa and > copying sign || exponent || mantissa would, in fact, always be OK in the > PowerPC case. > What seem to appear to me now is that the problems are due to the fact > Mips have an inverted representation of SNaN / QNaN (if I understood > well) that do not allow distinction between a rounded QNaN and an > infinity... Nope it is not due to the fact that MIPS uses an "inverted" representation. It is the same problem on x86 or other target, except that they can allow the distinction between a rounded SNaN and an infinity. The problem is present on all targets that can represent a single precision FP value. >>> qNan), I can see no way to handle this case in the generic code. And >>> even adding a "#ifdef TARGET_PPC" won't solve the problem as the PowerPC >>> code would not be able to make the distinction between infinity case and >>> qNaN case. Then, the only solution, as you already mentioned, is to >>> check for qNaN before calling the rounding function. As the target >>> emulation code already has to check for sNaN to be able to raise an >>> exception when it's needed, checking for qNaN would cost no
[Qemu-devel] qemu Makefile.target vl.c vl.h hw/dummy_m68k.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/11/10 18:03:23 Modified files: . : Makefile.target vl.c vl.h Added files: hw : dummy_m68k.c Log message: Add dummy m68k board. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.218&r2=1.219 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.355&r2=1.356 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.290&r2=1.291 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/dummy_m68k.c?cvsroot=qemu&rev=1.1
[Qemu-devel] qemu/target-m68k translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/11/10 17:43:49 Modified files: target-m68k: translate.c Log message: Fix m68k FP register debug dumps. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/translate.c?cvsroot=qemu&r1=1.21&r2=1.22
[Qemu-devel] qemu arm-dis.c dis-asm.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/11/10 17:38:00 Modified files: . : arm-dis.c dis-asm.h Log message: Update ARM disassembler. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/arm-dis.c?cvsroot=qemu&r1=1.5&r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/dis-asm.h?cvsroot=qemu&r1=1.17&r2=1.18
Re: [Qemu-devel] [PATCH] Fix NaN handling in softfloat
On Sat, 2007-11-10 at 17:15 +0100, Aurelien Jarno wrote: > J. Mayer a écrit : > > On Sat, 2007-11-10 at 10:35 +0100, Aurelien Jarno wrote: > >> J. Mayer a écrit : > >>> On Thu, 2007-11-08 at 00:05 +0100, Aurelien Jarno wrote: > On Tue, Nov 06, 2007 at 09:01:13PM +0100, J. Mayer wrote: > > On Sat, 2007-11-03 at 22:28 +0100, Aurelien Jarno wrote: > >> On Sat, Nov 03, 2007 at 02:06:04PM -0400, Daniel Jacobowitz wrote: > >>> On Sat, Nov 03, 2007 at 06:35:48PM +0100, Aurelien Jarno wrote: > Hi all, > > The current softfloat implementation changes qNaN into sNaN when > converting between formats, for no reason. The attached patch fixes > that. It also fixes an off-by-one in the extended double precision > format (aka floatx80), the mantissa is 64-bit long and not 63-bit > long. > > With this patch applied all the glibc 2.7 floating point tests > are successfull on MIPS and MIPSEL. > > [...] > Anyway there is no way to do that in the target specific code *after > the conversion*, as the detection of a mantissa being nul when > converting from double to single precision can only be done when both > values are still known. In other words when the value is not fixed > during the conversion, the value 0x7f80 can either be infinity or a > conversion of NaN from double to single precision, and thus is it not > possible to fix the value afterwards in the target specific code. > >>> I don't say you have to return an infinity when the argument is a qNaN. > >>> I just say you have to return a qNaN in a generic way. Just return sign > >>> | 0x7f80 | mantissa, which is the more generic form and seems to me > >>> to even be OK for sNaNs. It's even needed for some target (not to say > >> 0x7f80 is actually not a NaN, but infinity. > >> > >>> PowerPC) that specify that the result have to be equal to the operand > >>> (in the single precision format, of course) in such a case. This is > >>> simpler, it ensures that any target could then detect the presence of a > >>> NaN, know which one, and can then adjust the value according to its > >>> specification if needed. > >>> I then still can'tl see any reason of having target specific code in > >>> that area. > >> Ok, let's give an example then. On MIPS let's say you want to convert > >> 0x7ff1 (qNaN) to single precision. The mantissa shifted to > >> the right become 0, so you have to generate a new value. As you > >> proposed, let's generate a "generic value" 0x7fc0 in the softfloat > >> routines. This value has to be converted to 0x7fbf in the MIPS > >> target code. > > > > OK, the values that can cause a problem is all values that would have a > > zero mantissa once rounded to sinlge-precision. As the PowerPC requires > > that the result would have a zero mantissa (and the result class set to > > Are you sure of that? According to IEEE 754 a zero mantissa is not a > NaN. And tests on a real machine shows different results. > 0x7ff1 is converted to 0x7fc0 on a 740/750 CPU. First, please note that a PowerPC do not have any single precision register nor internal representation. The operation here is "round to single precision" (frsp) but the result is still a 64 bits float. Then the result is more likely to be 0x7fc0. 0x7FF1 seems to be a SNaN, according to what I see in the PowerPC specification. Then the result is OK: when no exception is raised, SNaN is converted to QNaN during rounding to single operation (please see below). What about 0x7FF80001, which is a QNaN ? According to the PowerPC specification, this should be rounded to 0x7FF8 which is also a QNaN, then is also OK. Then rounding the mantissa and copying sign || exponent || mantissa would, in fact, always be OK in the PowerPC case. What seem to appear to me now is that the problems are due to the fact Mips have an inverted representation of SNaN / QNaN (if I understood well) that do not allow distinction between a rounded QNaN and an infinity... > > qNan), I can see no way to handle this case in the generic code. And > > even adding a "#ifdef TARGET_PPC" won't solve the problem as the PowerPC > > code would not be able to make the distinction between infinity case and > > qNaN case. Then, the only solution, as you already mentioned, is to > > check for qNaN before calling the rounding function. As the target > > emulation code already has to check for sNaN to be able to raise an > > exception when it's needed, checking for qNaN would cost nothing more; > > Except this is currently done *after* the call to the rounding function, > using the flags returned by the softmmu routines. Doing a check before > and after would slow down the emulation. On PowerPC at least, you have to check operands for sNaN _before_ doing any floating-point operation and check the result _after_ having do
[Qemu-devel] monitor's memory dump
Hello Look at the following monitor's memory dump commands: (qemu) x/1xw 0 : 0xb7d00694 (qemu) x/1xw 1 0001: 0xb7d00694 (qemu) x/2xw 0 : 0xb7d00694 0x081459a6 It looks like the single 4-byte dumps always show the first memory location. Is it a bug ? I use qemu-0.9.0 under linux. I run the qemu with the pure bzImage 2.6.23 from kernel.org. qemu -kernel bzImage ... Thank You for help. PS: sorry for posting to devel mailing list but I cannot subscribe to the "Qemu for Linux" mailing list. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[Qemu-devel] qemu/hw integratorcp.c pl011.c pl050.c pl080.c ...
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 07/11/10 16:34:47 Modified files: hw : integratorcp.c pl011.c pl050.c pl080.c pl110.c pl181.c pl190.c smc91c111.c Log message: Fix 64-bit host printf format mismatches. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/integratorcp.c?cvsroot=qemu&r1=1.22&r2=1.23 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl011.c?cvsroot=qemu&r1=1.7&r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl050.c?cvsroot=qemu&r1=1.6&r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl080.c?cvsroot=qemu&r1=1.5&r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl110.c?cvsroot=qemu&r1=1.13&r2=1.14 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl181.c?cvsroot=qemu&r1=1.8&r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl190.c?cvsroot=qemu&r1=1.5&r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/smc91c111.c?cvsroot=qemu&r1=1.9&r2=1.10
Re: [Qemu-devel] [PATCH] Fix NaN handling in softfloat
J. Mayer a écrit : > On Sat, 2007-11-10 at 10:35 +0100, Aurelien Jarno wrote: >> J. Mayer a écrit : >>> On Thu, 2007-11-08 at 00:05 +0100, Aurelien Jarno wrote: On Tue, Nov 06, 2007 at 09:01:13PM +0100, J. Mayer wrote: > On Sat, 2007-11-03 at 22:28 +0100, Aurelien Jarno wrote: >> On Sat, Nov 03, 2007 at 02:06:04PM -0400, Daniel Jacobowitz wrote: >>> On Sat, Nov 03, 2007 at 06:35:48PM +0100, Aurelien Jarno wrote: Hi all, The current softfloat implementation changes qNaN into sNaN when converting between formats, for no reason. The attached patch fixes that. It also fixes an off-by-one in the extended double precision format (aka floatx80), the mantissa is 64-bit long and not 63-bit long. With this patch applied all the glibc 2.7 floating point tests are successfull on MIPS and MIPSEL. > [...] Anyway there is no way to do that in the target specific code *after the conversion*, as the detection of a mantissa being nul when converting from double to single precision can only be done when both values are still known. In other words when the value is not fixed during the conversion, the value 0x7f80 can either be infinity or a conversion of NaN from double to single precision, and thus is it not possible to fix the value afterwards in the target specific code. >>> I don't say you have to return an infinity when the argument is a qNaN. >>> I just say you have to return a qNaN in a generic way. Just return sign >>> | 0x7f80 | mantissa, which is the more generic form and seems to me >>> to even be OK for sNaNs. It's even needed for some target (not to say >> 0x7f80 is actually not a NaN, but infinity. >> >>> PowerPC) that specify that the result have to be equal to the operand >>> (in the single precision format, of course) in such a case. This is >>> simpler, it ensures that any target could then detect the presence of a >>> NaN, know which one, and can then adjust the value according to its >>> specification if needed. >>> I then still can'tl see any reason of having target specific code in >>> that area. >> Ok, let's give an example then. On MIPS let's say you want to convert >> 0x7ff1 (qNaN) to single precision. The mantissa shifted to >> the right become 0, so you have to generate a new value. As you >> proposed, let's generate a "generic value" 0x7fc0 in the softfloat >> routines. This value has to be converted to 0x7fbf in the MIPS >> target code. > > OK, the values that can cause a problem is all values that would have a > zero mantissa once rounded to sinlge-precision. As the PowerPC requires > that the result would have a zero mantissa (and the result class set to Are you sure of that? According to IEEE 754 a zero mantissa is not a NaN. And tests on a real machine shows different results. 0x7ff1 is converted to 0x7fc0 on a 740/750 CPU. > qNan), I can see no way to handle this case in the generic code. And > even adding a "#ifdef TARGET_PPC" won't solve the problem as the PowerPC > code would not be able to make the distinction between infinity case and > qNaN case. Then, the only solution, as you already mentioned, is to > check for qNaN before calling the rounding function. As the target > emulation code already has to check for sNaN to be able to raise an > exception when it's needed, checking for qNaN would cost nothing more; Except this is currently done *after* the call to the rounding function, using the flags returned by the softmmu routines. Doing a check before and after would slow down the emulation. > just have to change the check if (float64_is_signaling_nan) check with a > check for NaN and handle the two cases by hand. I can see no other way > to have all cases handled for all targets specific cases, do you ? > If you can confirm that the all PowerPC CPU are IEEE compliant and should behave like the 740/750, the patch I proposed is another way to be correct on all target, including PowerPC. But it seems you don't really like to add target specific code in the softmmu routines. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net
[Qemu-devel] qemu vl.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard07/11/10 15:36:21 Modified files: . : vl.h Log message: exported display init functions to common code CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.289&r2=1.290
[Qemu-devel] qemu exec.c darwin-user/main.c hw/an5206.c hw/e...
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard07/11/10 15:15:54 Modified files: . : exec.c darwin-user: main.c hw : an5206.c etraxfs.c integratorcp.c mcf5208.c mips_malta.c mips_mipssim.c mips_pica61.c mips_r4k.c omap.c pc.c ppc4xx_devs.c ppc_chrp.c ppc_oldworld.c ppc_prep.c pxa2xx.c r2d.c realview.c shix.c sun4m.c sun4u.c versatilepb.c linux-user : main.c target-alpha : cpu.h translate.c target-arm : cpu.h helper.c target-cris: cpu.h translate.c target-i386: cpu.h helper2.c target-m68k: cpu.h helper.c translate.c target-mips: cpu.h translate.c translate_init.c target-ppc : cpu.h helper.c translate_init.c target-sh4 : cpu.h translate.c target-sparc : cpu.h translate.c tests : qruncom.c Log message: added cpu_model parameter to cpu_init() CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.112&r2=1.113 http://cvs.savannah.gnu.org/viewcvs/qemu/darwin-user/main.c?cvsroot=qemu&r1=1.9&r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/an5206.c?cvsroot=qemu&r1=1.4&r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/etraxfs.c?cvsroot=qemu&r1=1.2&r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/integratorcp.c?cvsroot=qemu&r1=1.21&r2=1.22 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mcf5208.c?cvsroot=qemu&r1=1.5&r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_malta.c?cvsroot=qemu&r1=1.47&r2=1.48 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_mipssim.c?cvsroot=qemu&r1=1.5&r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_pica61.c?cvsroot=qemu&r1=1.10&r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_r4k.c?cvsroot=qemu&r1=1.51&r2=1.52 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.c?cvsroot=qemu&r1=1.19&r2=1.20 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pc.c?cvsroot=qemu&r1=1.90&r2=1.91 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc4xx_devs.c?cvsroot=qemu&r1=1.1&r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_chrp.c?cvsroot=qemu&r1=1.48&r2=1.49 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_oldworld.c?cvsroot=qemu&r1=1.4&r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_prep.c?cvsroot=qemu&r1=1.51&r2=1.52 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx.c?cvsroot=qemu&r1=1.18&r2=1.19 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/r2d.c?cvsroot=qemu&r1=1.3&r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/realview.c?cvsroot=qemu&r1=1.12&r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/shix.c?cvsroot=qemu&r1=1.6&r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemu&r1=1.58&r2=1.59 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4u.c?cvsroot=qemu&r1=1.24&r2=1.25 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/versatilepb.c?cvsroot=qemu&r1=1.18&r2=1.19 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemu&r1=1.144&r2=1.145 http://cvs.savannah.gnu.org/viewcvs/qemu/target-alpha/cpu.h?cvsroot=qemu&r1=1.10&r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/target-alpha/translate.c?cvsroot=qemu&r1=1.7&r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/cpu.h?cvsroot=qemu&r1=1.36&r2=1.37 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/helper.c?cvsroot=qemu&r1=1.24&r2=1.25 http://cvs.savannah.gnu.org/viewcvs/qemu/target-cris/cpu.h?cvsroot=qemu&r1=1.2&r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/target-cris/translate.c?cvsroot=qemu&r1=1.1&r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/cpu.h?cvsroot=qemu&r1=1.53&r2=1.54 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper2.c?cvsroot=qemu&r1=1.56&r2=1.57 http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/cpu.h?cvsroot=qemu&r1=1.14&r2=1.15 http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/helper.c?cvsroot=qemu&r1=1.8&r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/translate.c?cvsroot=qemu&r1=1.20&r2=1.21 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/cpu.h?cvsroot=qemu&r1=1.52&r2=1.53 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.112&r2=1.113 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate_init.c?cvsroot=qemu&r1=1.27&r2=1.28 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemu&r1=1.88&r2=1.89 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemu&r1=1.88&r2=1.89 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemu&r1=1.56&r2=1.57 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sh4/cpu.h?cvsroot=qemu&r1=1.11&r2=1.12 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sh4/translate.c?cvsroot=qemu&r1=1.18&r2=1.19 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/cpu.h?cvsroot=qemu&r1=1.57&r2=1.58 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?c
[Qemu-devel] mips64 gdbstub broken
A recent CVS commit ("Fix gdb stub for MIPS64.") looks incorrect:
> diff -u -r1.66 -r1.67
> --- gdbstub.c 8 Oct 2007 13:16:14 - 1.66
> +++ gdbstub.c 25 Oct 2007 21:30:37 - 1.67
> @@ -563,7 +563,7 @@
> ptr += sizeof(target_ulong);
>}
>
> -*(target_ulong *)ptr = tswapl(env->CP0_Status);
> +*(target_ulong *)ptr = (int32_t)tswap32(env->CP0_Status);
> ptr += sizeof(target_ulong);
This is obviously bogus. The new value sent to gdb will depend on the host
endianness.
I suspect what you meant to do is
*(target_ulong *)ptr = tswapl((int32_t)env->CP0_Status);
i.e. sign extended to a target-endian 64-bit value. This is consistent with
the implementation of cpu_gdb_write_registers.
Could you confirm?
Paul
Re: [Qemu-devel] [PATCH] Fix NaN handling in softfloat
On Sat, 2007-11-10 at 10:35 +0100, Aurelien Jarno wrote: > J. Mayer a écrit : > > On Thu, 2007-11-08 at 00:05 +0100, Aurelien Jarno wrote: > >> On Tue, Nov 06, 2007 at 09:01:13PM +0100, J. Mayer wrote: > >>> On Sat, 2007-11-03 at 22:28 +0100, Aurelien Jarno wrote: > On Sat, Nov 03, 2007 at 02:06:04PM -0400, Daniel Jacobowitz wrote: > > On Sat, Nov 03, 2007 at 06:35:48PM +0100, Aurelien Jarno wrote: > >> Hi all, > >> > >> The current softfloat implementation changes qNaN into sNaN when > >> converting between formats, for no reason. The attached patch fixes > >> that. It also fixes an off-by-one in the extended double precision > >> format (aka floatx80), the mantissa is 64-bit long and not 63-bit > >> long. > >> > >> With this patch applied all the glibc 2.7 floating point tests > >> are successfull on MIPS and MIPSEL. [...] > >> Anyway there is no way to do that in the target specific code *after > >> the conversion*, as the detection of a mantissa being nul when > >> converting from double to single precision can only be done when both > >> values are still known. In other words when the value is not fixed > >> during the conversion, the value 0x7f80 can either be infinity or a > >> conversion of NaN from double to single precision, and thus is it not > >> possible to fix the value afterwards in the target specific code. > > > > I don't say you have to return an infinity when the argument is a qNaN. > > I just say you have to return a qNaN in a generic way. Just return sign > > | 0x7f80 | mantissa, which is the more generic form and seems to me > > to even be OK for sNaNs. It's even needed for some target (not to say > > 0x7f80 is actually not a NaN, but infinity. > > > PowerPC) that specify that the result have to be equal to the operand > > (in the single precision format, of course) in such a case. This is > > simpler, it ensures that any target could then detect the presence of a > > NaN, know which one, and can then adjust the value according to its > > specification if needed. > > I then still can'tl see any reason of having target specific code in > > that area. > > Ok, let's give an example then. On MIPS let's say you want to convert > 0x7ff1 (qNaN) to single precision. The mantissa shifted to > the right become 0, so you have to generate a new value. As you > proposed, let's generate a "generic value" 0x7fc0 in the softfloat > routines. This value has to be converted to 0x7fbf in the MIPS > target code. OK, the values that can cause a problem is all values that would have a zero mantissa once rounded to sinlge-precision. As the PowerPC requires that the result would have a zero mantissa (and the result class set to qNan), I can see no way to handle this case in the generic code. And even adding a "#ifdef TARGET_PPC" won't solve the problem as the PowerPC code would not be able to make the distinction between infinity case and qNaN case. Then, the only solution, as you already mentioned, is to check for qNaN before calling the rounding function. As the target emulation code already has to check for sNaN to be able to raise an exception when it's needed, checking for qNaN would cost nothing more; just have to change the check if (float64_is_signaling_nan) check with a check for NaN and handle the two cases by hand. I can see no other way to have all cases handled for all targets specific cases, do you ? [...] -- J. Mayer <[EMAIL PROTECTED]> Never organized
Re: [Qemu-devel] [PATCH] Fix NaN handling in softfloat
J. Mayer a écrit : > On Thu, 2007-11-08 at 00:05 +0100, Aurelien Jarno wrote: >> On Tue, Nov 06, 2007 at 09:01:13PM +0100, J. Mayer wrote: >>> On Sat, 2007-11-03 at 22:28 +0100, Aurelien Jarno wrote: On Sat, Nov 03, 2007 at 02:06:04PM -0400, Daniel Jacobowitz wrote: > On Sat, Nov 03, 2007 at 06:35:48PM +0100, Aurelien Jarno wrote: >> Hi all, >> >> The current softfloat implementation changes qNaN into sNaN when >> converting between formats, for no reason. The attached patch fixes >> that. It also fixes an off-by-one in the extended double precision >> format (aka floatx80), the mantissa is 64-bit long and not 63-bit >> long. >> >> With this patch applied all the glibc 2.7 floating point tests >> are successfull on MIPS and MIPSEL. > FYI, I posted a similar patch and haven't had time to get back to it. > Andreas reminded me that we need to make sure at least one mantissa > bit is set. If we're confident that the common NaN format will > already have some bit other than the qnan/snan bit set, this is fine; > otherwise, we might want to forcibly set some other mantissa bit. > Please find an updated patch below. I have tried to match real x86, MIPS, HPPA, PowerPC and SPARC hardware when all mantissa bits are cleared. >>> It's a good idea to fix NaN problems here but in my opinion, it's a bad >>> idea to have target dependant code here. This code should implement IEEE >>> behavior. Target specific behavior / deviations from the norm has to be >> Has Thiemo already said, there is no IEEE behavior. If you look at the >> IEEE 754 document you will see that it has requirements on what should >> be supported by an IEEE compliant FPU, but has very few requirements on >> the implementation. >> > > OK. > >>> implemented in target specific code. As targets have to check the >>> presence of a NaN to update the FP flags, it seems that uglyifying this >>> code with target specific hacks is pointless. If the target code do not >>> check the presence of a NaN, that means that it does not implement >>> precise FPU emulation, then there's no need to have specific code to >>> return a precise value (I mean target dependant) from the generic code, >>> imho. >> I actually know very few CPU that check for NaN in general. They check >> for sNaN as required by IEEE 754, but rarely for qNaN as their purpose >> is exactly to be propagated through all FPU operations as a normal FP >> number would be. > > CPU do check QNaNs because most of them update a specific flag that can > be checked to know there was a NaN seen during FPU operations. I don't > know for all FPU, but I can see that the PowerPC gives me 4 bits that > give the class of the last FPU result and I guess you have those kind of > flags in most implementations. This is not the case of MIPS for example. >> Anyway there is no way to do that in the target specific code *after >> the conversion*, as the detection of a mantissa being nul when >> converting from double to single precision can only be done when both >> values are still known. In other words when the value is not fixed >> during the conversion, the value 0x7f80 can either be infinity or a >> conversion of NaN from double to single precision, and thus is it not >> possible to fix the value afterwards in the target specific code. > > I don't say you have to return an infinity when the argument is a qNaN. > I just say you have to return a qNaN in a generic way. Just return sign > | 0x7f80 | mantissa, which is the more generic form and seems to me > to even be OK for sNaNs. It's even needed for some target (not to say 0x7f80 is actually not a NaN, but infinity. > PowerPC) that specify that the result have to be equal to the operand > (in the single precision format, of course) in such a case. This is > simpler, it ensures that any target could then detect the presence of a > NaN, know which one, and can then adjust the value according to its > specification if needed. > I then still can'tl see any reason of having target specific code in > that area. Ok, let's give an example then. On MIPS let's say you want to convert 0x7ff1 (qNaN) to single precision. The mantissa shifted to the right become 0, so you have to generate a new value. As you proposed, let's generate a "generic value" 0x7fc0 in the softfloat routines. This value has to be converted to 0x7fbf in the MIPS target code. However, that doesn't work because 0x7ff8 (sNaN) will also be converted to 0x7fc0 in the softfloat routines. The MIPS target code will convert that into 0x7bff, which is wrong because it is a qNaN, and because the mantissa has been changed while it should have not. In short this is not possible to fix a value while it is already converted to single precision, because all the possible 2^32 values have a signification. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Deb
[Qemu-devel] qemu/target-sparc translate.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl 07/11/10 09:32:02 Modified files: target-sparc : translate.c Log message: More Sparc64 CPU definitions CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?cvsroot=qemu&r1=1.80&r2=1.81
