: Any news on the possible cvs-svn migration?
:
: To be perfectly honest, IMO there is little point moving an existing
: project from CVS to SVN.
:
: I disagree. CVS has several fairly fundamental flaws (no global revision
: IDs, unable to move files, and more subtle problems with
As it is, Fabrice's code generator will most likely be something
similar to Paul's qops, which means that you have to invent a
primitive C in which to write the miniops, and you will have to
write a backend for _each_ and _every_ host CPU you support.
It's not a terribly big deal.
Well, I admit I've invented the term ppc32, but there are dozens of
32-bit PowerPC chips. I'd be amazed if they do 64-bit computations or have
64-bit GPRs.
Indeed not. Valgrind implements the 32-bit PPC user-space instruction set
quite adequately using 32-bit computations throughout. No
Hi Jocelyn
I ran valgrind's ppc32 insn set tests and got the impression that
the above insns are not correctly implemented. It seems like 7 bits
of CR are set to 1 and one is set to 0, when it should be the other
way around. Below is a simple test case. On QEMU it prints
result is 000fc000
way around. Below is a simple test case. On QEMU it prints
result is 000fc000
and on a real 7447
result is 4000
What is strange is that 0xFC + 0x04... I will have to check all the CR
ops, I guess...
Another strange thing is that 000fc000 does not have 'fc'
On Saturday 13 October 2007 16:24, Werner Dittmann wrote:
Bruno Cornec wrote:
On Sat, Oct 13, 2007 at 01:53:37PM +0200, Bruno Cornec wrote:
However, mandriva 2008.0 x86_64 doesn't exhibit this error on the same
host.
I stand corrected. It also crashed but later during the install
Some x86_64 SSE2 instructions that convert floats to ints appear
to ignore the rounding mode (in mxcsr), and so produce wrong results
if mxcsr is set to anything other than default rounding. For example
cvtsd2si et al.
I'm looking at softfloat-native.c and softfloat.c and wondering how
to fix
Unfortunately C99 relaxed this requirement, and allowed abominations like
the win64 ABI.
This means you have a choice: Write standard conforming code (long) that
works on all known systems except win64, or use features that do't exist
on many systems. IIRC C99 types like intptr_t are
Does this fix some specific bug you encountered?
J
On Monday 26 March 2007 14:53, Bernhard Kauer wrote:
The Intel manual states for LTR and 64-Bit Exceptions:
#GP(selector)
If the descriptor type of the upper 8-byte of the 16-byte descriptor
is non-zero.
Qemu currently
As far as X86 is concerned i386/i486/i586 are very different from later
generation
processors. I am wondering whether another host and target architecture
could be
created called i686 that makes use of something like MMX or other
registers in Intel
Pentium II/III/4 and AMD Athlon to negate
On Thursday 22 March 2007 23:27, Paul Brook wrote:
Do you mean you're asking me to break up Paul Brook's QOPS tree at
https://nowt.dyndns.org and submit it to mainline? I can do this thing,
if you really think it would help.
If you implement all the missing bits in the process it'll help
On Thursday 15 March 2007 14:53, Paul Brook wrote:
Subsequent releases of the branch would contain no functionality
enhancements, but just bug fixes, with the eventual aim of achieving
'it just works' status for any x86/x86_64 guest I try to install/run.
I know that's a tall order, and
Note that float64_to_uint64 functions are not correct, as they won't
return results between INT64_MAX and UINT64_MAX. Hope someone may know
the proper solution for this.
How about this?
J
uint64_t float64_to_uint64 (float64 a STATUS_PARAM)
{
uint64_t res;
int64_t v;
if
Thinking about this more, you ask is this correct, but that
is only meaningful if you say what the specification is.
Correct relative to what?
Yes, it seems to be the correct way, but thinking more about the
problem, it appeared to me that the implementation could be even easier
than yours.
The helpers for x86/amd64 fprem and fprem1 in target-i386/helper.c are
significantly borked and, for example, cause konqueror in RedHat8 (x86
guest) to go into an infinite loop when displaying http://news.bbc.co.uk.
helper_fprem has the following borkage:
- various Inf/Nan/zero inputs not
I'm seeing redundant repz (0xF3) prefixes in generated code, typically
just before jumps:
code_gen_buffer+415: repz mov $0xe07f,%eax
code_gen_buffer+421: mov%eax,0x20(%rbp)
code_gen_buffer+424: lea-25168302(%rip),%ebx # 0xaf0420 tbs+96
code_gen_buffer+430: retq
code_gen_buffer+431:
On Friday 16 March 2007 14:28, Paul Brook wrote:
On Friday 16 March 2007 14:15, Julian Seward wrote:
I'm seeing redundant repz (0xF3) prefixes in generated code, typically
just before jumps:
code_gen_buffer+415: repz mov $0xe07f,%eax
code_gen_buffer+421: mov%eax,0x20(%rbp
On Friday 16 March 2007 18:07, Rob Landley wrote:
On Tuesday 13 March 2007 10:21 pm, Julian Seward wrote:
0.9.0, or that the compiler/host combination used to build the qemu
binary Julian is running generated bad code for the float compares.
I used gcc 3.4.6 bootstrapped as normal
I ran QEMU on Valgrind for several hours last night, including a couple
of boot-shutdown cycles of RedHat8, and lots of file copying/deletion
in the guest to get the qcow2 image up to 8GB and generally cause a lot
of disk IO. I got no memory errors whatsoever from Valgrind and got no
filesystem
On Friday 16 March 2007 18:40, Anthony Liguori wrote:
Hi Julian,
Julian Seward wrote:
Here is a somewhat revised version of a patch I first made nearly
three years ago. The original thread is
http://lists.gnu.org/archive/html/qemu-devel/2004-07/msg00263.html
It still uses a shadow
ifeq ($(ARCH),x86_64)
+OP_CFLAGS+= -mtune=nocona -W -Wall -O4
BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
endif
That works. Thanks.
J
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Something similar happened to me. At first I thought it was a hardware
(host) problem and so do not have good details - this is from memory.
- 0.9.0, binary build from qemu.org
- i386 openSUSE 10.2 host
- RedHat 8 guest
- .qcow2 image, max size 8GB
- using the Accelerator but not -kernel-kqemu
I am a great fan of QEMU, and have used it more or less continuously
for the past 2+ years. Over that time I've installed and operated
various Linux and Windows guests with varying degrees of success.
The recently released 0.9.0 seems a big step forward in the
stability/usability department,
On Thursday 15 March 2007 13:48, Anthony Liguori wrote:
I'm not necessarily sure I agree that a stable branch is the best thing
to have (verses aiming for never introducing regressions).
Aiming for no regressions is a worthy aim, but I believe unachieveable
in a project of any size. For sure
On Wednesday 14 March 2007 04:57, Mark Williamson wrote:
Here is a somewhat revised version of a patch I first made nearly
three years ago. The original thread is
The idea here is quite similar to what the VNC server does now.
If this is desirable for SDL too, then perhaps we should
QEMU and Core 2 Duo disagree on the handling of NaNs it seems.
http://courses.ece.uiuc.edu/ece390/books/labmanual/inst-ref-simd.html
- this implies that MAXPS should leave the NaNs alone, no idea how
normative that is though (and no IA32 manual at hand)
Having looked at an IA32 manual I'd
Here is a somewhat revised version of a patch I first made nearly
three years ago. The original thread is
http://lists.gnu.org/archive/html/qemu-devel/2004-07/msg00263.html
The patch makes QEMU's graphics emulation much more usable over remote
X connections, by reducing the amount of data
0.9.0, or that the compiler/host combination used to build the qemu
binary Julian is running generated bad code for the float compares.
I used gcc 3.4.6 bootstrapped as normal ('make bootstrap; make install')
on a 64-bit machine. If it is qemu generating bad code due to variations
in gcc
The program below tests the 'maxps' instruction. When run on
qemu-0.9.0, host amd64, guest x86, guest OS redhat8, it prints:
f9a511d1 8d37d67f b34825b8 e2f40739
scp the binary to a Core 2 (real) machine and run:
f9a511d1 22dcb9b9 b34825b8 e2f40739
Second 32-bit word is completely
Thanks for the feedback. Since I do not wish to be involved in a
great battle (as you so nicely put it) I'll stick with VMware (sigh).
J
On Wednesday 21 February 2007 15:05, Robin Atwood wrote:
On Wednesday 21 Feb 2007, Julian Seward wrote:
(replying off list)
So you have Solaris 10
On Saturday 16 December 2006 21:11, Anthony Liguori wrote:
info block is impossible to parse reliably because there is no escaping
done on the filename.
Don't you also need to convert \ to \\ ? Else any \ which was in
the original string will confuse the parser of the escaped output.
J
Really? My win2k install couldn't do anything useful with -std-vga.
It would only do the very basic 640x480x4 mode. I'm fairly sure win9x
can't do anything useful with straight VGA either.
Same here. Also std-vga seemed to be slower than cirrus when I tried
it recently on my linux
It appears that cvttps2dq is indeed the only exception in the range,
combined patch that fixes both movd?q2d?q and cvttps2dq is attached.
I don't have any kind of SSE on this machine so would apprecaite if
someone would run tests/test-i386 with the patch attached.
That works for me.
The SSE2 instructions cvttps2dq, movdq2q, movq2dq do not behave
correctly, as shown by the attached program. It should print
cvttps2dq_1 ... ok
cvttps2dq_2 ... ok
movdq2q_1 ... ok
movq2dq_1 ... ok
but instead produces
cvttps2dq_1 ... ok
cvttps2dq_2 ... not ok
result0.sd[0] =
On Tuesday 20 June 2006 12:29, malc wrote:
The signature of movdq2q is Pq, VRq and for movq2dq - Vo, PRq it appears
that translate.c gets it backwards, attached patch should deal with it.
Cool.
As for cvttps2dq i ran it with interpreter which uses outdated(i.e. non
soft-float) conversion
[EMAIL PROTECTED] qemu]$ gcc -msse2 sse2test.c -o sse2test
[EMAIL PROTECTED] qemu]$ ./sse2test
cvttps2dq_1 ... failed
cvttps2dq_2 ... failed
movdq2q_1 ... failed
movq2dq_1 ... failed
what am i doing wrong here ?
Running it on a CPU without SSE2, if i'm allowed to venture a gues.
Malc, your sse-movq.patch works for me. Thanks.
soft-float was a red herring, translate.c is at fault here (interpreter
does not use it, hence behaved correctly)
translate.c:3009
if (b1 = 2 ((b = 0x50 b = 0x5f) ||
b == 0xc2)) {
/* specific case for SSE single
I've been doing some instruction set testing on i386-softmmu,
with the aim of seeing if I can find any anomalies which might
be the cause the of Win2K SP4 installation failure.
helper_fxam_ST0 doesn't correctly distinguish infinities from
nans, and thereby causes programs that use the x86
On Saturday 17 June 2006 18:03, Rick Vernam wrote:
On Saturday 17 June 2006 11:32, Alex wrote:
This patch has been around for a while but never committed to the
mainstream.
Huh? Fabrice committed it some time around Tuesday. I've been
using it 8+ hours/day since then and it seems fine to
On Thursday 15 June 2006 14:18, WaxDragon wrote:
On 6/15/06, kadil [EMAIL PROTECTED] wrote:
On Wed, 2006-06-14 at 18:10 +0200, Oliver Gerlich wrote:
Real world, gui's are just so easy desirable, especially if the gui is
consistent across os's, and part of the original distro. I think
Could somebody please commit, or at least consider committing,
Anthony Liguori's invisible wall patch, shown at
http://lists.gnu.org/archive/html/qemu-devel/2006-05/msg00112.html ?
Without it, QEMU is essentially unusable on my SuSE 10 host; with it,
the mouse stuff works perfectly. A couple
On Wednesday 07 June 2006 12:49, Julian Seward wrote:
On Wednesday 07 June 2006 02:31, Ben Taylor wrote:
I've been able to get 1152x864 out of the Solaris Xorg gdm5446 driver
so there must be something else that's causing you problems. I think
I've gotten win98se to do it as well
On Wednesday 07 June 2006 02:31, Ben Taylor wrote:
I've been able to get 1152x864 out of the Solaris Xorg gdm5446 driver
so there must be something else that's causing you problems. I think I've
gotten win98se to do it as well.
Thanks for the confirmation. So, I re-tried (extensively) to
autodetect what color format to use. Also putting if inside the inner loop
of the low-level conversion routines is a bad idea.
While that's per-se true, maybe it's not such a big deal. The branch is
going to be perfectly predictable since the condition stays the same
for the entire run, so
-if ((T0 31) ^ (T1 31) ^ (tmp 31)) {
+if (((tmp ^ T1 ^ (-1)) (T0 ^ T1)) 31) {
+ /* operands of same sign, result different sign */
CALL_FROM_TB1(do_raise_exception_direct, EXCP_OVERFLOW);
}
I see this went in, but - huh? The math doesn't make sense.
Recently I've been playing with CVS qemu-system (softmmu) on amd64
and had some stability problems. I decided to run Valgrind's amd64
instruction-set tests (derived from qemu's) to see if they picked up
anything. Resulting diffs are attached.
There are a bunch of differences for the C flag for
I guess the problem comes from the usage of lrintl() on x86_64 in
fpu/softfloat-native.c, but I cannot test it yet.
It might be that you have to pass in an extra value into those
float - int conversion routines, which describes what to do if the
conversion is going to overflow. That's because
Using qemu from cvs simulating x86-softmmu (no kqemu) on x86,
booting SuSE 9.1 and getting to the xdm (kdm?) graphical login
screen, requires making about 1088000 translations, and the
translation cache is flushed 17 times. Booting is not too bad,
but once user-mode starts to run the translation
Basically, if u want split images to be supported in qemu, speak up now.
;)
I speak!
Me too! I've always used split images with vmware; they are
easier to manage than files tens of gigabytes long.
J
___
Qemu-devel mailing list
What are the prospects for qemu-system-ppc being improved to the
point where I can do a vanilla install of popular ppc32-linux
distros?
I've tried a vanilla install of Debian Sarge (3.1). That went
smoothly, except for the stage right at the end, where the disk
image is made bootable. The
it, if someone could test this patch and/or give me links to programs
(Linux/Win98) that use SSE3 instructions (and preferably also prove
Valgrind (current svn trunk) has some pretty extensive SSE/SSE2 tests;
you could use those.
J
___
Qemu-devel
The use of gcc to generate the back end in QEMU's early days was a
clever way to get the project up and running quickly. But surely
now it would be better to transition to a handwritten backend, so
as to be independent future changes in gcc, and generally more robust?
J
On Wednesday 09
52 matches
Mail list logo
