hardware float stack corruption

Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
=20

I am seeing hardware float stack in SwiftForth 2.2.2.9 like those =
described
by Gordon Osbourne (below).

I am using a Dell D600 laptop under windows XP. Numeric stack errors =
are
coming up intermettently: sometimes a same code is interrupted by the =
error
and sometimes it isn't. There are no calls to other applications =
involved
(although I don't know what Windows might be doing in the background).

=20

My experience suggests that the hardware stack is especially fragile =
with
respect to the "ok" prompt..

=20

In playing interactively with the float stack in a clean Forth session =
and
loading FPMath.f it appears there is no way to reset the hardware stack
after an error. =20

=20

Entering "PI FDEPTH" over and over, the FDEPTH count increments
normally. After exceeding the hardward stack and prompting a numeric =
stack
error, FDEPTH no longer works reliably. As float value are added FDEPTH
continues to return 1 or zero. 'F.' retuns an error even when there =
should
be values on the hardware stack..

=20

I would have thought the /FTACK would reinitiate the hardware stack and
return it to functionality. Instead it just returns FDEPTH to zero. =
There
is no way to recover except to end the session.

=20

=20

=20

=20

-------------------------------------------------------------------------=

---
--------------------------------
From: Osbourn, Gordon C <
<mailto:gcosbou_at_sandia.gov?Subject=3DRe:%20hardware%20float%20stack%20=
corru
ption> gcosbou_at_sandia.gov>=20
Date: Fri Oct 07 2005 - 10:06:40 PDT
=20
=20
Our small team of scientific Forth programmers has run into problems=20
associated with using the hardware float stack in SwiftForth 2.2.2.9.=20
We see a variety of symptoms, such as the same SwiftForth command giving =
different answers or garbage answers in different executions. The=20
simplest version is to simply put a float value on the stack and hit=20
return, then executing f. produces garbage on one of our systems. We=20
find the root cause, by single-stepping through the assembly code, to be =
that values in the hardware float registers are corrupted upon return=20
from certain SwiftForth system calls, e.g. a call to user32.dll by the=20
"ok" prompt code (that updates the status bar on the SwiftForth window)
----------------------------------------------------------------------
sftalk_at_forth.com      The SwiftForth programming discussion email list
To unsubscribe, send subject "unsubscribe" to sftalk-request_at_forth.com
For list command help, send subject "help" to sftalk-request_at_forth.com
Message archives are located at http://www.forth.com/archive/sftalk
----------------------------------------------------------------------
This list is a forum for SwiftForth users.  For product support and bug
reports, please send email to support_at_forth.com
----------------------------------------------------------------------