On 15/04/2024 6:47 pm, Krishna Myneni wrote:
> On 4/14/24 21:07, dxf wrote:
> ...
>> The design criteria that never changed was the 8-level hardware stack.
>> Forthers can either accept it for best performance - or pick something
>> more forgiving at a lesser performance.
>>
>
> In the Lorenz equation example, which works with the 8 deep fpu stack, we have assumed that the fpu hardware stack was empty before calling DERIVS. In a real use case, the call to DERIVS is likely to occur within a deeper call chain, resulting in items already on the fpu stack before args for DERIVS are pushed. As Marcel said, using only a hardware-based fp stack is not realistic for any non-trivial floating point work.
>
> The loss of performance with a memory-based fp stack is far less a concern than having to consider the limited stack depth when writing code involving floating point arithmetic. Failure from overflowing the fpu stack is silent. Debugging is likely to be a nightmare.

Likely the designers never considered Forth. OTOH ANS-Forth did and said
6 items ought to be good enough for anyone :)

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>Failure from overflowing the
>fpu stack is silent.

Reality check:

VFX Forth 64 5.43 [build 0199] 2023-11-09 for Linux x64
© MicroProcessor Engineering Ltd, 1998-2023

1e 2e 3e 4e 5e 6e 7e ok F:-7
8e ok
NDP Stack Fault: NDP SW = 0041
NDP Potential Exception: NDP SW = 0041

SwiftForth also seems to notice it in some way, but does not report it
as an error:

SwiftForth x64-Linux 4.0.0-RC87 24-Mar-2024
1e 2e 3e 4e 5e 6e ok
f. 6.00000000 ok

SwiftForth x64-Linux 4.0.0-RC87 24-Mar-2024
1e 2e 3e 4e 5e 6e 7e ok
f.
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: https://euro.theforth.net/2023

albert@spenarnc.xs4all.nl writes:
>In article <3e419396b1ee93c7a391a7ffc0e44ed8@www.novabbs.com>,
>minforth <minforth@gmx.net> wrote:
>>And if CPU based stacks were so lucrative for high performance,
>>CPU makers would have implemented them since long for normal
>>integer data.

They have: SPARC has a stack of integer register windows, AMD29K and
IA-64 have a register stack of 128 integer registers. However, the
29K died in the early 1990s, IA-64 always remained niche and has been
killed (last order date in January 2020), and SPARC delivered OoO too
late to save it, and the last new SPARC designs were introduced in
2017.

>The iA64 comes to mind. Apparently a failure but was a
>technical or commercial failure?

It was a great commercial success. Several companies killed their
RISCs in favour of IA-64 based just on the IA-64 roadmaps, and when
IA-64 failed to achieve the predicted technical and market
superiority, they switched to Intel's AMD64 CPUs: HP, DEC (bought by
Compaq bought by HP), SGI. Apple switched to Intel's AMD64 CPUs
without the IA-64 step, so maybe it would have happened for the others
as well without IA-64, but maybe one of the others would have done
what ARM and Apple did 15-20 years later.

Technically, IA-64 was a bet on in-order execution with compiler
scheduling being superior to hardware scheduling (out-of-order
execution). That was a bet on the wrong horse, as the superior
hardware branch prediction allows OoO hardware to outperform IA-64 on
branchy code, while SIMD and GPGPUs eat IA-64's lunch on data-parallel
code.

- 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: https://euro.theforth.net/2023

On 4/15/24 09:09, Anton Ertl wrote:
> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>> Failure from overflowing the
>> fpu stack is silent.
>
> Reality check:
>
> VFX Forth 64 5.43 [build 0199] 2023-11-09 for Linux x64
> © MicroProcessor Engineering Ltd, 1998-2023
>
> 1e 2e 3e 4e 5e 6e 7e ok F:-7
> 8e ok
> NDP Stack Fault: NDP SW = 0041
> NDP Potential Exception: NDP SW = 0041
>
> SwiftForth also seems to notice it in some way, but does not report it
> as an error:
>
> SwiftForth x64-Linux 4.0.0-RC87 24-Mar-2024
> 1e 2e 3e 4e 5e 6e ok
> f. 6.00000000 ok
>
> SwiftForth x64-Linux 4.0.0-RC87 24-Mar-2024
> 1e 2e 3e 4e 5e 6e 7e ok
> f.
> ok

