Marcel Hendrix schrieb am Mittwoch, 20. Juli 2022 um 21:11:31 UTC+2:
> On Wednesday, July 20, 2022 at 6:21:04 PM UTC+2, minf...@arcor.de wrote:
> > Anton Ertl schrieb am Mittwoch, 20. Juli 2022 um 13:53:06 UTC+2:
> [..]
> > How can this be qustioned??
> > Branch cuts are an important thing eg in the field of trigonometric and
> > logarithmic functions, particularly in the complex plane.
> > +0e FDUP FLN f. f. -inf +0.
> > -0e FDUP FLN f. -nan -0.
> > The only thing that is undefined is the 'sign' of nan. The signs before 0.
> > are important.
> You had me worried for a moment but it isn't as simple as that :--)
>
> MATLAB:
> >> log(-0)
> ans = -Inf
> >> log(+0)
> ans = -Inf

Everyone is free and happy to cook her own soup ;-)

Wolfram Alpha does:
log(0.0) or log(-0.0) --> undefined, whereas
log(0+0i) -> -inf, whereas
log(0.0+0.0i) -> undefined

On Thursday, July 21, 2022 at 4:37:24 PM UTC+2, minf...@arcor.de wrote:
> Marcel Hendrix schrieb am Mittwoch, 20. Juli 2022 um 21:11:31 UTC+2:
[..]
> > MATLAB:
> > >> log(-0)
> > ans = -Inf
> > >> log(+0)
> > ans = -Inf
> Everyone is free and happy to cook her own soup ;-)
>
> Wolfram Alpha does:
> log(0.0) or log(-0.0) --> undefined, whereas
> log(0+0i) -> -inf, whereas
> log(0.0+0.0i) -> undefined

Soup? More like a bitches' brew.

-marcel

On 21/07/2022 05:11, Marcel Hendrix wrote:
> On Wednesday, July 20, 2022 at 6:21:04 PM UTC+2, minf...@arcor.de wrote:
>> Anton Ertl schrieb am Mittwoch, 20. Juli 2022 um 13:53:06 UTC+2:
> [..]
>> How can this be qustioned??
>> Branch cuts are an important thing eg in the field of trigonometric and
>> logarithmic functions, particularly in the complex plane.
>> +0e FDUP FLN f. f. -inf +0.
>> -0e FDUP FLN f. -nan -0.
>> The only thing that is undefined is the 'sign' of nan. The signs before 0.
>> are important.
>
> You had me worried for a moment but it isn't as simple as that :--)
>
> MATLAB:
>>> log(-0)
> ans = -Inf
>>> log(+0)
> ans = -Inf

VFX:
0e fln f. -NaN ok

DX-Forth:
0e fln f. -INF ok

As both use the same x87 instructions I'm guessing it's something
to do with NAN/INF decoding.

On Friday, July 22, 2022 at 4:38:04 AM UTC+2, dxforth wrote:
> On 21/07/2022 05:11, Marcel Hendrix wrote:
> > On Wednesday, July 20, 2022 at 6:21:04 PM UTC+2, minf...@arcor.de wrote:
> >> Anton Ertl schrieb am Mittwoch, 20. Juli 2022 um 13:53:06 UTC+2:
> > [..]
> >> How can this be qustioned??
> >> Branch cuts are an important thing eg in the field of trigonometric and
> >> logarithmic functions, particularly in the complex plane.
> >> +0e FDUP FLN f. f. -inf +0.
> >> -0e FDUP FLN f. -nan -0.
> >> The only thing that is undefined is the 'sign' of nan. The signs before 0.
> >> are important.
> >
> > You had me worried for a moment but it isn't as simple as that :--)
> >
> > MATLAB:
> >>> log(-0)
> > ans = -Inf
> >>> log(+0)
> > ans = -Inf
> VFX:
> 0e fln f. -NaN ok
>
> DX-Forth:
> 0e fln f. -INF ok
>
> As both use the same x87 instructions I'm guessing it's something
> to do with NAN/INF decoding.

