Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #26523 > unrolled thread

Floating Point : To Stack or Not To Stack

Back to article view | Back to comp.lang.forth

Contents

  Floating Point : To Stack or Not To Stack rickman <gnuarm@gmail.com> - 2013-10-14 16:18 -0400
    Re: Floating Point : To Stack or Not To Stack "Elizabeth D. Rather" <erather@forth.com> - 2013-10-14 10:34 -1000
      Re: Floating Point : To Stack or Not To Stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-14 15:41 -0500
      Re: Floating Point : To Stack or Not To Stack Paul Rubin <no.email@nospam.invalid> - 2013-10-14 20:32 -0700
        Re: Floating Point : To Stack or Not To Stack rickman <gnuarm@gmail.com> - 2013-10-15 17:14 -0400
      Re: Floating Point : To Stack or Not To Stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-15 16:22 +0000
    Re: Floating Point : To Stack or Not To Stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-14 15:42 -0500
      Re: Floating Point : To Stack or Not To Stack Hans Bezemer <the.beez.speaks@gmail.com> - 2013-10-16 11:16 +0200
    Re: Floating Point : To Stack or Not To Stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-15 16:09 +0000
    Re: Floating Point : To Stack or Not To Stack krishna.myneni@ccreweb.org - 2013-10-15 18:51 -0700
      Re: Floating Point : To Stack or Not To Stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-16 03:47 -0500
      Re: Floating Point : To Stack or Not To Stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-16 12:27 +0000
        Re: Floating Point : To Stack or Not To Stack rickman <gnuarm@gmail.com> - 2013-10-25 14:20 -0400
          Re: Floating Point : To Stack or Not To Stack Paul Rubin <no.email@nospam.invalid> - 2013-10-25 12:08 -0700
            Re: Floating Point : To Stack or Not To Stack rickman <gnuarm@gmail.com> - 2013-10-26 02:34 -0400
              Re: Floating Point : To Stack or Not To Stack Paul Rubin <no.email@nospam.invalid> - 2013-10-26 00:13 -0700
                Re: Floating Point : To Stack or Not To Stack "Elizabeth D. Rather" <erather@forth.com> - 2013-10-25 21:49 -1000
                  Re: Floating Point : To Stack or Not To Stack Paul Rubin <no.email@nospam.invalid> - 2013-10-26 01:26 -0700
                  Re: Floating Point : To Stack or Not To Stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-26 05:45 -0500
                    Re: Floating Point : To Stack or Not To Stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-26 13:48 +0000
                      Re: Floating Point : To Stack or Not To Stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-26 14:28 -0500
                        Re: Floating Point : To Stack or Not To Stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-27 12:41 +0000
                          Re: Floating Point : To Stack or Not To Stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-27 08:31 -0500
                            ?DUP (was: Floating Point : To Stack or Not To Stack) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-28 15:19 +0000
                              Re: ?DUP Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-28 13:54 -0500
                                Re: ?DUP "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-10-28 16:30 -0400
                                  Re: ?DUP "Elizabeth D. Rather" <erather@forth.com> - 2013-10-28 11:11 -1000
                                Re: ?DUP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-29 11:51 +0000
                                  Re: ?DUP Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-29 16:48 +0100
                                    Re: ?DUP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-29 16:10 +0000
                                    Re: ?DUP albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-29 16:24 +0000
                                      Re: ?DUP Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-29 20:00 +0100
                                        Re: ?DUP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-30 07:44 +0000
                                  Re: ?DUP Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-29 16:29 -0500
                                    Re: ?DUP "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-10-29 18:58 -0400
                                      Re: ?DUP Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-30 03:15 -0500
                                    Re: ?DUP albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-30 01:14 +0000
                                    Re: ?DUP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-30 08:22 +0000
                                      Re: ?DUP "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-10-30 08:03 -0400
                                        Re: ?DUP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-30 12:24 +0000
                                      Re: ?DUP Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-30 12:44 -0500
                                        Re: ?DUP "Alex McDonald" <blog@rivadpm.com> - 2013-10-30 22:43 +0000
                                        Re: ?DUP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-31 12:09 +0000
                                          Re: ?DUP Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-31 12:23 -0500
                              Re: ?DUP (was: Floating Point : To Stack or Not To Stack) "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-10-28 16:30 -0400
                                Re: ?DUP "Elizabeth D. Rather" <erather@forth.com> - 2013-10-28 11:16 -1000
                                  Re: ?DUP Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-29 01:58 +0100
                                    Re: ?DUP Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2013-10-28 18:41 -0700
                                    Re: ?DUP Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-29 04:37 -0500
                                      Re: ?DUP m.a.m.hendrix@tue.nl - 2013-10-29 04:27 -0700
                                      Re: ?DUP anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-29 12:51 +0000
                Re: Floating Point : To Stack or Not To Stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-26 09:45 +0000
                  Re: Floating Point : To Stack or Not To Stack albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-26 11:30 +0000
                    Re: Floating Point : To Stack or Not To Stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-26 08:05 -0500
                    Re: Floating Point : To Stack or Not To Stack mhx@iae.nl - 2013-10-26 06:09 -0700
                      Re: Floating Point : To Stack or Not To Stack "Rod Pemberton" <dont_use_email@nohavenotit.com> - 2013-10-27 03:01 -0400
                        Re: Floating Point : To Stack or Not To Stack "Elizabeth D. Rather" <erather@forth.com> - 2013-10-26 22:23 -1000
              Re: Floating Point : To Stack or Not To Stack albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-26 09:39 +0000
                Re: Floating Point : To Stack or Not To Stack albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-26 09:44 +0000
    Re: Floating Point : To Stack or Not To Stack "Ed" <invalid@invalid.com> - 2013-10-18 14:09 +1000
      Re: Floating Point : To Stack or Not To Stack "Elizabeth D. Rather" <erather@forth.com> - 2013-10-17 21:21 -1000
        Re: Floating Point : To Stack or Not To Stack "Ed" <invalid@invalid.com> - 2013-10-19 12:14 +1000
          Re: Floating Point : To Stack or Not To Stack "Elizabeth D. Rather" <erather@forth.com> - 2013-10-18 17:17 -1000
            Re: Floating Point : To Stack or Not To Stack Paul Rubin <no.email@nospam.invalid> - 2013-10-19 02:58 -0700
            Re: Floating Point : To Stack or Not To Stack "Ed" <invalid@invalid.com> - 2013-10-27 22:33 +1100
              Re: Floating Point : To Stack or Not To Stack mhx@iae.nl - 2013-10-27 06:21 -0700
                Re: Floating Point : To Stack or Not To Stack "Ed" <invalid@invalid.com> - 2013-10-29 22:40 +1100
              Re: Floating Point : To Stack or Not To Stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-27 08:23 -0500
    Re: Floating Point : To Stack or Not To Stack Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2013-10-28 18:38 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#26523 — Floating Point : To Stack or Not To Stack