I tried overflowing the fpu stack in kforth32, and no exception is
raised. Perhaps one needs to configure the fpu to raise an exception.
Also tried it in C with an assembly procedure. The executable throws no
exception.

--
Krishna

== begin fpu-stack-overflow.4th ==
fpu-stack-overflow.4th
\ for use with kforth32

include ans-words
include strings
include modules
include syscalls
include mc
include asm-x86

code fpu-stack-overflow
fld1,
fld1,
fld1,
fld1,
fld1,
fld1,
fld1,
fld1,
fld1,
end-code

fpu-stack-overflow

== end fpu-stack-overflow.4th ==

== begin example ==
$ kforth32
kForth-32 v 2.4.5 (Build: 2024-03-30)
Copyright (c) 1998--2023 Krishna Myneni
Contributions by: dpw gd mu bk abs tn cmb bg dnw
Provided under the GNU Affero General Public License, v3.0 or later

include fpu-stack-overflow
ok
== end example ==

I would be surprised to get a SIGFPE interrupt from x87 stack ops.
X87 mode has long been deprecated and replaced by SSE2.

On 4/15/24 20:10, minforth wrote:
> I would be surprised to get a SIGFPE interrupt from x87 stack ops.
> X87 mode has long been deprecated and replaced by SSE2.

The FPU has maskable interrupts for arithmetic -- see

https://github.com/mynenik/kForth-32/blob/master/forth-src/fpu-x86.4th

But, yes, I'm not aware of any interrupts from stack ops.

--
Krishna

minforth@gmx.net (minforth) writes:
>X87 mode has long been deprecated

Citation needed.

>and replaced by SSE2.

I just tried compiling the following program with gcc with different
options:

float sfplus(float a, float b)
{ return a+b;
}

double dfplus(double a, double b)
{ return a+b;
}

long double lfplus(long double a, long double b)
{ return a+b;
}

what I got was:

sfplus() dfplus() lfplus()
387 387 387 gcc -m32 -O
SSE2 SSE2 387 gcc -m64 -O
387 387 387 gcc -m64 -mfpmath=387 -O

The System V calling convention for AMD64 passes and returns float and
double in xmm registers, so the last option leads to moving the values
between the xmm register and the 387 FP stack through memory, e.g.:

000000000000001f <dfplus>:
1f: f2 0f 11 44 24 f0 movsd %xmm0,-0x10(%rsp)
25: f2 0f 11 4c 24 f8 movsd %xmm1,-0x8(%rsp)
2b: dd 44 24 f0 fldl -0x10(%rsp)
2f: dc 44 24 f8 faddl -0x8(%rsp)
33: dd 5c 24 f0 fstpl -0x10(%rsp)
37: f2 0f 10 44 24 f0 movsd -0x10(%rsp),%xmm0
3d: c3 retq

By contrast, the middle option produces:

0000000000000005 <dfplus>:
5: f2 0f 58 c1 addsd %xmm1,%xmm0
9: c3 retq

and the first option:

00000009 <dfplus>:
9: dd 44 24 04 fldl 0x4(%esp)
d: dc 44 24 0c faddl 0xc(%esp)
11: c3 ret

The difference between the first and last option is due to the
differences in calling convention.

gcc also has the option -mfpmath=sse,387 which tells the compiler that
it can use both. A small experiment only resulted in using SSE2, but
maybe if I had used code with more values alive at the same time it
would have used both.

- 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: https://euro.theforth.net/2023

Sure, x87 mode is still there for backwards compatibility and you can
instruct compilers to use it eg for 80-bit floats. Godbolt is your friend.
I seem to remember the "deprecation" had to do with inefficient load/store
mechanisms between memory and x87 registes.