Why Inf? What about this classic:

FORTH> +0e fdup fsin fswap f/ f. -NAN ok
FORTH> +0e fdup fcos fswap f/ f. +INF ok
FORTH> -0e fdup fcos fswap f/ f. -INF ok
FORTH> 0e fdup fcos fswap f/ f. +INF ok

-marcel

dxforth <dxforth@gmail.com> writes:
>VFX:
>0e fln f. -NaN ok

VFX Forth for Linux IA32 Version: 4.72 [build 0555]
Including /usr/local/VfxLinEval/Lib/x86/Ndp387.fth
0e fln f. -Inf ok
NDP Potential Exception: NDP SW = 0004

VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
© MicroProcessor Engineering Ltd, 1998-2021

0e fln f. Invalid argument to FLN/FLOG
-> 0e fln f.
^

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: http://www.euroforth.org/ef22/cfp.html

On 22/07/2022 15:16, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>VFX:
>>0e fln f. -NaN ok
>
> VFX Forth for Linux IA32 Version: 4.72 [build 0555]
> Including /usr/local/VfxLinEval/Lib/x86/Ndp387.fth
> 0e fln f. -Inf ok
> NDP Potential Exception: NDP SW = 0004
>
> VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
> © MicroProcessor Engineering Ltd, 1998-2021
>
> 0e fln f. Invalid argument to FLN/FLOG
> -> 0e fln f.
> ^

Looks likes 32->64 conversion issues (for Win x64 anyway).
I've sent Stephen an email and mentioned your result.

On 22/07/2022 15:05, Marcel Hendrix wrote:
> On Friday, July 22, 2022 at 4:38:04 AM UTC+2, dxforth wrote:
>> On 21/07/2022 05:11, Marcel Hendrix wrote:
>> > On Wednesday, July 20, 2022 at 6:21:04 PM UTC+2, minf...@arcor.de wrote:
>> >> Anton Ertl schrieb am Mittwoch, 20. Juli 2022 um 13:53:06 UTC+2:
>> > [..]
>> >> How can this be qustioned??
>> >> Branch cuts are an important thing eg in the field of trigonometric and
>> >> logarithmic functions, particularly in the complex plane.
>> >> +0e FDUP FLN f. f. -inf +0.
>> >> -0e FDUP FLN f. -nan -0.
>> >> The only thing that is undefined is the 'sign' of nan. The signs before 0.
>> >> are important.
>> >
>> > You had me worried for a moment but it isn't as simple as that :--)
>> >
>> > MATLAB:
>> >>> log(-0)
>> > ans = -Inf
>> >>> log(+0)
>> > ans = -Inf
>> VFX:
>> 0e fln f. -NaN ok
>>
>> DX-Forth:
>> 0e fln f. -INF ok
>>
>> As both use the same x87 instructions I'm guessing it's something
>> to do with NAN/INF decoding.
>
> Why Inf? What about this classic:
>
> FORTH> +0e fdup fsin fswap f/ f. -NAN ok
> FORTH> +0e fdup fcos fswap f/ f. +INF ok
> FORTH> -0e fdup fcos fswap f/ f. -INF ok
> FORTH> 0e fdup fcos fswap f/ f. +INF ok

After applying a fix to VFX64 I get those, in addition to 0e FLN working
as expected. Why is it classic?

On 22/07/2022 15:16, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>VFX:
>>0e fln f. -NaN ok
>
> VFX Forth for Linux IA32 Version: 4.72 [build 0555]
> Including /usr/local/VfxLinEval/Lib/x86/Ndp387.fth
> 0e fln f. -Inf ok
> NDP Potential Exception: NDP SW = 0004
>
> VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
> © MicroProcessor Engineering Ltd, 1998-2021
>
> 0e fln f. Invalid argument to FLN/FLOG
> -> 0e fln f.
> ^

Stephen advises the fix will be in the next release.