That is the question...

I have read the floating point section of the DPANS document a couple of 
times and I am still unclear about the floating point stack.  No, I am 
clear about the stack, I'm not clear on how to write code that does not 
*assume* the presence or absence of the floating point stack.

Obviously if you keep all floating point calculations distinct from 
other stack operations it won't matter.  But that is not so easy in most 
apps, no?

How do people use floating point calculations in Forth?  Do they write 
with an assumption about the presence of a floating point stack?  Or is 
there a way to code that does not make any assumptions about this?

-- 

Rick

[toc] | [next] | [standalone]

#26524

On 10/14/13 10:18 AM, rickman wrote:
> That is the question...
>
> I have read the floating point section of the DPANS document a couple of
> times and I am still unclear about the floating point stack.  No, I am
> clear about the stack, I'm not clear on how to write code that does not
> *assume* the presence or absence of the floating point stack.
>
> Obviously if you keep all floating point calculations distinct from
> other stack operations it won't matter.  But that is not so easy in most
> apps, no?
>
> How do people use floating point calculations in Forth?  Do they write
> with an assumption about the presence of a floating point stack?  Or is
> there a way to code that does not make any assumptions about this?
>

People pretty much ignore the possibility of there not being a FP stack. 
The allowance of integrated stacks was put in DPANS as a courtesy to 
Harris Corp, whose RTX Forth chip didn't have one. I don't know of any 
modern Forths that use an integrated FP stack.