I can't remember or name an exact citation but found a somewhat related
discussion:
https://retrocomputing.stackexchange.com/questions/9751/did-any-compiler-fully-use-intel-x87-80-bit-floating-point

Anton Ertl wrote:
[..]
> gcc also has the option -mfpmath=sse,387 which tells the compiler that
> it can use both.

Nice to know! Last time I checked, only the Intel compiler could do that.

-marcel

In article <uvk861$gs90$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
>On 4/15/24 09:09, Anton Ertl wrote:
>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>>> Failure from overflowing the
>>> fpu stack is silent.
>>
>> Reality check:
>>
>> VFX Forth 64 5.43 [build 0199] 2023-11-09 for Linux x64
>> © MicroProcessor Engineering Ltd, 1998-2023
>>
>> 1e 2e 3e 4e 5e 6e 7e ok F:-7
>> 8e ok
>> NDP Stack Fault: NDP SW = 0041
>> NDP Potential Exception: NDP SW = 0041
>>
>> SwiftForth also seems to notice it in some way, but does not report it
>> as an error:
>>
>> SwiftForth x64-Linux 4.0.0-RC87 24-Mar-2024
>> 1e 2e 3e 4e 5e 6e ok
>> f. 6.00000000 ok
>>
>> SwiftForth x64-Linux 4.0.0-RC87 24-Mar-2024
>> 1e 2e 3e 4e 5e 6e 7e ok
>> f.
>> ok
>
>I tried overflowing the fpu stack in kforth32, and no exception is
>raised. Perhaps one needs to configure the fpu to raise an exception.
>Also tried it in C with an assembly procedure. The executable throws no
>exception.
>
>--
>Krishna
>
>== begin fpu-stack-overflow.4th ==
> fpu-stack-overflow.4th
>\ for use with kforth32
>
>include ans-words
>include strings
>include modules
>include syscalls
>include mc
>include asm-x86
>
>code fpu-stack-overflow
> fld1,
> fld1,
> fld1,
> fld1,
> fld1,
> fld1,
> fld1,
> fld1,
> fld1,
>end-code
>
>fpu-stack-overflow
>
>
>== end fpu-stack-overflow.4th ==
>
>== begin example ==
>$ kforth32
>kForth-32 v 2.4.5 (Build: 2024-03-30)
>Copyright (c) 1998--2023 Krishna Myneni
>Contributions by: dpw gd mu bk abs tn cmb bg dnw
>Provided under the GNU Affero General Public License, v3.0 or later
>
>include fpu-stack-overflow
> ok
>== end example ==
>
>
I tried this on ciforth. It crashes with the 10th item
not the 8th.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

On 4/16/24 02:59, albert@spenarnc.xs4all.nl wrote:
> In article <uvk861$gs90$1@dont-email.me>,
> Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
>> On 4/15/24 09:09, Anton Ertl wrote:
>>> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>>>> Failure from overflowing the
>>>> fpu stack is silent.
>>>
>>> Reality check:
>>>
>>> VFX Forth 64 5.43 [build 0199] 2023-11-09 for Linux x64
>>> © MicroProcessor Engineering Ltd, 1998-2023
>>>
>>> 1e 2e 3e 4e 5e 6e 7e ok F:-7
>>> 8e ok
>>> NDP Stack Fault: NDP SW = 0041
>>> NDP Potential Exception: NDP SW = 0041
>>>
>>> SwiftForth also seems to notice it in some way, but does not report it
>>> as an error:
>>>
>>> SwiftForth x64-Linux 4.0.0-RC87 24-Mar-2024
>>> 1e 2e 3e 4e 5e 6e ok
>>> f. 6.00000000 ok
>>>
>>> SwiftForth x64-Linux 4.0.0-RC87 24-Mar-2024
>>> 1e 2e 3e 4e 5e 6e 7e ok
>>> f.
>>> ok
>>
>> I tried overflowing the fpu stack in kforth32, and no exception is
>> raised. Perhaps one needs to configure the fpu to raise an exception.
>> Also tried it in C with an assembly procedure. The executable throws no
>> exception.
>>
>> --
>> Krishna
>>
>> == begin fpu-stack-overflow.4th ==
>> fpu-stack-overflow.4th
>> \ for use with kforth32
>>
>> include ans-words
>> include strings
>> include modules
>> include syscalls
>> include mc
>> include asm-x86
>>
>> code fpu-stack-overflow
>> fld1,
>> fld1,
>> fld1,
>> fld1,
>> fld1,
>> fld1,
>> fld1,
>> fld1,
>> fld1,
>> end-code
>>
>> fpu-stack-overflow
>>
>>
>> == end fpu-stack-overflow.4th ==
>>
>> == begin example ==
>> $ kforth32
>> kForth-32 v 2.4.5 (Build: 2024-03-30)
>> Copyright (c) 1998--2023 Krishna Myneni
>> Contributions by: dpw gd mu bk abs tn cmb bg dnw
>> Provided under the GNU Affero General Public License, v3.0 or later
>>
>> include fpu-stack-overflow
>> ok
>> == end example ==
>>
>>
> I tried this on ciforth. It crashes with the 10th item
> not the 8th.
>

