I just looked at the floating-point implementations of recent
SwiftForth and VFX (finally present in the system from the start), and
on iForth-5.1-mini (for comparison):

1 FLOATS .

reports:

16 iforth
10 sf64
10 vfx64

For

: foo f+ f* ;

the resulting code is:

SwiftForth x64-Linux 4.0.0-RC87 24-Mar-2024
: foo f+ f* ; ok
see foo
44E8B9 ST(0) ST(1) FADDP DEC1
44E8BB ST(0) ST(1) FMULP DEC9
44E8BD RET C3 ok

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

: foo f+ f* ; ok
see foo
FOO
( 0050A250 DEC1 ) FADDP ST(1), ST
( 0050A252 DEC9 ) FMULP ST(1), ST
( 0050A254 C3 ) RET/NEXT
( 5 bytes, 3 instructions )

iForth:
$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

So apparently the 8 hardware FP stack items are enough for SwiftForth
and VFX, while iForth prefers to use an FP stack in memory to allow
for a deeper FP stack.

Gforth sticks out by using 8-byte FP values; most of those are stored
in memory (supporting deep FP stacks), with the top of FP stack in an
xmm register on AMD64:

: foo f+ f* ; ok
see-code foo
$7FF2CE8034E0 f+ 1->1
7FF2CE4A6E43: mov rax,r12
7FF2CE4A6E46: lea r12,$08[r12]
7FF2CE4A6E4B: addsd xmm15,$08[rax]
$7FF2CE8034E8 f* 1->1
7FF2CE4A6E51: mov rax,r12
7FF2CE4A6E54: lea r12,$08[r12]
7FF2CE4A6E59: mulsd xmm15,$08[rax]
$7FF2CE8034F0 ;s 1->1
7FF2CE4A6E5F: mov rbx,[r14]
7FF2CE4A6E62: add r14,$08
7FF2CE4A6E66: mov rax,[rbx]
7FF2CE4A6E69: jmp eax

- 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/13/24 12:55, Anton Ertl wrote:
> I just looked at the floating-point implementations of recent
> SwiftForth and VFX (finally present in the system from the start), and
> on iForth-5.1-mini (for comparison):
>
> 1 FLOATS .
>
> reports:
>
> 16 iforth
> 10 sf64
> 10 vfx64
>
> For
>
> : foo f+ f* ;
>
> the resulting code is:
>
> SwiftForth x64-Linux 4.0.0-RC87 24-Mar-2024
> : foo f+ f* ; ok
> see foo
> 44E8B9 ST(0) ST(1) FADDP DEC1
> 44E8BB ST(0) ST(1) FMULP DEC9
> 44E8BD RET C3 ok
>
>
> VFX Forth 64 5.43 [build 0199] 2023-11-09 for Linux x64
> © MicroProcessor Engineering Ltd, 1998-2023
>
> : foo f+ f* ; ok
> see foo
> FOO
> ( 0050A250 DEC1 ) FADDP ST(1), ST
> ( 0050A252 DEC9 ) FMULP ST(1), ST
> ( 0050A254 C3 ) RET/NEXT
> ( 5 bytes, 3 instructions )
>
>
> iForth:
> $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
>
> So apparently the 8 hardware FP stack items are enough for SwiftForth
> and VFX, while iForth prefers to use an FP stack in memory to allow
> for a deeper FP stack.
>
....

For me, an 8 item hardware fp stack limit is too limiting to be useful.
This is mostly because of my use of the fp stack for initializing tables
(arrays and matrices), and my coding style of returning more than 8
floats on the fp stack for some types of computation. No doubt one can
limit themselves to an 8-item fp stack, but I'd hate to have to code wit
such a limit.

--
Krishna

On 14/04/2024 3:55 am, Anton Ertl wrote:
> I just looked at the floating-point implementations of recent
> SwiftForth and VFX (finally present in the system from the start), and
> on iForth-5.1-mini (for comparison):
> ...
> So apparently the 8 hardware FP stack items are enough for SwiftForth
> and VFX, while iForth prefers to use an FP stack in memory to allow
> for a deeper FP stack.

All the more reason to make fp loadable so users can choose the model
they want instead of built-in. IIRC VFX and SWF previously did this.

Anton Ertl wrote:
[..]

> iForth:
> $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

> So apparently the 8 hardware FP stack items are enough for SwiftForth
> and VFX, while iForth prefers to use an FP stack in memory to allow
> for a deeper FP stack.

Turbo Pascal had a fast FP mode that used the FPU stack. I found almost
immediately that that is unusable for serious work.

The used scheme is rather complicated. iForth uses the internal stack
when it can prove that there will be no under- or overflow. Non-inlined
calls (F. below) always use the memory stack.

