From cbebc11359ebe793ba9cd50e42a98afda0c77d99 Mon Sep 17 00:00:00 2001 From: sewardj Date: Mon, 4 Feb 2002 10:48:11 +0000 Subject: [PATCH] [project @ 2002-02-04 10:48:11 by sewardj] Clarify explaination about problems with x87 FPU stack invalid exceptions. --- ghc/docs/comm/the-beast/ncg.html | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/ghc/docs/comm/the-beast/ncg.html b/ghc/docs/comm/the-beast/ncg.html index 2b2d2fc..9a8d55f 100644 --- a/ghc/docs/comm/the-beast/ncg.html +++ b/ghc/docs/comm/the-beast/ncg.html @@ -616,16 +616,19 @@ There are, however, two unforeseen bad side effects:
  • This doesn't work properly, because it doesn't observe the normal conventions for x86 FP code generation. It turns out that each of the 8 elements in the x86 FP register stack has a tag bit which - indicates whether or not that slot contains a valid value. If you - do a FPU operation which happens to read such a value, you get a - x87 FPU exception, which is normally handled by the FPU without - passing it to the OS: the program keeps going, but the resulting - FP values are garbage. (The OS can ask for the FPU to pass it FP - stack-invalid exceptions, but it usually doesn't). + indicates whether or not that register is notionally in use or + not. If you do a FPU operation which happens to read a + tagged-as-empty register, you get an x87 FPU (stack invalid) + exception, which is normally handled by the FPU without passing it + to the OS: the program keeps going, but the resulting FP values + are garbage. The OS can ask for the FPU to pass it FP + stack-invalid exceptions, but it usually doesn't.

    - Anyways: inside NCG created x86 FP code this all works fine, but - when control returns to a gcc-generated world, the stack tag bits - soon cause stack exceptions, and thus garbage results. + Anyways: inside NCG created x86 FP code this all works fine. + However, the NCG's fiction of a flat register set does not operate + the x87 register stack in the required stack-like way. When + control returns to a gcc-generated world, the stack tag bits soon + cause stack exceptions, and thus garbage results.

    The only fix I could think of -- and it is horrible -- is to clear all the tag bits just before the next STG-level entry, in chunks -- 1.7.10.4