I don't actually know if Forth20xx has removed that language or not, but 
it would be a reasonable thing to do.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#26525

Elizabeth D. Rather <erather@forth.com> wrote:
> 
> People pretty much ignore the possibility of there not being a FP stack. 
> The allowance of integrated stacks was put in DPANS as a courtesy to 
> Harris Corp, whose RTX Forth chip didn't have one. I don't know of any 
> modern Forths that use an integrated FP stack.
> 
> I don't actually know if Forth20xx has removed that language or not, but 
> it would be a reasonable thing to do.

We did.

Andrew.

[toc] | [prev] | [next] | [standalone]

#26538

"Elizabeth D. Rather" <erather@forth.com> writes:
> I don't know of any modern Forths that use an integrated FP stack.

There's a new AmForth FP extension has an integrated stack.  Maybe the
author didn't know any better and can be talked out of it.

https://mywebspace.wisc.edu/lnmaurer/web/FloatingAway/FloatingAway.html :

    It uses the same stack for floating-point numbers as for integers
    and other data. I believe this is allowed by the ANS standard, but
    it isn’t ideal. 

[toc] | [prev] | [next] | [standalone]

#26566

On 10/14/2013 11:32 PM, Paul Rubin wrote:
> "Elizabeth D. Rather"<erather@forth.com>  writes:
>> I don't know of any modern Forths that use an integrated FP stack.
>
> There's a new AmForth FP extension has an integrated stack.  Maybe the
> author didn't know any better and can be talked out of it.
>
> https://mywebspace.wisc.edu/lnmaurer/web/FloatingAway/FloatingAway.html :
>
>      It uses the same stack for floating-point numbers as for integers
>      and other data. I believe this is allowed by the ANS standard, but
>      it isn’t ideal.

The thread on AMForth was what made me think of this.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#26561

"Elizabeth D. Rather" <erather@forth.com> writes:
>I don't actually know if Forth20xx has removed that language or not, but 
>it would be a reasonable thing to do.

You no longer have to declare an environmental dependency on a
separate FP stack.  The language is not as clear as I would wish,
though.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#26526

rickman <gnuarm@gmail.com> wrote:
> That is the question...
> 
> I have read the floating point section of the DPANS document a couple of 
> times and I am still unclear about the floating point stack.  No, I am 
> clear about the stack, I'm not clear on how to write code that does not 
> *assume* the presence or absence of the floating point stack.

It's almost impossible.  Don't bother trying.

Andrew.

[toc] | [prev] | [next] | [standalone]

#26577

Andrew Haley wrote:
>> I have read the floating point section of the DPANS document a couple of
>> times and I am still unclear about the floating point stack.  No, I am
>> clear about the stack, I'm not clear on how to write code that does not
>> *assume* the presence or absence of the floating point stack.
> It's almost impossible.  Don't bother trying.
Maintaining a compiler that has *BOTH* there are several libraries that
support both architectures. Agreed, it is a bit awkward, but doable if you
are willing to apply some rules:
- Never assume FP numbers can reside on the return stack;
- Keep the FP numbers below the integers on the data stack as much as
possible;
- Consume integers first when dealing with words with a mixed stack diagram;
- If you need to access FP numbers while there are still integers on the
stack, move the integers to the return stack;
- Never manipulate a mix of FP numbers or integers with either integer stack
operators or FP stack operators.

I'm sure this list is not exhaustive, but it helps ;-) Note those rules
work, but are by no means any guarantee for very beautiful code.

Small example here:

struct
  field:       st_count
  float +field st_sum
  float +field st_qsum
  float +field st_rsum
  float +field st_prod
  float +field st_mean
  float +field st_nvar
end-struct /st_var