FORTH> pi fvalue val1 pi/2 fvalue val2 ok
FORTH> : test val1 fdup val2 foo val1 f+ val2 f* f. ; ok
FORTH> see test
Flags: ANSI
$015FDA80 : test
$015FDA8A fld $015FD650 tbyte-offset
$015FDA90 fld ST(0)
$015FDA92 fld $015FD670 tbyte-offset
$015FDA98 faddp ST(1), ST
$015FDA9A fmulp ST(1), ST
$015FDA9C fld $015FD650 tbyte-offset
$015FDAA2 faddp ST(1), ST
$015FDAA4 fld $015FD670 tbyte-offset
$015FDAAA fmulp ST(1), ST
$015FDAAC fpush,
$015FDAB6 jmp F.+10 ( $0124ED42 ) offset NEAR
$015FDABB ;

Apparently there are special interrupts that one can enable
to signal FPU stack underflow (and then spill to memory)
but I never got them to work reliably. The software
analysis works fine, but can be fooled in case of rather
contrived circumstances. I have not encountered a bug in the
past two decades.

-marcel

On 14/04/2024 5:03 pm, mhx wrote:
> Anton Ertl wrote:
> [..]
>
>> iForth:
>> $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
>
>> So apparently the 8 hardware FP stack items are enough for SwiftForth
>> and VFX, while iForth prefers to use an FP stack in memory to allow
>> for a deeper FP stack.
>
> Turbo Pascal had a fast FP mode that used the FPU stack. I found almost
> immediately that that is unusable for serious work.

Were that the case Intel had plenty opportunity to change it. They had
an academic advising them.

mhx@iae.nl (mhx) writes:
>Apparently there are special interrupts that one can enable
>to signal FPU stack underflow (and then spill to memory)
>but I never got them to work reliably.

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.

And apparently this feature was not considered to be important enough
to add a new architectural feature that allows implementing the FP
stack extension to memory. I guess that the implementations of
Fortran and Algol-family languages (e.g., C) in the 1980s only used
the stack within an expression, so avoiding FP stack overflows with
compiler analysis (like you do), is relatively easy.

- 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 14/04/2024 6:34 pm, Anton Ertl wrote:
> mhx@iae.nl (mhx) writes:
>> Apparently there are special interrupts that one can enable
>> to signal FPU stack underflow (and then spill to memory)
>> but I never got them to work reliably.
>
> 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? Below is a paper written by one of the
designers and it doesn't appear to be mentioned. It's of course possible
to maintain a stack in software and use the FPU to do the calculations.
There are instructions to load/store Temp Real format to memory and that
gets a mention.

https://dl.acm.org/doi/pdf/10.1145/800053.801923

In article <2024Apr13.195518@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>I just looked at the floating-point implementations of recent
>SwiftForth and VFX (finally present in the system from the start), and
>on iForth-5.1-mini (for comparison):
>
>1 FLOATS .
>
>reports:
>
>16 iforth
>10 sf64
>10 vfx64
>
>For
>
>: foo f+ f* ;
>
>the resulting code is:
>
>SwiftForth x64-Linux 4.0.0-RC87 24-Mar-2024
>: foo f+ f* ; ok
>see foo
>44E8B9 ST(0) ST(1) FADDP DEC1
>44E8BB ST(0) ST(1) FMULP DEC9
>44E8BD RET C3 ok
>
>
>VFX Forth 64 5.43 [build 0199] 2023-11-09 for Linux x64
>© MicroProcessor Engineering Ltd, 1998-2023
>
>: foo f+ f* ; ok
>see foo
>FOO
>( 0050A250 DEC1 ) FADDP ST(1), ST
>( 0050A252 DEC9 ) FMULP ST(1), ST
>( 0050A254 C3 ) RET/NEXT
>( 5 bytes, 3 instructions )

I cut the same corners with ciforth. However I think this
cannot be compliant with the IEEE requirement of the standard?

>- anton
--
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 <27089a13c7ce61da7ffb927cb6c365d2@www.novabbs.com>,
mhx <mhx@iae.nl> wrote:
>Anton Ertl wrote:
>[..]
>
>> iForth:
>> $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
>
>> So apparently the 8 hardware FP stack items are enough for SwiftForth
>> and VFX, while iForth prefers to use an FP stack in memory to allow
>> for a deeper FP stack.
>
>Turbo Pascal had a fast FP mode that used the FPU stack. I found almost
>immediately that that is unusable for serious work.
>
>The used scheme is rather complicated. iForth uses the internal stack
>when it can prove that there will be no under- or overflow. Non-inlined
>calls (F. below) always use the memory stack.
>
>FORTH> pi fvalue val1 pi/2 fvalue val2 ok
>FORTH> : test val1 fdup val2 foo val1 f+ val2 f* f. ; ok
>FORTH> see test
>Flags: ANSI
>$015FDA80 : test
>$015FDA8A fld $015FD650 tbyte-offset
>$015FDA90 fld ST(0)
>$015FDA92 fld $015FD670 tbyte-offset
>$015FDA98 faddp ST(1), ST
>$015FDA9A fmulp ST(1), ST
>$015FDA9C fld $015FD650 tbyte-offset
>$015FDAA2 faddp ST(1), ST
>$015FDAA4 fld $015FD670 tbyte-offset
>$015FDAAA fmulp ST(1), ST
>$015FDAAC fpush,
>$015FDAB6 jmp F.+10 ( $0124ED42 ) offset NEAR
>$015FDABB ;
>
>Apparently there are special interrupts that one can enable
>to signal FPU stack underflow (and then spill to memory)
>but I never got them to work reliably. The software
>analysis works fine, but can be fooled in case of rather
>contrived circumstances. I have not encountered a bug in the
>past two decades.