dxforth schrieb am Sonntag, 24. Juli 2022 um 06:31:22 UTC+2:
> On 22/07/2022 15:16, Anton Ertl wrote:
> > dxforth <dxf...@gmail.com> writes:
> >>VFX:
> >>0e fln f. -NaN ok
> >
> > VFX Forth for Linux IA32 Version: 4.72 [build 0555]
> > Including /usr/local/VfxLinEval/Lib/x86/Ndp387.fth
> > 0e fln f. -Inf ok
> > NDP Potential Exception: NDP SW = 0004
> >
> > VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
> > © MicroProcessor Engineering Ltd, 1998-2021
> >
> > 0e fln f. Invalid argument to FLN/FLOG
> > -> 0e fln f.
> > ^
> Stephen advises the fix will be in the next release.

IEEE 754 section 9.2.1 specifies clearly
".. log(±0) is −∞ and signals the divideByZero exception .."

Reference page 43 in
https://irem.univ-reunion.fr/IMG/pdf/ieee-754-2008.pdf

On 7/30/22 07:22, minf...@arcor.de wrote:
> dxforth schrieb am Sonntag, 24. Juli 2022 um 06:31:22 UTC+2:
>> On 22/07/2022 15:16, Anton Ertl wrote:
>>> dxforth <dxf...@gmail.com> writes:
>>>> VFX:
>>>> 0e fln f. -NaN ok
>>>
>>> VFX Forth for Linux IA32 Version: 4.72 [build 0555]
>>> Including /usr/local/VfxLinEval/Lib/x86/Ndp387.fth
>>> 0e fln f. -Inf ok
>>> NDP Potential Exception: NDP SW = 0004
>>>
>>> VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
>>> © MicroProcessor Engineering Ltd, 1998-2021
>>>
>>> 0e fln f. Invalid argument to FLN/FLOG
>>> -> 0e fln f.

>> ^
>> Stephen advises the fix will be in the next release.
>
> IEEE 754 section 9.2.1 specifies clearly
> ".. log(±0) is −∞ and signals the divideByZero exception .."
>
> Reference page 43 in
> https://irem.univ-reunion.fr/IMG/pdf/ieee-754-2008.pdf

The divideByZero exception mask bit must be set in order for the fpu to
signal the exception. It is not set by default.

In kForth-32/64,

\ Check ln(0)
0e f.
0 ok
0e fln f.
-inf ok

\ Check ln(-0)
-0e f.
-0 ok
-0e fln f.
-inf ok

In kForth-32, the FPU's exception mask bit for divideByZero may be set
as follows:

------
include ans-words
include strings
include modules
include syscalls
include mc
include asm-x86
include fpu-x86

cr
..( FLN of zero with default FPU exception mask ) cr

0e fln f. cr

..( Press a key to set the divideByZero FPU exception ) cr
key drop

FPU_CW_ZERODIVIDE FPU_CW_EXCEPTION_MASK modifyFPUStateX86

0e fln f.
------

Output of the above code in kForth-32:
-------
$ kforth32
kForth-32 v 2.4.0 (Build: 2022-06-30)
Copyright (c) 1998--2022 Krishna Myneni
Contributions by: dpw gd mu bk abs tn cmb bg dnw
Provided under the GNU Affero General Public License, v3.0 or later

Ready!
include fpu-signals-test

FLN of zero with default FPU exception mask
-inf
Press a key to set the divideByZero FPU exception
Floating point exception (core dumped)
$ ------

We can, of course, trap the signal in kForth (see sigfpe.4th for an
example of how to trap a signal in kForth).

--
Krishna

