Path: nntp.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: anton@mips.complang.tuwien.ac.at (Anton Ertl) Newsgroups: comp.lang.forth Subject: Re: Parsing timestamps? Date: Sun, 06 Jul 2025 11:30:27 GMT Organization: Institut fuer Computersprachen, Technische Universitaet Wien Lines: 132 Message-ID: <2025Jul6.133027@mips.complang.tuwien.ac.at> References: <1f433fabcb4d053d16cbc098dedc6c370608ac01@i2pn2.org> <2025Jul2.172222@mips.complang.tuwien.ac.at> <300ba9a1581bea9a01ab85d5d361e6eaeedbf23a@i2pn2.org> <4d440297d7e17251ebc50774bacfec73e184f9bc@i2pn2.org> <2025Jul5.104922@mips.complang.tuwien.ac.at> <6fd9f665e73ad93270fff88eca894ba69424cac7@i2pn2.org> Injection-Date: Sun, 06 Jul 2025 15:00:51 +0200 (CEST) Injection-Info: dont-email.me; posting-host="c39846e38dab9db6b5b0c4b029f7f58f"; logging-data="2324766"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19LAvz/AD4KGT9iD4AouNWz" Cancel-Lock: sha1:vO9pNsffKrhg55xlWb2BiTAGCFc= X-newsreader: xrn 10.11 dxf writes: >On 5/07/2025 6:49 pm, Anton Ertl wrote: >> dxf 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/