That may be for some other reason. The following code executes an
arbitrary number of FLD1 instructions:

code fpu-stack-overflow ( n -- -n )
0 [ebx] ecx mov, \ set loop count
0 # eax mov,
DO,
fld1,
eax dec,
LOOP,
eax 0 [ebx] mov,
0 # eax mov,
end-code

16384 fpu-stack-overflow .
\ end of prog

\ run it

include clf-code/fpu-stack-overflow

-16384
ok

--
Krishna
> Groetjes Albert

On 4/15/24 20:10, minforth wrote:
> I would be surprised to get a SIGFPE interrupt from x87 stack ops.
> X87 mode has long been deprecated and replaced by SSE2.

Maybe I'm missing something, but SSE2 does not seem to have anything
beyond basic floating point arithmetic e.g. transcendental functions.

--
Krishna

Krishna Myneni wrote:

> On 4/15/24 20:10, minforth wrote:
>> I would be surprised to get a SIGFPE interrupt from x87 stack ops.
>> X87 mode has long been deprecated and replaced by SSE2.

> Maybe I'm missing something, but SSE2 does not seem to have anything
> beyond basic floating point arithmetic e.g. transcendental functions.

Hardware x87 support isn't necessarily faster:
https://users.ece.utexas.edu/~adnan/comm/fast-trigonometric-functions-using.pdf

But I think the main advantage lies in the possibility of parallel and/or
vectorized execution.

And of course Forth is very close to assembler and as such it is natural
to use x87 instructions, unless a Forth system is implemented using libc
or using math libraries that better exploit those many features of modern CPUs.

Krishna Myneni wrote:

> On 4/15/24 20:10, minforth wrote:
>> I would be surprised to get a SIGFPE interrupt from x87 stack ops.
>> X87 mode has long been deprecated and replaced by SSE2.

> Maybe I'm missing something, but SSE2 does not seem to have anything
> beyond basic floating point arithmetic e.g. transcendental functions.

Yes that is right. There is a sqrt but nothing more.

In lxf64/ntf64 I use an external C library, specifically fdlibm53.

This claims to be within 1 ulp correct. My testing also suggests this.
fdlibm looks to be the base for most other math libraries.
I could have used libm from gcc but I wanted the same code for both
Linux and Windows.

In lxf/ntf I use the 387 fp stack. I think this was a wrong decision.
8 stack items is to low to be useful for anything more complicated.
complex numbers is an example that quickly eats all 8 stack items.

Best Regards
Peter Fälth

> --
> Krishna

minforth wrote:

> Krishna Myneni wrote:
[..]
> Hardware x87 support isn't necessarily faster:
> https://users.ece.utexas.edu/~adnan/comm/fast-trigonometric-functions-using.pdf

... which shows it also can be a lot slower. And if I'm not mistaken, it can't
deliver the 80 bits of the FPU without breaking down by a factor of at least 1.3.