Krishna Myneni schrieb am Samstag, 30. Juli 2022 um 18:31:38 UTC+2:
> On 7/30/22 07:22, minf...@arcor.de wrote:
> > dxforth schrieb am Sonntag, 24. Juli 2022 um 06:31:22 UTC+2:
> >> On 22/07/2022 15:16, Anton Ertl wrote:
> >>> dxforth <dxf...@gmail.com> writes:
> >>>> VFX:
> >>>> 0e fln f. -NaN ok
> >>>
> >>> VFX Forth for Linux IA32 Version: 4.72 [build 0555]
> >>> Including /usr/local/VfxLinEval/Lib/x86/Ndp387.fth
> >>> 0e fln f. -Inf ok
> >>> NDP Potential Exception: NDP SW = 0004
> >>>
> >>> VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
> >>> © MicroProcessor Engineering Ltd, 1998-2021
> >>>
> >>> 0e fln f. Invalid argument to FLN/FLOG
> >>> -> 0e fln f.
>
> >> ^
> >> Stephen advises the fix will be in the next release.
> >
> > IEEE 754 section 9.2.1 specifies clearly
> > ".. log(±0) is −∞ and signals the divideByZero exception .."
> >
> > Reference page 43 in
> > https://irem.univ-reunion.fr/IMG/pdf/ieee-754-2008.pdf
> The divideByZero exception mask bit must be set in order for the fpu to
> signal the exception. It is not set by default.
>
> In kForth-32/64,
>
> \ Check ln(0)
> 0e f.
> 0 ok
> 0e fln f.
> -inf ok
>
> \ Check ln(-0)
> -0e f.
> -0 ok
> -0e fln f.
> -inf ok
>
>
> In kForth-32, the FPU's exception mask bit for divideByZero may be set
> as follows:
>
> ------
> include ans-words
> include strings
> include modules
> include syscalls
> include mc
> include asm-x86
> include fpu-x86
>
> cr
> .( FLN of zero with default FPU exception mask ) cr
>
> 0e fln f. cr
>
> .( Press a key to set the divideByZero FPU exception ) cr
> key drop
>
> FPU_CW_ZERODIVIDE FPU_CW_EXCEPTION_MASK modifyFPUStateX86
>
> 0e fln f.
> ------
>
> Output of the above code in kForth-32:
> -------
> $ kforth32
> kForth-32 v 2.4.0 (Build: 2022-06-30)
> Copyright (c) 1998--2022 Krishna Myneni
> Contributions by: dpw gd mu bk abs tn cmb bg dnw
> Provided under the GNU Affero General Public License, v3.0 or later
>
>
> Ready!
> include fpu-signals-test
>
> FLN of zero with default FPU exception mask
> -inf
> Press a key to set the divideByZero FPU exception
> Floating point exception (core dumped)
> $
> ------
>
> We can, of course, trap the signal in kForth (see sigfpe.4th for an
> example of how to trap a signal in kForth).
>

Well done!

BTW I was sometimes wondering about those strange exception codes
54 and 55 in table 9.1 of the standard document. They seem a half-cooked
rudiment and practically useless.

