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: Sat, 05 Jul 2025 08:49:22 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 83
Message-ID: <2025Jul5.104922@mips.complang.tuwien.ac.at>
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>
Injection-Date: Sat, 05 Jul 2025 11:15:12 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="696d5a79ccd3df213f570816791679c9";
	logging-data="1471797"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+PQbXVmfZibKY6XL8Oewv1"
Cancel-Lock: sha1:z/DVzpedzSUWmhcqtKPbbwS4vLE=
X-newsreader: xrn 10.11

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.

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.

One interesting aspect is that VFX 5.x finally includes an FP package
by default, and it started by including an SSE2-based FP package which
supports a deep FP stack.  However, MPE received customer complaints
about the lower number of significant digits in SSE2 (binary64)
vs. 387 (80-bit FP values), so they switched the default to the
387-based FP package that only has 8 FP stack items.  Apparently no
MPE customer complains about that limitation.

OTOH, iForth-5.1-mini uses the 387 instructions, but stores FP stack
items in memory at least on call boundaries.  Maybe Marcel Hendrix can
give some insight into what made him take this additional
implementation effort.


FORTH> : foo f+ f* ;  ok
FORTH> : bar f@ f@ f@ execute f! ;   ok
FORTH> ' foo idis 
$10226000  : foo                        488BC04883ED088F4500      H.@H.m..E.
$1022600A  fld           [r13 0 +] tbyte41DB6D00                  A[m.
$1022600E  fld           [r13 #16 +] tbyte
                                        41DB6D10                  A[m.
$10226012  fxch          ST(2)          D9CA                      YJ
$10226014  lea           r13, [r13 #32 +] qword
                                        4D8D6D20                  M.m 
$10226018  faddp         ST(1), ST      DEC1                      ^A
$1022601A  fxch          ST(1)          D9C9                      YI
$1022601C  fpopswap,                    41DB6D00D9CA4D8D6D10      A[m.YJM.m.
$10226026  fmulp         ST(1), ST      DEC9                      ^I
$10226028  fpush,                       4D8D6DF0D9C941DB7D00      M.mpYIA[}.
$10226032  ;                            488B45004883C508FFE0      H.E.H.E..` ok
FORTH> ' bar idis 
$10226080  : bar                        488BC04883ED088F4500      H.@H.m..E.
$1022608A  pop           rbx            5B                        [
$1022608B  fld           [rbx] tbyte    DB2B                      [+
$1022608D  pop           rbx            5B                        [
$1022608E  fld           [rbx] tbyte    DB2B                      [+
$10226090  pop           rbx            5B                        [
$10226091  fld           [rbx] tbyte    DB2B                      [+
$10226093  lea           r13, [r13 #-48 +] qword
                                        4D8D6DD0                  M.mP
$10226097  fxch          ST(3)          D9CB                      YK
$10226099  fstp          [r13 #32 +] tbyte
                                        41DB7D20                  A[} 
$1022609D  fstp          [r13 0 +] tbyte41DB7D00                  A[}.
$102260A1  fstp          [r13 #16 +] tbyte
                                        41DB7D10                  A[}.
$102260A5  pop           rbx            5B                        [
$102260A6  or            rbx, rbx       4809DB                    H.[
$102260A9  je            $102260B1 offset NEAR 
                                        0F8402000000              ......
$102260AF  call          rbx            FFD3                      .S
$102260B1  pop           rbx            5B                        [
$102260B2  fpop,                        41DB6D00D9C94D8D6D10      A[m.YIM.m.
$102260BC  fstp          [rbx] tbyte    DB3B                      [;
$102260BE  ;                            488B45004883C508FFE0      H.E.H.E..` ok

- 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/