: f+! ( x addr -- ) dup >r f@ f+ r> f! ;
: st.variance ( stats -- var ) dup >r -> st_nvar f@ r> -> st_count @ s>f
f/ ;
: st.amean ( stats -- amean )  dup >r -> st_sum  f@ r> -> st_count @ s>f
f/ ;
: st.hmean ( stats -- hmean )  dup >r -> st_count @ s>f r> -> st_rsum f@
f/ ;
: st.rms ( stats -- rms ) dup >r -> st_qsum f@ r> -> st_count @ s>f f/
fsqrt ;
: st.stddev ( stats -- stddev ) st.variance fsqrt ;
: st.gmean dup >r -> st_prod f@ 1 s>f r> -> st_count @ s>f f/ f** ;
                                        ( stats -- gmean )
: st.clear
  >r 0 dup r@ -> st_count ! s>f
  fdup r@ -> st_sum  f!
  fdup r@ -> st_qsum f!
  fdup r@ -> st_rsum f!
  fdup r@ -> st_mean f!
  r@ -> st_nvar f! 1 s>f
  r> -> st_prod f! ;
 
: st.add ( x stats -- )
  >r 1 dup r@ -> st_count +!           \ update count
  s>f fover f/ r@ -> st_rsum f+!       \ update reciproke sum
  fdup r@ -> st_prod dup >r f@ f* r> f!
  fdup fdup f* r@ -> st_qsum f+!       \ update square sum
  fdup r@ -> st_sum f+!                \ update sum
  fdup r@ -> st_mean f@ f- fswap       ( delta x )
  fover r@ -> st_count @ s>f f/        ( delta x delta/n )
  r@ -> st_mean dup >r f+!             \ update mean ( delta x )
  r> f@ f- f* r> -> st_nvar f+! ;

Hans Bezemer

[toc] | [prev] | [next] | [standalone]

#26560

rickman <gnuarm@gmail.com> writes:
>That is the question...
>
>I have read the floating point section of the DPANS document a couple of 
>times and I am still unclear about the floating point stack.  No, I am 
>clear about the stack, I'm not clear on how to write code that does not 
>*assume* the presence or absence of the floating point stack.

The way to do that is to keep FP values in memory nearly all of the
time.  Only F@ them onto the FP/data stack right before the FP
operation, and F! it from the FP/data stack to memory right
afterwards.

On those platforms which use the data stack for FP for supposedly
performance reasons the resulting code is not any faster than
implementing a separate FP stack and running code written for that,
but it's much less convenient for the programmers.

>How do people use floating point calculations in Forth?  Do they write 
>with an assumption about the presence of a floating point stack?

Yes.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#26572

On Monday, October 14, 2013 3:18:30 PM UTC-5, rickman wrote:
> That is the question...
> 
> 
> 
> I have read the floating point section of the DPANS document a couple of 
> 
> times and I am still unclear about the floating point stack.  No, I am 
> 
> clear about the stack, I'm not clear on how to write code that does not 
> 
> *assume* the presence or absence of the floating point stack.
> 
> 
> 
> Obviously if you keep all floating point calculations distinct from 
> 
> other stack operations it won't matter.  But that is not so easy in most 
> 
> apps, no?
> 
> 
> 
> How do people use floating point calculations in Forth?  Do they write 
> 
> with an assumption about the presence of a floating point stack?  Or is 
> 
> there a way to code that does not make any assumptions about this?
> 
> 

Rick,

I am a scientific user who uses an integrated floating point/data stack Forth system (kForth, which is my creation, with some contributions from others). Originally, I wanted a tool similar to LMI's UR/Forth, which I had used earlier on DOS systems. On modern desktop systems, with 32-bit/64-bit stack cell sizes, there is very little problem in writing and using floating point code for an integrated data/fp stack, with use of standard single or double precision arithmetic and functions. In my experience, it also takes very little effort also to write the code in a way that it is usable on separate data/fp stack systems. I have extensive experience as a scientific user to prove this out, despite some of the unnecessary hand-wringing you see here about combined stack systems.

