Sujet : Re: Parsing timestamps?
De : anton (at) *nospam* mips.complang.tuwien.ac.at (Anton Ertl)
Groupes : comp.lang.forthDate : 13. Jul 2025, 10:01:41
Autres entêtes
Organisation : Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID : <2025Jul13.110141@mips.complang.tuwien.ac.at>
References : 1 2 3 4 5 6 7 8 9 10 11
User-Agent : xrn 10.11
dxf <
dxforth@gmail.com> writes:
On 11/07/2025 8:22 pm, Anton Ertl wrote:
The rest of the industry has standardized on binary64 and binary32,
and they prefer bit-equivalent results for ease of testing. So as
soon as SSE2 gave that to them, they flocked to SSE2.
...
>
I wonder how much of this is academic or trend inspired?
Is ease of testing an academic concern or a trend?
AFAICS Forth
clients haven't flocked to it else vendors would have SSE2 offerings at
the same level as their x387 packs.
For Forth, Inc. and MPE AFAIK their respective IA-32 Forth system was
the only one with hardware FP for many years, so there probably was
little pressure from users for bit-identical results with, say, SPARC,
because they did not have a Forth system that ran on SPARC.
And when they did their IA-32 systems, SSE2 did not exist, so of
course they used the 387. Plus, 387 was guaranteed to be available
with Intel's Pentium and AMD's K5, while SSE2 was only available on
the Pentium 4 and the Athlon 64; so for many years there was a good
reason to prefer 387 over SSE2 if you compiled for IA-32. And gcc
generated 387 code to this day if you ask it to produce code for
IA-32. Only with AMD64 SSE2 was guaranteed, and only there gcc
defaults to it if you use float or double. Now SwiftForth and VFX are
only being ported to AMD64 since a relatively short time.
And as long as customers did not ask for bit-identical results to
those on, say, a Raspi, there was little reason to reimplement FP with
SSE2. I wonder if the development of the SSE2 package for VFX was
influenced by the availability of VFX for the Raspi.
These Forth systems also don't do global register allocation or
auto-vectorization, so two other reasons why, e.g., C compilers chose
to use SSE2 on AMD64 (where SSE2 was guaranteed to be available) don't
exist for them.
- anton
-- M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.htmlcomp.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/