Path: nntp.eternal-september.org!news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: dxf <dxforth@gmail.com>
Newsgroups: comp.lang.forth
Subject: Re: Parsing timestamps?
Date: Mon, 7 Jul 2025 13:48:16 +1000
Organization: i2pn2 (i2pn.org)
Message-ID: <3ff110137ebe9798ad69c03ee62e3930e34771ce@i2pn2.org>
References: <1f433fabcb4d053d16cbc098dedc6c370608ac01@i2pn2.org>
 <2025Jul2.172222@mips.complang.tuwien.ac.at>
 <nnd$77366e3c$215e3e20@1580fe9081551b96>
 <300ba9a1581bea9a01ab85d5d361e6eaeedbf23a@i2pn2.org>
 <nnd$619ca290$2bff25f3@fa4b7a265c28888c>
 <4d440297d7e17251ebc50774bacfec73e184f9bc@i2pn2.org>
 <2025Jul5.104922@mips.complang.tuwien.ac.at>
 <6fd9f665e73ad93270fff88eca894ba69424cac7@i2pn2.org>
 <2025Jul6.133027@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 7 Jul 2025 03:48:21 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3709836"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="XPw7UV90Iy7EOhY4YuUXhpdoEf5Vz7K+BsxA/Cx8bVc";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-GB
In-Reply-To: <2025Jul6.133027@mips.complang.tuwien.ac.at>

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.