Now, would I design a Forth system today using an integrated stack? I don't know. I don't use Forth on microcontroller or embedded device platforms, and, there, the motivation for separated stacks may be compelling. There may be also odd processor architectures requiring separated stacks, but on Intel/AMD and PPC processors, I have found no problems. There is also the question of efficiency, particularly if the FPU stack is used as the floating point stack. But, for the way I use floating point, I find that using the FPU stack as the Forth floating point stack is too restrictive (the depth is insufficient), even if it is an order of magnitude more efficient -- when I need that kind of efficiency, I will drop down to a lower level of programming such as CODE definitions.

To have a look at examples of fp code written for an integrated stack Forth (32-bit system, one standard double fp requires two cells on the data stack), see

http://ccreweb.org/software/kforth/kforth4.html


Cheers,
Krishna

[toc] | [prev] | [next] | [standalone]

#26574

krishna.myneni@ccreweb.org wrote:
> On Monday, October 14, 2013 3:18:30 PM UTC-5, rickman wrote:
>> That is the question...
>> 
>> I have read the floating point section of the DPANS document a couple of 
>> times and I am still unclear about the floating point stack.  No, I am 
>> clear about the stack, I'm not clear on how to write code that does not 
>> *assume* the presence or absence of the floating point stack.
>> 
>> Obviously if you keep all floating point calculations distinct from 
>> other stack operations it won't matter.  But that is not so easy in most 
>> apps, no?
>> 
>> How do people use floating point calculations in Forth?  Do they write 
>> with an assumption about the presence of a floating point stack?  Or is 
>> there a way to code that does not make any assumptions about this?
> 
> I am a scientific user who uses an integrated floating point/data
> stack Forth system (kForth, which is my creation, with some
> contributions from others). Originally, I wanted a tool similar to
> LMI's UR/Forth, which I had used earlier on DOS systems. On modern
> desktop systems, with 32-bit/64-bit stack cell sizes, there is very
> little problem in writing and using floating point code for an
> integrated data/fp stack, with use of standard single or double
> precision arithmetic and functions. In my experience, it also takes
> very little effort also to write the code in a way that it is usable
> on separate data/fp stack systems. I have extensive experience as a
> scientific user to prove this out, despite some of the unnecessary
> hand-wringing you see here about combined stack systems.

I'm very skeptical.  AFAIK there are only two practical ways to use a
Forth with combined stacks: either to assume that a floating-point
item occupies some fixed number of cells on the data stack or be
forced to use locals (or variables) to separate floating-point and
integer data.  The first option is nonportable, and the second is
unpleasant (and maybe non-reentrant).

