Re: Parsing timestamps?

dxf <dxforth@gmail.com> writes:

On 5/07/2025 6:49 pm, Anton Ertl wrote:

dxf <dxforth@gmail.com> writes:
[8 stack items on the FP stack]

Puzzling because of a thread here not long ago in which scientific users
appear to suggest the opposite.  Such concerns have apparently been around
a long time:
>
https://groups.google.com/g/comp.lang.forth/c/CApt6AiFkxo/m/wwZmc_Tr1PcJ

 
I have read through the thread.  It's unclear to me which scientific
users you have in mind.  My impression is that 8 stack items was
deemed sufficient by many, and preferable (on 387) for efficiency
reasons.

>
AFAICS both Skip Carter (proponent) and Julian Noble were suggesting the
6 level minimum were inadequate.

Skip Carter did not post in this thread, but given that he proposed
the change, he probably found 6 to be too few; or maybe it was just a
phenomenon that we also see elsewhere as range anxiety.  In any case,
he made no such proposal to Forth-200x, so apparently the need was not
pressing.

Julian Noble ignored the FP stack size issue in his first posting in
this thread, unlike the separate FP stack size issue, which he
supported.  So it seems that he did not care about a larger FP stack
size.  In the other posting he endorsed moving FP stack items to the
data stack, but he did not write why; for all we know he might have
wanted that as a first step for getting the mantissa, exponent and
sign of the FP value as integer (and the other direction for
synthesizing FP numbers from these parts).

AFAIK all major forths supporting x87 hardware
offer software stack options.

Certainly on SwiftForth-4.0 I find no such option, it apparently
proved unnecessary.  The manual mentions fpconfig.f, but no such file
exists in a SwiftForth-4.0 directory in the versions I have installed.

There exists such a file on various SwiftForth-3.x versions, but on
most of our machines SwiftForth-3.x segfaults (I have not investigated
why; it used to work).  Ok, so I found an old system where it does not
segfault, but trying to load FP on that system produced no joy:

[k8:~:118696] sf-3.11.0
SwiftForth i386-Linux 3.11.0 23-Feb-2021
require fpmath File not found

[k8:~:118699] sf-3.11.0 "include /nfs/nfstmp/anton/SwiftForth-3.11.0/lib/options/fpmath.f"
/nfs/nfstmp/anton/SwiftForth-3.11.0/lib/options/fpmath.f
   49: REQUIRES fpconfig >>> File not found

[k8:~:118700] sf-3.11.0 "include /nfs/nfstmp/anton/SwiftForth-3.11.0/lib/options/linux/fpconfig.f include /nfs/nfstmp/anton/SwiftForth-3.11.0/lib/options/fpmath.f"
/nfs/nfstmp/anton/SwiftForth-3.11.0/lib/options/fpmath.f
   49: REQUIRES fpconfig >>> File not found

[k8:~:118702] sf-3.11.0 "include /nfs/nfstmp/anton/SwiftForth-3.11.0/lib/options/linux/fpconfig.f"
 ok
include /nfs/nfstmp/anton/SwiftForth-3.11.0/lib/options/fpmath.f
/nfs/nfstmp/anton/SwiftForth-3.11.0/lib/options/fpmath.f
   49: REQUIRES fpconfig >>> File not found

Certainly, of the two points this thread is about, there was a
Forth200x proposal for standardizing a separate FP stack, and this
proposal was accepted.  There was no proposal for increasing the
minimum size of the FP stack; Forth-2012 still says:
 
|The size of a floating-point stack shall be at least 6 items.

>
Only because nothing further was heard.  What became of the review
Elizabeth announced I've no idea.

The ANS Forth committee gave up after a price increase by the
origanization under whose umbrella they did their work (it's a
Tom-Sawyer-like business model: You work for them, and they charge you
money for that).

Several years later, we started Forth-200x, and we started with
dpANS6/Forth-94, not with whatever the state their revision was in
when they gave up.  Concerning these two issues, the separate FP stack
was proposed and accepted; the larger stack depth was not even
proposed, not by Skip Carter, and not by anyone else.  If you think
that a larger number of guaranteed FP stack items is necessary,
propose it.

The old scheme was simpler and idiot-proof.

Maybe for using a different FP package which is something I have used
only once (IIRC I modified the 387 package to do store and load FP
values in 8 byes, in order to investigate whether that explains a
performance difference).  But thinking about it, no, it was everything
but simple.  I had to find the VFX manual every time, then look up the
name of the FP package (which is named as unmemorizable as possible
without going to random names), then search for that package in the
files on the system, and finally cut and paste the path of that file.

A typical sequence of commands was:

locate -i vfx|grep pdf
xpdf /usr/share/doc/VfxForth/VfxLin.pdf
bg
locate ndp387.fth
locate p387.fth
vfxlin "include /usr/local/VfxLinEval/Lib/x86/Ndp387.fth"

If I want to switch from the default FP package to a different
package, I essentially have to take the same steps, I only have to add
two additional commands before including the FP package; the last
command for including the SSE implementation becomes:

vfx64 "integers remove-FP-pack include /nfs/nfstmp/anton/VfxForth64Lin-5.43/Lib/x64/FPSSE64S.fth"

(A special twist here is that the documentation says that the file is
called FPSSE64.fth (with only 2 S characters), so I needed a few more
locate invocations to find the right one).

If you find the former simple, why not the latter (apart from the
documentation mistake)?

In any case, in almost all cases I use the default FP pack, and here
the VFX-5 and SwiftForth-4 approach is unbeatable in simplicity.
Instead of performing the sequence of commands shown above, I just
start the Forth system, and FP words are ready.

- 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 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/