This is a practical way.

I researched whether it is possible to detect whether the
circular stack overflows. There are instructions to
detect whether a position in this stack is occupied.
For a word that using a stack 4 deep, you could detect whether
it is necessary to save words this way, I thought.
I couldn't make it work, because essential assembler instruction
are missing. (Or I'm not clever enough.)

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

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.

- 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 wrote:

> In article <27089a13c7ce61da7ffb927cb6c365d2@www.novabbs.com>,
> mhx <mhx@iae.nl> wrote:
>>Anton Ertl wrote:
>>[..]
> This is a practical way.

> I researched whether it is possible to detect whether the
> circular stack overflows. There are instructions to
> detect whether a position in this stack is occupied.
> For a word that using a stack 4 deep, you could detect whether
> it is necessary to save words this way, I thought.
> I couldn't make it work, because essential assembler instruction
> are missing. (Or I'm not clever enough.)

I vaguely remember something like that for the FPU stack (combined
with interrupts?). It falls under the category "I couldn't make
it work."

-marcel

On 4/14/24 03:02, dxf wrote:
> On 14/04/2024 5:03 pm, mhx wrote:
>> Anton Ertl wrote:
>> [..]
>>
>>> iForth:
>>> $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
>>
>>> So apparently the 8 hardware FP stack items are enough for SwiftForth
>>> and VFX, while iForth prefers to use an FP stack in memory to allow
>>> for a deeper FP stack.
>>
>> Turbo Pascal had a fast FP mode that used the FPU stack. I found almost
>> immediately that that is unusable for serious work.
>
> Were that the case Intel had plenty opportunity to change it. They had
> an academic advising them.
>

Let's take a non-trivial example to illustrate why the 8-deep fp stack
may not be that useful for numerical computation. This example is
actually from the FSL demo. The word computes the Lorenz equations,
which give rise to the famous butterfly attractor. This is a system of
three nonlinear first order differential equations in three variables,
x, y, z, which are time dependent. The Lorenz equations define the
instantaneous derivatives of these variables:

dx/dt = sigma*(y - x)
dy/dt = x*(rho -z) - y
dz/dt = x*y - beta*z

where sigma, rho, and beta are constant parameters.

Let's say we want to write a word DERIVS which computes and stores the
derivatives, given the instantaneous values of x, y, z. This is the
basis for any numerical code which solves the trajectory in time,
starting from an initial condition.

DERIVS ( F: x y z -- )

Hence, we want to place some values x, y, and z onto the fp stack and
compute the three derivatives. Ideally these three values remain on the
fp stack and don't need to be fetched from memory constantly until the
three derivatives are computed, especially if one is using the hardware
fp stack. We allow the constant parameters to be fetched from memory and
the results of the derivative computation to be stored to memory so they
don't overflow the stack. This should be doable with the 8-element
hardware fp stack.

Below I give Forth code which computes the derivatives. This code is
usable only on systems with a separate FP stack. It will be interesting
to see the compiled code given by Forth systems using the hardware fpu
stack to compute the results. While this example may behave properly, if
we go to a fourth order system or higher, it gets less likely that the
hardware stack remains usable.

--
Krishna

== begin fpstack-test.4th ==
\ fpstack-test.4th
\ \ Compute the Lorenz equations, a set of three coupled
\ nonlinear differential equations.
\ \ dx/dt = sigma*(y - x)
\ dy/dt = x*(rho -z) - y
\ dz/dt = x*y - beta*z
\ \ sigma, rho, and beta are constant parameters.
\ \ The following code requires a separate fp stack

include ans-words \ only for kForth64
include fsl/fsl-util

[UNDEFINED] FPICK [IF]
cr .( Your system may not use a separate floating point stack!)
ABORT
[THEN]

[UNDEFINED] F2OVER [IF]
: f2over ( F: r1 r2 r3 r4 -- r1 r2 r3 r4 r1 r2 )
3 fpick 3 fpick ;
[THEN]

[UNDEFINED] F+! [IF]
: f+! ( a -- ) ( F: r -- ) dup f@ f+ f! ;
[THEN]

16.0e0 fconstant sigma
45.92e0 fconstant rho
4.0e0 fconstant beta

\ Compute the derivatives given the instantaneous values
\ x, y, z for a given time t.

\ xdot{ is an array consisting of dx/dt, dy/dt, dz/dt
3 float array xdot{

: derivs ( F: x y z -- )
fdup f2over \ F: x y z z x y
f- sigma f* fnegate
xdot{ 0 } f! \ F: x y z z
rho fover f- \ F: x y z z rho-z
4 fpick f* \ F: x y z z x*(rho - z)
3 fpick f-
xdot{ 1 } f! \ F: x y z z
fdrop
beta f* fnegate
xdot{ 2 } f!
f* xdot{ 2 } f+!
;

0 [IF]
include ttester
\ Test DERIVS
1e-15 set-near
t{ 0.1e 0.6e 4.0e derivs -> }t
t{ xdot{ 0 } f@ -> 8.0e0 }t
t{ xdot{ 1 } f@ -> 3.592e0 }t
t{ xdot{ 2 } f@ -> -15.94e0 }t
[THEN]

== end fpstack-test.4th ==

On 14/04/2024 9:25 pm, Anton Ertl 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.

The latter sounds like someone not getting his way more than a design mistake.
In the first reference Kahan states:

"When the 8087 was designed, I knew that stack over/underflow was an issue of
more aesthetic than practical importance. I still regret that the 8087's stack
implementation was not quite so neat as my original intention described in the
accompanying note."

Intel decided Kahan's aesthetic afterthought could be dispensed with. History
appears to have proven them correct. Were 8 levels of stack actually insufficient,
it would have made more sense for Intel to double it (if not for the 8087 then the
next incarnation) than to spill to memory which was bad in every way.

On 14/04/2024 10:50 pm, Krishna Myneni wrote:
> ...
> Below I give Forth code which computes the derivatives. This code is usable only on systems with a separate FP stack. It will be interesting to see the compiled code given by Forth systems using the hardware fpu stack to compute the results. While this example may behave properly, if we go to a fourth order system or higher, it gets less likely that the hardware stack remains usable.

Systems that default to hardware fpu stack may well offer a software stack option.

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>dx/dt = sigma*(y - x)
>dy/dt = x*(rho -z) - y
>dz/dt = x*y - beta*z
>
>where sigma, rho, and beta are constant parameters.
>
>Let's say we want to write a word DERIVS which computes and stores the
>derivatives, given the instantaneous values of x, y, z. This is the
>basis for any numerical code which solves the trajectory in time,
>starting from an initial condition.
>
>DERIVS ( F: x y z -- )
>
>Hence, we want to place some values x, y, and z onto the fp stack and
>compute the three derivatives. Ideally these three values remain on the
>fp stack and don't need to be fetched from memory constantly until the
>three derivatives are computed, especially if one is using the hardware
>fp stack. We allow the constant parameters to be fetched from memory and
>the results of the derivative computation to be stored to memory so they
>don't overflow the stack. This should be doable with the 8-element
>hardware fp stack.

I have adapted your Forth code:

[UNDEFINED] F2OVER [IF]
: f2over ( F: r1 r2 r3 r4 -- r1 r2 r3 r4 r1 r2 )
3 fpick 3 fpick ;
[THEN]

16.0e0 fconstant sigma
45.92e0 fconstant rho
4.0e0 fconstant beta

fvariable dx/dt
fvariable dy/dt
fvariable dz/dt

: derivs ( F: x y z -- )
fdup f2over \ F: x y z z x y
f- sigma f* fnegate
dx/dt f! \ F: x y z z
rho fover f- \ F: x y z z rho-z
4 fpick f* \ F: x y z z x*(rho - z)
3 fpick f-
dy/dt f! \ F: x y z z
fdrop
beta f* fnegate
frot frot f* f+ dz/dt f!
;

0.1e 0.6e 4.0e derivs
dx/dt f@ f. cr \ 8.
dy/dt f@ f. cr \ 3.592
dz/dt f@ f. cr \ -15.94

In particular, I eliminated the additional memory accesses to DZ/DT.

SwiftForth, VFX and iforth produce the expected results for your test
case. The code is:

SwiftForth 4.0.0-RC87 VFX Forth 64 5.43 iforth-5.1-mini
ST(0) FLD FLD ST fld ST(0)
44E8BC ( f2over ) CALL CALL 0050A080 F2OVER fld [r13 0 +] tbyte
ST(0) ST(1) FSUBP FSUBP ST(1), ST fxch ST(1)
44E8FB ( sigma ) CALL CALL 0050A2BB SIGMA fld [r13 #16 +] tby
ST(0) ST(1) FMULP FMULP ST(1), ST lea r13, [r13 #32 +]
FCHS FCHS fxch ST(3)
-8 [RBP] RBP LEA FSTP TBYTE FFF9CFE8 [RIP] fxch ST(1)
RBX 0 [RBP] MOV CALL 0050A2FB RHO fld ST(3)
4C508 [RDI] RBX LEA FLD ST(1) fld ST(3)
0 [RBX] TBYTE FSTP FSUBP ST(1), ST fsubp ST(1), ST
0 [RBP] RBX MOV LEA RBP, [RBP+-08] fld $101BC720 tbyte
8 [RBP] RBP LEA MOV [RBP], RBX fmulp ST(1), ST
44E923 ( rho ) CALL MOV EBX, # 00000004 fchs
ST(1) FLD CALL 005030C0 FPICK fstp $10226470 tbyte
ST(0) ST(1) FSUBP FMULP ST(1), ST fld $101BC710 tbyte
-8 [RBP] RBP LEA LEA RBP, [RBP+-08] fld ST(1)
RBX 0 [RBP] MOV MOV [RBP], RBX fsubp ST(1), ST
4 # EBX MOV MOV EBX, # 00000003 fld ST(4)
43C901 ( FPICK ) CALL CALL 005030C0 FPICK fmulp ST(1), ST
ST(0) ST(1) FMULP FSUBP ST(1), ST fld ST(3)
-8 [RBP] RBP LEA FSTP TBYTE FFF9CFC1 [RIP] fsubp ST(1), ST
RBX 0 [RBP] MOV FSTP ST fstp $10226490 tbyte
3 # EBX MOV CALL 0050A33B BETA ffreep ST(0)
43C901 ( FPICK ) CALL FMULP ST(1), ST fld $101BC700 tbyte
ST(0) ST(1) FSUBP FCHS fmulp ST(1), ST
-8 [RBP] RBP LEA FXCH ST(1) fchs
RBX 0 [RBP] MOV FXCH ST(2) fxch ST(1)
4C530 [RDI] RBX LEA FXCH ST(1) fxch ST(2)
0 [RBX] TBYTE FSTP FXCH ST(2) fxch ST(1)
0 [RBP] RBX MOV FMULP ST(1), ST fxch ST(2)
8 [RBP] RBP LEA FADDP ST(1), ST fmulp ST(1), ST
ST(0) FSTP FSTP TBYTE FFF9CFB4 [RIP] fxch ST(1)
44E94B ( beta ) CALL RET/NEXT fpopswap,
ST(0) ST(1) FMULP faddp ST(1), ST
FCHS fstp $102264B0 tbyte
43C807 ( FROT ) CALL ;
43C807 ( FROT ) CALL
ST(0) ST(1) FMULP
ST(0) ST(1) FADDP
-8 [RBP] RBP LEA
RBX 0 [RBP] MOV
4C558 [RDI] RBX LEA
0 [RBX] TBYTE FSTP
0 [RBP] RBX MOV
8 [RBP] RBP LEA
RET

FPICK is apparently implemented on SwiftForth and VFX through an
indirect branch that branches to one of 8 variants of "FLD ST(...)",
while iForth manages to resolve this during compilation.

I have also looked at VFX 5.11 which uses XMM registers instead of the
FP stack, but it does not inline FP operations, so you mostly see a long
sequence of calls.

- 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

dxf <dxforth@gmail.com> writes:
>On 14/04/2024 9:25 pm, Anton Ertl wrote:
>> 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.
>
>The latter sounds like someone not getting his way more than a design mistake.
>In the first reference Kahan states:
>
> "When the 8087 was designed, I knew that stack over/underflow was an issue of
> more aesthetic than practical importance. I still regret that the 8087's stack
> implementation was not quite so neat as my original intention described in the
> accompanying note."
>
>Intel decided Kahan's aesthetic afterthought could be dispensed with.

In a way, they did, and Kahan obviously did not get his way. But to
me it sounds like they tried and failed at implementing a stack that
extends into memory. The tags that indicate the presence of a stack
item are there. If they had made a conscious decision at the start to
dispense with the idea of an extensible stack, they would have
discpensed with these bits indicating the presence of a stack item as
well. So what happened is that they botched the first attempt, and
then decided that they did not want to do what would have been
necessary to fix it.

- 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 14 Apr 2024 at 01:47:20 CEST, "Krishna Myneni" <krishna.myneni@ccreweb.org>
wrote:

> On 4/13/24 12:55, Anton Ertl wrote:
>> I just looked at the floating-point implementations of recent
>> SwiftForth and VFX (finally present in the system from the start), and
>> on iForth-5.1-mini (for comparison):
>>
>> 1 FLOATS .
>>
>> reports:
>>
>> 16 iforth
>> 10 sf64
>> 10 vfx64
>>
>> For
>>
>> : foo f+ f* ;
>>
>> the resulting code is:
>>
>> SwiftForth x64-Linux 4.0.0-RC87 24-Mar-2024
>> : foo f+ f* ; ok
>> see foo
>> 44E8B9 ST(0) ST(1) FADDP DEC1
>> 44E8BB ST(0) ST(1) FMULP DEC9
>> 44E8BD RET C3 ok
>>
>>
>> VFX Forth 64 5.43 [build 0199] 2023-11-09 for Linux x64
>> © MicroProcessor Engineering Ltd, 1998-2023
>>
>> : foo f+ f* ; ok
>> see foo
>> FOO
>> ( 0050A250 DEC1 ) FADDP ST(1), ST
>> ( 0050A252 DEC9 ) FMULP ST(1), ST
>> ( 0050A254 C3 ) RET/NEXT
>> ( 5 bytes, 3 instructions )
>>
>>
>> iForth:
>> $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
>>
>> So apparently the 8 hardware FP stack items are enough for SwiftForth
>> and VFX, while iForth prefers to use an FP stack in memory to allow
>> for a deeper FP stack.
>>
> ...
>
> For me, an 8 item hardware fp stack limit is too limiting to be useful.
> This is mostly because of my use of the fp stack for initializing tables
> (arrays and matrices), and my coding style of returning more than 8
> floats on the fp stack for some types of computation. No doubt one can
> limit themselves to an 8-item fp stack, but I'd hate to have to code wit
> such a limit.

The manual (gasp) documents how to change the default FP package.

Changing the default pack also changes the system call interfaces to
match.

Stephen
--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com
MPE website
http://www.vfxforth.com/downloads/VfxCommunity/
downloads

On 4/14/24 10:19, Anton Ertl wrote:
> Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>> dx/dt = sigma*(y - x)
>> dy/dt = x*(rho -z) - y
>> dz/dt = x*y - beta*z
>>
>> where sigma, rho, and beta are constant parameters.
>>
>> Let's say we want to write a word DERIVS which computes and stores the
>> derivatives, given the instantaneous values of x, y, z. This is the
>> basis for any numerical code which solves the trajectory in time,
>> starting from an initial condition.
>>
>> DERIVS ( F: x y z -- )
>>
>> Hence, we want to place some values x, y, and z onto the fp stack and
>> compute the three derivatives. Ideally these three values remain on the
>> fp stack and don't need to be fetched from memory constantly until the
>> three derivatives are computed, especially if one is using the hardware
>> fp stack. We allow the constant parameters to be fetched from memory and
>> the results of the derivative computation to be stored to memory so they
>> don't overflow the stack. This should be doable with the 8-element
>> hardware fp stack.
>
> I have adapted your Forth code:
>
> [UNDEFINED] F2OVER [IF]
> : f2over ( F: r1 r2 r3 r4 -- r1 r2 r3 r4 r1 r2 )
> 3 fpick 3 fpick ;
> [THEN]
>
> 16.0e0 fconstant sigma
> 45.92e0 fconstant rho
> 4.0e0 fconstant beta
>
> fvariable dx/dt
> fvariable dy/dt
> fvariable dz/dt
>
> : derivs ( F: x y z -- )
> fdup f2over \ F: x y z z x y
> f- sigma f* fnegate
> dx/dt f! \ F: x y z z
> rho fover f- \ F: x y z z rho-z
> 4 fpick f* \ F: x y z z x*(rho - z)
> 3 fpick f-
> dy/dt f! \ F: x y z z
> fdrop
> beta f* fnegate
> frot frot f* f+ dz/dt f!
> ;
>
> 0.1e 0.6e 4.0e derivs
> dx/dt f@ f. cr \ 8.
> dy/dt f@ f. cr \ 3.592
> dz/dt f@ f. cr \ -15.94
>
> In particular, I eliminated the additional memory accesses to DZ/DT.
>

Nice. FROT FROT is expensive on a memory based FP stack, unless it is
optimized by the compiler, but for fpu stack use it's probably very
fast. I see that VFX Forth and iforth use a series of FXCH instructions
to implement FROT FROT.

> SwiftForth, VFX and iforth produce the expected results for your test
> case. The code is:
>
> SwiftForth 4.0.0-RC87 VFX Forth 64 5.43 iforth-5.1-mini
> ST(0) FLD FLD ST fld ST(0)
> 44E8BC ( f2over ) CALL CALL 0050A080 F2OVER fld [r13 0 +] tbyte
> ST(0) ST(1) FSUBP FSUBP ST(1), ST fxch ST(1)
> 44E8FB ( sigma ) CALL CALL 0050A2BB SIGMA fld [r13 #16 +] tby
> ST(0) ST(1) FMULP FMULP ST(1), ST lea r13, [r13 #32 +]
> FCHS FCHS fxch ST(3)
> -8 [RBP] RBP LEA FSTP TBYTE FFF9CFE8 [RIP] fxch ST(1)
> RBX 0 [RBP] MOV CALL 0050A2FB RHO fld ST(3)
> 4C508 [RDI] RBX LEA FLD ST(1) fld ST(3)
> 0 [RBX] TBYTE FSTP FSUBP ST(1), ST fsubp ST(1), ST
> 0 [RBP] RBX MOV LEA RBP, [RBP+-08] fld $101BC720 tbyte
> 8 [RBP] RBP LEA MOV [RBP], RBX fmulp ST(1), ST
> 44E923 ( rho ) CALL MOV EBX, # 00000004 fchs
> ST(1) FLD CALL 005030C0 FPICK fstp $10226470 tbyte
> ST(0) ST(1) FSUBP FMULP ST(1), ST fld $101BC710 tbyte
> -8 [RBP] RBP LEA LEA RBP, [RBP+-08] fld ST(1)
> RBX 0 [RBP] MOV MOV [RBP], RBX fsubp ST(1), ST
> 4 # EBX MOV MOV EBX, # 00000003 fld ST(4)
> 43C901 ( FPICK ) CALL CALL 005030C0 FPICK fmulp ST(1), ST
> ST(0) ST(1) FMULP FSUBP ST(1), ST fld ST(3)
> -8 [RBP] RBP LEA FSTP TBYTE FFF9CFC1 [RIP] fsubp ST(1), ST
> RBX 0 [RBP] MOV FSTP ST fstp $10226490 tbyte
> 3 # EBX MOV CALL 0050A33B BETA ffreep ST(0)
> 43C901 ( FPICK ) CALL FMULP ST(1), ST fld $101BC700 tbyte
> ST(0) ST(1) FSUBP FCHS fmulp ST(1), ST
> -8 [RBP] RBP LEA FXCH ST(1) fchs
> RBX 0 [RBP] MOV FXCH ST(2) fxch ST(1)
> 4C530 [RDI] RBX LEA FXCH ST(1) fxch ST(2)
> 0 [RBX] TBYTE FSTP FXCH ST(2) fxch ST(1)
> 0 [RBP] RBX MOV FMULP ST(1), ST fxch ST(2)
> 8 [RBP] RBP LEA FADDP ST(1), ST fmulp ST(1), ST
> ST(0) FSTP FSTP TBYTE FFF9CFB4 [RIP] fxch ST(1)
> 44E94B ( beta ) CALL RET/NEXT fpopswap,
> ST(0) ST(1) FMULP faddp ST(1), ST
> FCHS fstp $102264B0 tbyte
> 43C807 ( FROT ) CALL ;
> 43C807 ( FROT ) CALL
> ST(0) ST(1) FMULP
> ST(0) ST(1) FADDP
> -8 [RBP] RBP LEA
> RBX 0 [RBP] MOV
> 4C558 [RDI] RBX LEA
> 0 [RBX] TBYTE FSTP
> 0 [RBP] RBX MOV
> 8 [RBP] RBP LEA
> RET
>
> FPICK is apparently implemented on SwiftForth and VFX through an
> indirect branch that branches to one of 8 variants of "FLD ST(...)",
> while iForth manages to resolve this during compilation.
>

Good to see that x, y, z are not repeatedly fetched from memory.

For this example, the hardware fpu stack is sufficient. But, it's easy
to see that the benefits of a hardware-only stack would diminish quickly
as the size of the problem increased a small amount, and then the
programmer (or compiler) would have to keep careful track of how many
fpu registers are used.

> I have also looked at VFX 5.11 which uses XMM registers instead of the
> FP stack, but it does not inline FP operations, so you mostly see a long
> sequence of calls.
>

--
Krishna

On 4/14/24 15:02, Stephen Pelc wrote:
> On 14 Apr 2024 at 01:47:20 CEST, "Krishna Myneni" <krishna.myneni@ccreweb.org>
> wrote:
>
>> On 4/13/24 12:55, Anton Ertl wrote:
>>> I just looked at the floating-point implementations of recent
>>> SwiftForth and VFX (finally present in the system from the start), and
>>> on iForth-5.1-mini (for comparison):
....
>>>
>>> So apparently the 8 hardware FP stack items are enough for SwiftForth
>>> and VFX, while iForth prefers to use an FP stack in memory to allow
>>> for a deeper FP stack.
>>>
>> ...
>>
>> For me, an 8 item hardware fp stack limit is too limiting to be useful.
>> This is mostly because of my use of the fp stack for initializing tables
>> (arrays and matrices), and my coding style of returning more than 8
>> floats on the fp stack for some types of computation. No doubt one can
>> limit themselves to an 8-item fp stack, but I'd hate to have to code wit
>> such a limit.
>
> The manual (gasp) documents how to change the default FP package.
>

Good to know.

--
Krishna

On 15/04/2024 6:02 am, Stephen Pelc wrote:
> On 14 Apr 2024 at 01:47:20 CEST, "Krishna Myneni" <krishna.myneni@ccreweb.org>
> wrote:
>
>> On 4/13/24 12:55, Anton Ertl wrote:
>>> I just looked at the floating-point implementations of recent
>>> SwiftForth and VFX (finally present in the system from the start), and
>>> on iForth-5.1-mini (for comparison):
>>>
>>> 1 FLOATS .
>>>
>>> reports:
>>>
>>> 16 iforth
>>> 10 sf64
>>> 10 vfx64
>>>
>>> For
>>>
>>> : foo f+ f* ;
>>>
>>> the resulting code is:
>>>
>>> SwiftForth x64-Linux 4.0.0-RC87 24-Mar-2024
>>> : foo f+ f* ; ok
>>> see foo
>>> 44E8B9 ST(0) ST(1) FADDP DEC1
>>> 44E8BB ST(0) ST(1) FMULP DEC9
>>> 44E8BD RET C3 ok
>>>
>>>
>>> VFX Forth 64 5.43 [build 0199] 2023-11-09 for Linux x64
>>> © MicroProcessor Engineering Ltd, 1998-2023
>>>
>>> : foo f+ f* ; ok
>>> see foo
>>> FOO
>>> ( 0050A250 DEC1 ) FADDP ST(1), ST
>>> ( 0050A252 DEC9 ) FMULP ST(1), ST
>>> ( 0050A254 C3 ) RET/NEXT
>>> ( 5 bytes, 3 instructions )
>>>
>>>
>>> iForth:
>>> $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
>>>
>>> So apparently the 8 hardware FP stack items are enough for SwiftForth
>>> and VFX, while iForth prefers to use an FP stack in memory to allow
>>> for a deeper FP stack.
>>>
>> ...
>>
>> For me, an 8 item hardware fp stack limit is too limiting to be useful.
>> This is mostly because of my use of the fp stack for initializing tables
>> (arrays and matrices), and my coding style of returning more than 8
>> floats on the fp stack for some types of computation. No doubt one can
>> limit themselves to an 8-item fp stack, but I'd hate to have to code wit
>> such a limit.
>
> The manual (gasp) documents how to change the default FP package.
>
> Changing the default pack also changes the system call interfaces to
> match.

Specifically chapter 14 in the PDF doc.

integers
remove-FP-pack
include Lib/x64/Hfpx64

swaps in the 80-bit external stack model.

The HTML doc appears to lack this information (or hard to find) should a user
select that by mistake.

On 15/04/2024 1:53 am, Anton Ertl wrote:
> dxf <dxforth@gmail.com> writes:
>> On 14/04/2024 9:25 pm, Anton Ertl wrote:
>>> 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.
>>
>> The latter sounds like someone not getting his way more than a design mistake.
>> In the first reference Kahan states:
>>
>> "When the 8087 was designed, I knew that stack over/underflow was an issue of
>> more aesthetic than practical importance. I still regret that the 8087's stack
>> implementation was not quite so neat as my original intention described in the
>> accompanying note."
>>
>> Intel decided Kahan's aesthetic afterthought could be dispensed with.
>
> In a way, they did, and Kahan obviously did not get his way. But to
> me it sounds like they tried and failed at implementing a stack that
> extends into memory. The tags that indicate the presence of a stack
> item are there. If they had made a conscious decision at the start to
> dispense with the idea of an extensible stack, they would have
> discpensed with these bits indicating the presence of a stack item as
> well. So what happened is that they botched the first attempt, and
> then decided that they did not want to do what would have been
> necessary to fix it.

My impression is Palmer (the mathematician Intel hired to co-head the
project) was trying to placate Kahan and it fell through for various
reasons.

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.

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.

--
Krishna

In most cases 'bigger' fp data will be stored in memory anyhow,
which can be cached before disk access. The old 8087 improvements
were caused by its new fp operators, the stack was unusable.

And if CPU based stacks were so lucrative for high performance,
CPU makers would have implemented them since long for normal
integer data.

In article <3e419396b1ee93c7a391a7ffc0e44ed8@www.novabbs.com>,
minforth <minforth@gmx.net> wrote:
>In most cases 'bigger' fp data will be stored in memory anyhow,
>which can be cached before disk access. The old 8087 improvements
>were caused by its new fp operators, the stack was unusable.
>
>And if CPU based stacks were so lucrative for high performance,
>CPU makers would have implemented them since long for normal
>integer data.

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

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 -

albert@spenarnc.xs4all.nl wrote:

> In article <3e419396b1ee93c7a391a7ffc0e44ed8@www.novabbs.com>,
> minforth <minforth@gmx.net> wrote:
>>In most cases 'bigger' fp data will be stored in memory anyhow,
>>which can be cached before disk access. The old 8087 improvements
>>were caused by its new fp operators, the stack was unusable.
>>
>>And if CPU based stacks were so lucrative for high performance,
>>CPU makers would have implemented them since long for normal
>>integer data.

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

Both i.e. poor developer tool stack and strong AMD competition.
And it was overly complex.
https://softwareengineering.stackexchange.com/questions/279334/why-was-the-itanium-processor-difficult-to-write-a-compiler-for