On 7/30/22 12:16, minf...@arcor.de wrote:
> Krishna Myneni schrieb am Samstag, 30. Juli 2022 um 18:31:38 UTC+2:
>> On 7/30/22 07:22, minf...@arcor.de wrote:
>>> dxforth schrieb am Sonntag, 24. Juli 2022 um 06:31:22 UTC+2:
>>>> On 22/07/2022 15:16, Anton Ertl wrote:
>>>>> dxforth <dxf...@gmail.com> writes:
>>>>>> VFX:
>>>>>> 0e fln f. -NaN ok
>>>>>
>>>>> VFX Forth for Linux IA32 Version: 4.72 [build 0555]
>>>>> Including /usr/local/VfxLinEval/Lib/x86/Ndp387.fth
>>>>> 0e fln f. -Inf ok
>>>>> NDP Potential Exception: NDP SW = 0004
>>>>>
>>>>> VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
>>>>> © MicroProcessor Engineering Ltd, 1998-2021
>>>>>
>>>>> 0e fln f. Invalid argument to FLN/FLOG
>>>>> -> 0e fln f.
>>
>>>> ^
>>>> Stephen advises the fix will be in the next release.
>>>
>>> IEEE 754 section 9.2.1 specifies clearly
>>> ".. log(±0) is −∞ and signals the divideByZero exception .."
>>>
>>> Reference page 43 in
>>> https://irem.univ-reunion.fr/IMG/pdf/ieee-754-2008.pdf
>> The divideByZero exception mask bit must be set in order for the fpu to
>> signal the exception. It is not set by default.
>>
>> In kForth-32/64,
>>
>> \ Check ln(0)
>> 0e f.
>> 0 ok
>> 0e fln f.
>> -inf ok
>>
>> \ Check ln(-0)
>> -0e f.
>> -0 ok
>> -0e fln f.
>> -inf ok
>>
>>
>> In kForth-32, the FPU's exception mask bit for divideByZero may be set
>> as follows:
>>
>> ------
>> include ans-words
>> include strings
>> include modules
>> include syscalls
>> include mc
>> include asm-x86
>> include fpu-x86
>>
>> cr
>> .( FLN of zero with default FPU exception mask ) cr
>>
>> 0e fln f. cr
>>
>> .( Press a key to set the divideByZero FPU exception ) cr
>> key drop
>>
>> FPU_CW_ZERODIVIDE FPU_CW_EXCEPTION_MASK modifyFPUStateX86
>>
>> 0e fln f.
>> ------
>>
>> Output of the above code in kForth-32:
>> -------
>> $ kforth32
>> kForth-32 v 2.4.0 (Build: 2022-06-30)
>> Copyright (c) 1998--2022 Krishna Myneni
>> Contributions by: dpw gd mu bk abs tn cmb bg dnw
>> Provided under the GNU Affero General Public License, v3.0 or later
>>
>>
>> Ready!
>> include fpu-signals-test
>>
>> FLN of zero with default FPU exception mask
>> -inf
>> Press a key to set the divideByZero FPU exception
>> Floating point exception (core dumped)
>> $
>> ------
>>
>> We can, of course, trap the signal in kForth (see sigfpe.4th for an
>> example of how to trap a signal in kForth).
>>
>
> Well done!
>
> BTW I was sometimes wondering about those strange exception codes
> 54 and 55 in table 9.1 of the standard document. They seem a half-cooked
> rudiment and practically useless.
>

Since Forth 2012 doesn't mandate IEEE floating point arithmetic, error
codes 54 and 55 are not specific to IEEE arithmetic specs. My guess is
that they were intended for use by processors which can provide
interrupts on such generic errors. The floating point arithmetic
exceptions which can be enabled on the x86 fpus are

INVALID
DENORMAL
ZERODIVIDE
OVERFLOW
UNDERFLOW
INEXACT

All of these, except DENORMAL, map to the IEEE standard arithmetic
exceptions. From the IEEE Std 754-2008 document,

7.2 Invalid Operation
7.3 Division by zero
7.4 Overflow
7.5 Underflow
7.6 Inexact

With regard to Table 9.1 of the Forth-94 and 2012 standards, exception
code -54 can be thrown for an x86 fpu UNDERFLOW (7.5) error. I'm not
entirely sure about when to throw exception code -55.

Note that the standard also provides the following floating point error
codes:

-41 loss of precision (I assume this is floating point?)
-42 floating-point divide by zero
-43 floating-point result out of range
-46 floating-point invalid argument

It would be good to have common practice for mapping the x86 fpu
exceptions to the standard error codes.

--
Krishna

On 7/30/22 11:31, Krishna Myneni wrote:
> On 7/30/22 07:22, minf...@arcor.de wrote:
>> dxforth schrieb am Sonntag, 24. Juli 2022 um 06:31:22 UTC+2:
>>> On 22/07/2022 15:16, Anton Ertl wrote:
>>>> dxforth <dxf...@gmail.com> writes:
>>>>> VFX:
>>>>> 0e fln f. -NaN ok
>>>>
>>>> VFX Forth for Linux IA32 Version: 4.72 [build 0555]
>>>> Including /usr/local/VfxLinEval/Lib/x86/Ndp387.fth
>>>> 0e fln f. -Inf ok
>>>> NDP Potential Exception: NDP SW = 0004
>>>>
>>>> VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
>>>> © MicroProcessor Engineering Ltd, 1998-2021
>>>>
>>>> 0e fln f. Invalid argument to FLN/FLOG
>>>> -> 0e fln f.
>
>>> ^
>>> Stephen advises the fix will be in the next release.
>>
>> IEEE 754 section 9.2.1 specifies clearly
>> ".. log(±0) is −∞ and signals the divideByZero exception .."
>>
>> Reference page 43 in
>> https://irem.univ-reunion.fr/IMG/pdf/ieee-754-2008.pdf
>
> The divideByZero exception mask bit must be set in order for the fpu to
> signal the exception. It is not set by default.
>
> In kForth-32/64,
>
> \ Check ln(0)
> 0e f.
> 0  ok
> 0e fln f.
> -inf  ok
>
> \ Check ln(-0)
> -0e f.
> -0  ok
> -0e fln f.
> -inf  ok
>
>
> In kForth-32, the FPU's exception mask bit for divideByZero may be set
> as follows:
>
> ------
> include ans-words
> include strings
> include modules
> include syscalls
> include mc
> include asm-x86
> include fpu-x86
>
> cr
> .( FLN of zero with default FPU exception mask ) cr
>
> 0e fln f. cr
>
> .( Press a key to set the divideByZero FPU exception ) cr
> key drop
>
> FPU_CW_ZERODIVIDE FPU_CW_EXCEPTION_MASK modifyFPUStateX86
>

The above line of code,

FPU_CW_ZERODIVIDE FPU_CW_EXCEPTION_MASK modifyFPUStateX86

is actually masking the divideByZero exception, rather than enabling it.
The program generates an exception for the odd reason that when I loaded
the strings.4th module, the fpu status register indicates an INVALID
error, caused by the following statement in strings.4th

0e 0e f/ fconstant NAN

used to define NAN for the word STRING>F .

The code is not generating an exception for the reason I thought. I
noticed this because strings.4th is not needed by any of the code, but
if I omit it, the code fails to generate an exception.

The fpu-x86.4th file permits examining the status and control registers
of the fpu as follows:

getFPUStatusX86 fpu-status ?
getFPUStateX86 fpu-control ?

Also, the word ClearFPUexceptionsX86 clears the fpu status register.

Bottom line is the code I intended to enable an exception on the fpu
divide by zero error is not correct, and only generates an exception due
to a leftover status error from somewhere else in the code. The word
modifyFPUStateX86 may be faulty.

Stay tuned.

--
KM

On 31/07/2022 14:02, Krishna Myneni wrote:
>
> FPU_CW_ZERODIVIDE FPU_CW_EXCEPTION_MASK modifyFPUStateX86
>
> is actually masking the divideByZero exception, rather than enabling it.
> The program generates an exception for the odd reason that when I loaded
> the strings.4th module, the fpu status register indicates an INVALID
> error, caused by the following statement in strings.4th
>
> 0e 0e f/ fconstant NAN
>
> used to define NAN for the word STRING>F .

The bit patterns for IEEE INF NAN are documented. Load them into PAD and F@

On 7/30/22 23:02, Krishna Myneni wrote:
> On 7/30/22 11:31, Krishna Myneni wrote:
,,,
> FPU_CW_ZERODIVIDE FPU_CW_EXCEPTION_MASK modifyFPUStateX86
>
> is actually masking the divideByZero exception, rather than enabling it.
> The program generates an exception for the odd reason that when I loaded
> the strings.4th module, the fpu status register indicates an INVALID
> error, caused by
....
> Bottom line is the code I intended to enable an exception on the fpu
> divide by zero error is not correct, and only generates an exception due
> to a leftover status error from somewhere else in the code. The word
> modifyFPUStateX86 may be faulty.
...
The word modifyFPUStateX86 works but I used it incorrectly. The
following code illustrates the working method for unmasking fpu exceptions.

