Re: Parsing timestamps?

On 6/07/2025 9:30 pm, Anton Ertl wrote:

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).

He appears to dislike the idea of standard-imposed minimums (e.g. Carter's
suggestion of 16) but suggested:

  a) the user can offload to memory if necessary from
  fpu hardware;

  b) an ANS FLOATING and FLOATING EXT wordset includes
  the necessary hooks to extend the fp stack.

AFAICS the above are in direct response to hardware-imposed minimums.

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:
...

Did you report the issues?  SwiftForth for Linux was a late addition.
AFAIK SwiftForth 4 isn't officially released.  How the Windows and
Linux versions may vary, I've no idea.

...
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)?

Because the fp (in Win at least) is located in the midst of the dictionary
and that has consequences.  The other thing is choice.  Why embed an fp
package not everyone will necessarily like?  AFAICS the 387 hw stack
limitation is definitely something some folks would rather not deal with.
The only reason for embedding an fp is when the user can't load the fp
of their choice and save the result.  An example would be a trial product
in which save is disabled.

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.

When doing devel work with VFX fp some years back I really appreciated
the ease with which I could just 'include' the various fp packages of
my choice without fear of something going wrong.  SwiftForth was a bit
tricky in this regard as there was one file with multiple settings and
this sometimes caused grief.  IMO separate fp files are the way to go.