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> <300ba9a1581bea9a01ab85d5d361e6eaeedbf23a@i2pn2.org> <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 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/