An example (from Kforth's version of my Chebyshev code) is attached.
There are other examples of unnecessary stack shuffling in that file.

Andrew.


fvariable 2x
0 ptr a0
0 ptr aN

: fpstack? ( - n)   false ( s" FLOATING-STACK" environment?) ;

[defined] fpick fpstack? and [if]

: chebev ( a0 an) ( F: x - y)
    2.0e0 f*

    0.0e0 fdup
    begin
        ( b[r+2] b[r+1] )
        fdup  3 fpick f*
        frot f-
        dup f@ f+
        -1 floats +
    2dup = until  drop

    frot 2.0e0 f/ f*  fswap f-  f@ f+ ;

[else]

: chebev ( x a0 aN -- y)   \  ( a0 aN -- ) ( F: x - y)
    to aN  to a0
    2.0e0 f* 2x f!
    0.0e fdup
    a0 float+  aN do
	( b[r+2] b[r+1] )
	fdup  2x f@ f*
	frot f-
	i f@ f+
    -1 floats +loop
    2x f@ 2.0e0 f/ f*  fswap f-  a0 f@ f+
;

[then]

[toc] | [prev] | [next] | [standalone]

#26581

krishna.myneni@ccreweb.org writes:
>Now, would I design a Forth system today using an integrated stack? I don't=
> know. I don't use Forth on microcontroller or embedded device platforms, a=
>nd, there, the motivation for separated stacks may be compelling.

Well, Stephen Pelc argued that integrated stacks may be the wave of
the future for embedded systems, because there is some embedded ARM
with FP coming out (i.e., the Novix/RTX argument again).

The imagined motivation is to save the FP stack pointer and the memory
area for the FP stack.  But, if you have a good Forth compiler, you
need neither the FP stack pointer nor a memory area for the FP stack
(details below).  Actually, with such a compiler, you only need one
stack pointer and one memory area that contains data stack items, FP
stack items, return stack items, and locals.

Details: In the "typical programs" assumed above the stack depth is
always known statically to the compiler, i.e., no unbalanced IFs and
no loop bodies that consume more stack items than they produce or vice
versa.  Most programs do that already, so that's no big restriction.

A more problematic issue is EXECUTE and DEFER.  Here the program would
have to tell the compiler the stack effect of the called word in the
general case.  I think that an embedded systems programmer who uses FP
will find that much less cumbersome than to use the data stack for FP.

You can find a bit more on this in my PAF paper
<http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/ertl-paf.pdf>.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#26680

On 10/16/2013 8:27 AM, Anton Ertl wrote:
> krishna.myneni@ccreweb.org writes:
>> Now, would I design a Forth system today using an integrated stack? I don't=
>> know. I don't use Forth on microcontroller or embedded device platforms, a=
>> nd, there, the motivation for separated stacks may be compelling.
>
> Well, Stephen Pelc argued that integrated stacks may be the wave of
> the future for embedded systems, because there is some embedded ARM
> with FP coming out (i.e., the Novix/RTX argument again).

There are any number of ARM CPUs with floating point.  How does that 
require combined stacks?  Can't a floating point stack always be created 
in memory?  I'm not that familiar with the ARM instruction set, but it 
should support that easily.


> The imagined motivation is to save the FP stack pointer and the memory
> area for the FP stack.  But, if you have a good Forth compiler, you
> need neither the FP stack pointer nor a memory area for the FP stack
> (details below).  Actually, with such a compiler, you only need one
> stack pointer and one memory area that contains data stack items, FP
> stack items, return stack items, and locals.

Oh, I should have read further, lol.  Not sure I follow the "one stack 
pointer" concept though.


> Details: In the "typical programs" assumed above the stack depth is
> always known statically to the compiler, i.e., no unbalanced IFs and
> no loop bodies that consume more stack items than they produce or vice
> versa.  Most programs do that already, so that's no big restriction.

How do you define "typical programs"???  As you mention any stack effect 
done in a loop would not be known to the compiler.  Is that really "no 
big" restriction?


> A more problematic issue is EXECUTE and DEFER.  Here the program would
> have to tell the compiler the stack effect of the called word in the
> general case.  I think that an embedded systems programmer who uses FP
> will find that much less cumbersome than to use the data stack for FP.
>
> You can find a bit more on this in my PAF paper
> <http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/ertl-paf.pdf>.
>
> - anton


-- 

Rick

[toc] | [prev] | [next] | [standalone]

#26682

rickman <gnuarm@gmail.com> writes:
> How do you define "typical programs"???  As you mention any stack
> effect done in a loop would not be known to the compiler.  Is that
> really "no big" restriction?

In theory it's a drastic change, but in practice most programs don't put
stack effects in loops unless the effects are obviously balanced.

[toc] | [prev] | [next] | [standalone]

#26685

On 10/25/2013 3:08 PM, Paul Rubin wrote:
> rickman<gnuarm@gmail.com>  writes:
>> How do you define "typical programs"???  As you mention any stack
>> effect done in a loop would not be known to the compiler.  Is that
>> really "no big" restriction?
>
> In theory it's a drastic change, but in practice most programs don't put
> stack effects in loops unless the effects are obviously balanced.

Except for loops that put something on the stack and another loop that 
takes them off.  I am not experienced in Forth.  Is that uncommon?

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#26687

rickman <gnuarm@gmail.com> writes:
> Except for loops that put something on the stack and another loop that
> takes them off.  I am not experienced in Forth.  Is that uncommon?

I'm no Forth guru either, but yes it is uncommon, at least relatively
speaking, from what I can tell.  There are a few idioms like passing a
variable number of args to something that pops them with a loop, but I
think they are not used much.  There is a ?DUP word in the standard that
dups the TOS if and only if it is nonzero, but using it is considered
poor style these days.  So I think the restriction could cause some
backward compatibility problems with some existing code, but it
shouldn't get in the way too much when writing new code.  In my limited
experience the code feels out of control if I don't know what's on the
stack at every place in the program.

[toc] | [prev] | [next] | [standalone]

#26689

On 10/25/13 9:13 PM, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
>> Except for loops that put something on the stack and another loop that
>> takes them off.  I am not experienced in Forth.  Is that uncommon?

It's relatively uncommon, in my experience, but far from unheard of. 
There would be a lot of resistance to making it illegal, I think!

> I'm no Forth guru either, but yes it is uncommon, at least relatively
> speaking, from what I can tell.  There are a few idioms like passing a
> variable number of args to something that pops them with a loop, but I
> think they are not used much.  There is a ?DUP word in the standard that
> dups the TOS if and only if it is nonzero, but using it is considered
> poor style these days.  So I think the restriction could cause some
> backward compatibility problems with some existing code, but it
> shouldn't get in the way too much when writing new code.  In my limited
> experience the code feels out of control if I don't know what's on the
> stack at every place in the program.

I certainly haven't ever heard ?DUP considered "poor style". It often 
saves an otherwise unnecessary ELSE DROP clause (even though the 
equivalent has to actually exist in ?DUP), and hence improves 
readability and saves a few cells, depending on the implementation.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#26690

"Elizabeth D. Rather" <erather@forth.com> writes:
> I certainly haven't ever heard ?DUP considered "poor style". It often
> saves an otherwise unnecessary ELSE DROP clause

In the case of the ?DUP IF idiom, the stack contents are known
everywhere.  Gforth combines them into a single word ?DUP-IF.  Per the
manual,[1] "This is the preferred alternative to the idiom "?DUP IF",
since it can be better handled by tools like stack checkers. Besides,
it's faster."

[1] http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Arbitrary-control-structures.html

[toc] | [prev] | [next] | [standalone]

#26694

Elizabeth D. Rather <erather@forth.com> wrote:
> On 10/25/13 9:13 PM, Paul Rubin wrote:
>> rickman <gnuarm@gmail.com> writes:
>>> Except for loops that put something on the stack and another loop that
>>> takes them off.  I am not experienced in Forth.  Is that uncommon?
> 
> It's relatively uncommon, in my experience, but far from unheard of. 
> There would be a lot of resistance to making it illegal, I think!

I'm sure.

I know that Forth Inc's experience is that with few exceptions, Forth
programs really don't use very much data stack.  There are exceptions,
such as the famous flood-fill algorithm and quicksort that are
recursive algorithms which naturally code as loops in Forth.

>> I'm no Forth guru either, but yes it is uncommon, at least
>> relatively speaking, from what I can tell.  There are a few idioms
>> like passing a variable number of args to something that pops them
>> with a loop, but I think they are not used much.  There is a ?DUP
>> word in the standard that dups the TOS if and only if it is
>> nonzero, but using it is considered poor style these days.  So I
>> think the restriction could cause some backward compatibility
>> problems with some existing code, but it shouldn't get in the way
>> too much when writing new code.  In my limited experience the code
>> feels out of control if I don't know what's on the stack at every
>> place in the program.
> 
> I certainly haven't ever heard ?DUP considered "poor style".

That's suprising to me too.  ?DUP WHILE is natural and elegant when
iterating over lists, for example.

Andrew.

[toc] | [prev] | [next] | [standalone]

#26698

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>That's suprising to me too.  ?DUP WHILE is natural and elegant when
>iterating over lists, for example.

?DUP IF can save an ELSE DROP, and, depending on layout style,q up to
two lines.  So i can understand the urge to use ?DUP IF there.

?DUP WHILE only saves a DROP.  Natural and elegant?  Maybe in the
Bizarro World.

As for putting the burden on the compiler to correct for the
programmer's use of ?DUP: This is Forth.  We argue even about good
practices if they complicate the compiler.  Why should we complicate
the compiler for "?DUP"?  Better let the programmers fix the programs.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web