> But I think the main advantage lies in the possibility of parallel and/or
> vectorized execution.

I have not yet seen algorithms where that would bring something. It might when
all other code is done properly with SSE. An on-the-fly reconfigured FPGA
(available on some microcontrollers) might be a better idea :--)

> And of course Forth is very close to assembler and as such it is natural
> to use x87 instructions, unless a Forth system is implemented using libc
> or using math libraries that better exploit those many features of modern CPUs.

It all depends, that is what I like about Forth.

-marcel

mhx wrote:
> minforth wrote:
>> And of course Forth is very close to assembler and as such it is natural
>> to use x87 instructions, unless a Forth system is implemented using libc
>> or using math libraries that better exploit those many features of modern CPUs.
> It all depends, that is what I like about Forth.

True, it all depends. Copied from a Visual Studio documentation:

Many of the floating point math library functions have different implementations
for different CPU architectures. For example, the 32-bit x86 CRT may have a
different implementation than the 64-bit x64 CRT. In addition, some of the
functions may have multiple implementations for a given CPU architecture. The
most efficient implementation is selected dynamically at run-time depending on
the instruction sets supported by the CPU. For example, in the 32-bit x86 CRT,
some functions have both an x87 implementation and an SSE2 implementation. When
running on a CPU that supports SSE2, the faster SSE2 implementation is used.
When running on a CPU that does not support SSE2, the slower x87 implementation
is used.

minforth wrote:
[..]
> [..] For example, in the 32-bit x86 CRT,
> some functions have both an x87 implementation and an SSE2 implementation. When
> running on a CPU that supports SSE2, the faster SSE2 implementation is used.
> When running on a CPU that does not support SSE2, the **slower**
> [ my emphasis -mhx ] x87 implementation is used.

This strikes me as showing a strong bias (i.e. not strictly based on technical
arguments) towards SSE2. I've noticed before that Microsoft has a dislike for
the x87 FPU, if not boycotting it outright (e.g. no long double in their
compiler).

-marcel

On 17/04/2024 11:07 pm, minforth wrote:
> ...
> And of course Forth is very close to assembler and as such it is natural
> to use x87 instructions

In addition to being available on most Intel x86 cpu's, x87 was cheap to
support. A relatively small amount of code was needed to implement the
assembler extensions:

https://pastebin.com/Md6BGWmj

There wasn't a good reason not to choose x87. If the hardware stack didn't
appeal, use a software stack. Performance will still be very good. I recall
pitting my 16-bit DTC forth with x87 against VFX using an fp intensive program/
benchmark. The difference was only a factor of 4. I couldn't believe it.

mhx wrote:

> minforth wrote:
> [..]
>> [..] For example, in the 32-bit x86 CRT,
>> some functions have both an x87 implementation and an SSE2 implementation. When
>> running on a CPU that supports SSE2, the faster SSE2 implementation is used.
>> When running on a CPU that does not support SSE2, the **slower**
>> [ my emphasis -mhx ] x87 implementation is used.

> This strikes me as showing a strong bias (i.e. not strictly based on technical
> arguments) towards SSE2. I've noticed before that Microsoft has a dislike for
> the x87 FPU, if not boycotting it outright (e.g. no long double in their
> compiler).

Could be. At least gcc has support for _float80. FWIW Intel's icc even has a
compiler flag for x87 stack overflow warnings. It all depends. ;-)

In article <6620d188$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
>On 17/04/2024 11:07 pm, minforth wrote:
>> ...
>> And of course Forth is very close to assembler and as such it is natural
>> to use x87 instructions
>
>In addition to being available on most Intel x86 cpu's, x87 was cheap to
>support. A relatively small amount of code was needed to implement the
>assembler extensions:
>
>https://pastebin.com/Md6BGWmj
>
>There wasn't a good reason not to choose x87. If the hardware stack didn't
>appeal, use a software stack. Performance will still be very good. I recall
>pitting my 16-bit DTC forth with x87 against VFX using an fp intensive program/
>benchmark. The difference was only a factor of 4. I couldn't believe it.
>

The loadable extension for ciforth runs 20 screens.
This is not politically correct. Only 80 bits floats, only 8 stack depth.
(The assembler is require, which contains 2 screens of fp related
instructions.)
The transcendental functions are very low cost,
Nice if you have an occasional cosine.
In implementing the floating point for the transputer, we had
to generate Chebychov polynomials with a special UBASIC
program and a truckload of testing. At least they
accommodated ISO single and double precision because
that was the transputer baseline.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

In article <37580f936ac4a2d21fb84ccf59e6b7a4@www.novabbs.com>,
mhx <mhx@iae.nl> wrote:
>minforth wrote:
>[..]
>> [..] For example, in the 32-bit x86 CRT,
>> some functions have both an x87 implementation and an SSE2 implementation. When
>> running on a CPU that supports SSE2, the faster SSE2 implementation is used.
>> When running on a CPU that does not support SSE2, the **slower**
>> [ my emphasis -mhx ] x87 implementation is used.
>
>This strikes me as showing a strong bias (i.e. not strictly based on technical
>arguments) towards SSE2. I've noticed before that Microsoft has a dislike for
>the x87 FPU, if not boycotting it outright (e.g. no long double in their
>compiler).

Microsoft are no hobbyists. There has to be a commercial incentive to
take it up, that is not a boycott. OTOH the gcc folks like a
challenge, resulting in a baroque building.

>
>-marcel
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

minforth wrote:

> mhx wrote:
[..]
> Could be. At least gcc has support for _float80. FWIW Intel's icc even has a
> compiler flag for x87 stack overflow warnings.
[..]

At runtime?

-marcel

In article <2024Apr14.132507@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>dxf <dxforth@gmail.com> writes:
>>On 14/04/2024 6:34 pm, Anton Ertl wrote:
>>> From what I read about this, the intention was that the FP stack would
>>> extend into memory (and thus not be limited to 8 elements): software
>>> should react to FP stack overflows and underflows and store some
>>> elements on overflow, and reload some elements on underflow. However,
>>> this functionality was implemented in a buggy way on the 8087, so it
>>> never worked as intended. Hoever, when they noticed this, the 8087
>>> was already on the market, and Hyrum's law ensured that this behaviour
>>> could not be changed.
>>
>>Do you have a reference for that?
>
>Kahan writes about the original intention in
>
>http://web.archive.org/web/20170118054747/https://cims.nyu.edu/~dbindel/class/cs279/87stack.pdf
>
>especially starting at the last paragraph of page 2.
>
>And about the bug (or rather design mistake):
>
>https://history.siam.org/pdfs2/Kahan_final.pdf
>
>Start with the second-to-last paragraph on page 163. He digresses for
>a page, but continues on the fourth paragraph of page 165 and
>continues to the first paragraph of page 168.

Interesting read. The reverse polish calculator from HP was a
resounding success, with great profits.
Kahan contributed to this.
It was killed by the bean counters at HP.
There was huge demand but they refused to expand production.
Then the calculator died because it simply was not available.

>
>- anton

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

mhx wrote:

> minforth wrote:

>> mhx wrote:
> [..]
>> Could be. At least gcc has support for _float80. FWIW Intel's icc even has a
>> compiler flag for x87 stack overflow warnings.
> [..]

> At runtime?

AFAIK they check if computation results are popped off the x87 stack and put
into the xmm0 register. Could be a flag for compile-time checking.

minforth wrote:

> mhx wrote:

>> minforth wrote:

>>> mhx wrote:
>> [..]
>>> Could be. At least gcc has support for _float80. FWIW Intel's icc even has a
>>> compiler flag for x87 stack overflow warnings.
>> [..]

>> At runtime?

> AFAIK they check if computation results are popped off the x87 stack and put
> into the xmm0 register. Could be a flag for compile-time checking.

Correction. It generates runtime code
https://www.intel.com/content/www/us/en/docs/cpp-compiler/developer-guide-reference/2021-8/fp-stack-check-qfp-stack-check.html

but it doesn't look very convincing to me.