From: Bart Oldeman <bartoldeman@users.sourceforge.net>
To: Stas Sergeev <stsp@aknet.ru>
Cc: dosemu <linux-msdos@vger.kernel.org>
Subject: Re: freezes when not emulating CPU (was: MIDI input patch)
Date: Mon, 14 Sep 2009 09:05:25 -0400 [thread overview]
Message-ID: <c3d607cc0909140605u476f26c9s41fc22ad38ecd3c7@mail.gmail.com> (raw)
In-Reply-To: <4AAA2D35.3040309@aknet.ru>
Hello Stas,
> Which means that the comment in
> do_vm86.c about fnsave is wrong, and the
> code that restores the dosemu FPU state
> should likely to be returned. You can,
> for example, memset the vm86_fpu_state
> to 0 in fpu_reset() and see the SIGFPE
> coming from all around the sound code
> (no other code use FPU in dosemu).
I've been looking at this. The SIGFPEs don't happen for i386 (default
FP), only for x86-64 or when explicitly compiling with SSE floating
point (using gcc -msse2 -mfpmath=sse). The "fnsave" instruction really
re-initializes the FPU (it's documented), but with SSE one needs to
use "fxsave" and "fninit", and that still doesn't reinitialize the
SIMD part. Adding an "ldmxcsr" instruction solved that problem.
I still think that a simple FPU environment reset is sufficient, no
need to restore all the registers, because the DOSEMU FPU code is not
interrupted by DOS code.
The fpu save/restore operations aren't cheap, so perhaps one could
only use them around the sound code instead of for every vm86 call.
Though that could be messy.
> Also, I found no docs about this FPU
> init/reset stuff, so everything in this
> patch is just a wild guesses based on
> a look into a bochs code.
> Also, there is a need to add the handling
> for exception 0x13 (SIMD FPE), which is
> what the SIGFPE is about today. I mean,
> at least print_exception_info() should
> write something meaningfull about SIGFPE
> instead of "Unknown exception".
I've done that now.
Bart
next prev parent reply other threads:[~2009-09-14 13:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-11 10:57 freezes when not emulating CPU (was: MIDI input patch) Stas Sergeev
2009-09-14 13:05 ` Bart Oldeman [this message]
2009-09-14 15:26 ` freezes when not emulating CPU Stas Sergeev
2009-09-17 20:37 ` Samuel Bronson
2009-09-17 21:05 ` Stas Sergeev
2009-09-18 12:49 ` Bart Oldeman
[not found] ` <AE6CA625AD924972A78210F20D55D7BC@kofowork>
2009-09-18 15:25 ` Bart Oldeman
2009-09-18 15:47 ` Gert Koefoed Andersen
2009-09-18 17:27 ` Gert Koefoed Andersen
2009-09-14 17:02 ` freezes when not emulating CPU (was: MIDI input patch) Frank Cox
-- strict thread matches above, loose matches on Subject: below --
2009-09-11 7:37 x.zupftom
2009-09-09 19:17 x.zupftom
2009-09-11 2:56 ` Bart Oldeman
2009-07-17 13:36 x.zupftom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c3d607cc0909140605u476f26c9s41fc22ad38ecd3c7@mail.gmail.com \
--to=bartoldeman@users.sourceforge.net \
--cc=linux-msdos@vger.kernel.org \
--cc=stsp@aknet.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox