public inbox for linux-msdos@vger.kernel.org
 help / color / mirror / Atom feed
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

  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