fpu-signals-test.4th
-------
include ans-words
include modules
include syscalls
include mc
include asm-x86
include fpu-x86
include dump
include ssd

: unmaskFPUexceptions ( bits -- )
invert getFPUStateX86 fpu-control @ and
FPU_CW_EXCEPTION_MASK modifyFPUStateX86 ;

cr .( Press a key to mask all FPU exceptions [default] )
cr .( and compute FLN of zero )
cr key drop

0 unmaskFPUexceptions \ mask all exceptions
0e fln f. cr

cr .( Press a key to unmask the divideByZero FPU exception )
cr .( and compute FLN of zero.)
cr key drop

\ Clear current fpu exceptions before unmasking exceptions

clearFPUexceptionsX86

FPU_CW_ZERODIVIDE unmaskFPUexceptions
0e fln f.
--------

Note that I define the word unmaskFPUexceptions which takes a bit
pattern for the exceptions to be unmasked. Several exceptions may be
unmasked by or'ing the mask constants together. Also note that any
pending exceptions in the fpu's status register will immediate signal a
floating point exception if that particular exception is unmasked. If
you don't want that to happen, use clearFPUexceptionsX86 before
executing unmaskFPUexceptions, as illustrated above.

Output of the above code in kforth32 is given below.

------
include fpu-signals-test

Press a key to mask all FPU exceptions [default]
and compute FLN of zero
-inf

Press a key to unmask the divideByZero FPU exception
and compute FLN of zero.
Floating point exception (core dumped)
$ --------

--
Krishna Myneni

On 7/31/22 00:38, dxforth wrote:
> On 31/07/2022 14:02, Krishna Myneni wrote:
>>
>> FPU_CW_ZERODIVIDE FPU_CW_EXCEPTION_MASK modifyFPUStateX86
>>
>> is actually masking the divideByZero exception, rather than enabling it.
>> The program generates an exception for the odd reason that when I loaded
>> the strings.4th module, the fpu status register indicates an INVALID
>> error, caused by the following statement in strings.4th
>>
>> 0e 0e f/ fconstant NAN
>>
>> used to define NAN for the word STRING>F .
>
> The bit patterns for IEEE INF NAN are documented. Load them into PAD and F@
>

Agreed that it's better to load the bit pattern for NAN than to actually
generate exception(s) which are stored in the FPU status register and
can later trigger a floating point exception if the particular
exception(s) are unmasked. The alternative is to clear the FPU status
register after generating the exceptions.

--
Krishna

On 7/31/22 07:30, Krishna Myneni wrote:
> On 7/30/22 23:02, Krishna Myneni wrote:
....
> 0 unmaskFPUexceptions \ mask all exceptions
....

Sigh. I just realized that the above line is bad logic. It does not mask
all fpu exceptions. It has no effect on the mask pattern. Corrected
code, using the definition maskAllFPUexceptions, is given below.

fpu-signals-test.4th
------
include ans-words
include modules
include syscalls
include mc
include asm-x86
include fpu-x86

: maskAllFPUexceptions ( -- )
FPU_CW_INVALID
FPU_CW_DENORMAL or
FPU_CW_ZERODIVIDE or
FPU_CW_OVERFLOW or
FPU_CW_UNDERFLOW or
FPU_CW_INEXACT or
FPU_CW_EXCEPTION_MASK modifyFPUStateX86 ;

: unmaskFPUexceptions ( bits -- )
invert getFPUStateX86 fpu-control @ and
FPU_CW_EXCEPTION_MASK modifyFPUStateX86 ;

cr .( Press a key to mask all FPU exceptions [default] )
cr .( and compute FLN of zero )
cr key drop

maskAllFPUexceptions
0e fln f. cr

cr .( Press a key to unmask the divideByZero FPU exception )
cr .( and compute FLN of zero.)
cr key drop

\ Clear current fpu exceptions before unmasking exceptions

clearFPUexceptionsX86

FPU_CW_ZERODIVIDE unmaskFPUexceptions
0e fln f.
-------

KM