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

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

Stack Operator Symbols

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

Contents

  Stack Operator Symbols trans <transfire@gmail.com> - 2016-10-24 20:42 -0700
    Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-10-25 01:58 -0700
    Re: Stack Operator Symbols november.nihal@gmail.com - 2016-10-25 10:52 -0700
    Re: Stack Operator Symbols Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-10-27 19:13 -0400
      Re: Stack Operator Symbols "Elizabeth D. Rather" <erather@forth.com> - 2016-10-27 17:08 -1000
        Re: Stack Operator Symbols "HAA" <someone@microsoft.com> - 2016-10-28 21:53 +1000
          Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-10-28 20:42 -0700
            Re: Stack Operator Symbols Walter Banks <walter@bytecraft.com> - 2016-10-29 17:15 -0400
              Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-10-29 17:27 -0700
          Re: Stack Operator Symbols "Elizabeth D. Rather" <erather@forth.com> - 2016-10-28 20:56 -1000
        Re: Stack Operator Symbols Paul Rubin <no.email@nospam.invalid> - 2016-10-29 00:46 -0700
          Re: Stack Operator Symbols Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-29 04:30 -0500
            Re: Stack Operator Symbols rickman <gnuarm@gmail.com> - 2016-10-29 16:58 -0400
            Re: Stack Operator Symbols Paul Rubin <no.email@nospam.invalid> - 2016-10-29 14:21 -0700
              Re: Stack Operator Symbols Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-30 04:03 -0500
                Re: Stack Operator Symbols Paul Rubin <no.email@nospam.invalid> - 2016-10-30 18:06 -0700
                  Re: Stack Operator Symbols Spiros Bousbouras <spibou@gmail.com> - 2016-10-31 01:43 +0000
                    Re: Stack Operator Symbols Paul Rubin <no.email@nospam.invalid> - 2016-10-30 19:23 -0700
                      Re: Stack Operator Symbols Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-31 05:13 -0500
                        Re: Stack Operator Symbols albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-31 12:42 +0100
                        Re: Stack Operator Symbols anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-31 12:12 +0000
                          Re: Stack Operator Symbols anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-31 14:49 +0000
                            Re: Stack Operator Symbols mhx@iae.nl - 2016-10-31 13:17 -0700
                            Re: Stack Operator Symbols anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-03 16:38 +0000
                      Re: Stack Operator Symbols Spiros Bousbouras <spibou@gmail.com> - 2016-11-20 14:33 +0000
                  Re: Stack Operator Symbols anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-31 08:35 +0000
              Re: Stack Operator Symbols anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-30 11:01 +0000
                Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-10-30 10:01 -0700
              Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-11-03 14:46 -0700
                Re: Stack Operator Symbols anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-04 23:04 +0000
                  Re: Stack Operator Symbols Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-05 03:16 -0400
          Re: Stack Operator Symbols peter.m.falth@gmail.com - 2016-10-29 09:13 -0700
            Re: Stack Operator Symbols "HAA" <someone@microsoft.com> - 2016-10-30 08:47 +1100
              Re: Stack Operator Symbols trans <transfire@gmail.com> - 2016-10-29 14:57 -0700
                Re: Stack Operator Symbols "HAA" <someone@microsoft.com> - 2016-10-30 09:20 +1100
          Re: Stack Operator Symbols Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-10-29 18:46 -0400
            Re: Stack Operator Symbols Paul Rubin <no.email@nospam.invalid> - 2016-10-29 19:45 -0700
              Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-10-29 20:29 -0700
                Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-10-29 20:47 -0700
                  Re: Stack Operator Symbols Cecil Bayona <cbayona@cbayona.com> - 2016-10-29 23:15 -0500
                    Re: Stack Operator Symbols "Elizabeth D. Rather" <erather@forth.com> - 2016-10-29 21:37 -1000
                      Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-10-30 10:07 -0700
              Re: Stack Operator Symbols "Elizabeth D. Rather" <erather@forth.com> - 2016-10-29 21:35 -1000
                Re: Stack Operator Symbols "HAA" <someone@microsoft.com> - 2016-10-31 13:11 +1100
                  Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-10-30 20:02 -0700
                  Re: Stack Operator Symbols "Elizabeth D. Rather" <erather@forth.com> - 2016-10-30 22:08 -1000
                  Re: Stack Operator Symbols anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-31 09:02 +0000
                    Re: Stack Operator Symbols "HAA" <someone@microsoft.com> - 2016-11-03 20:49 +1100
                      Re: Stack Operator Symbols anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-03 15:33 +0000
                        Re: Stack Operator Symbols Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-03 16:55 -0400
                          Re: Stack Operator Symbols anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-03 22:21 +0000
    Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-10-27 20:31 -0700
      Re: Stack Operator Symbols november.nihal@gmail.com - 2016-10-28 09:52 -0700
        Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-10-28 20:32 -0700
    Re: Stack Operator Symbols Mark Wills <markwills1970@gmail.com> - 2016-10-30 04:49 -0700
      Re: Stack Operator Symbols Coos Haak <htrofhc@gmail.com> - 2016-10-30 14:49 +0100
        Re: Stack Operator Symbols Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2016-10-31 13:31 +0100
          Re: Stack Operator Symbols Coos Haak <htrofhc@gmail.com> - 2016-10-31 14:12 +0100
            Re: Stack Operator Symbols Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2016-10-31 15:03 +0100
          Re: Stack Operator Symbols Mark Wills <markwills1970@gmail.com> - 2016-11-03 14:22 -0700
            Re: Stack Operator Symbols Coos Haak <htrofhc@gmail.com> - 2016-11-04 00:46 +0100
          Re: Stack Operator Symbols "HAA" <someone@microsoft.com> - 2016-11-05 13:14 +1100
      Re: Stack Operator Symbols trans <transfire@gmail.com> - 2016-10-30 06:50 -0700
        Re: Stack Operator Symbols trans <transfire@gmail.com> - 2016-10-30 08:56 -0700
        Re: Stack Operator Symbols albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-30 18:19 +0100

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

#52178 — Stack Operator Symbols

I was looking at various Unicode symbols today[1], and noticing that there are symbols for Arithmetic, Calculus, Logic, Set Theory, even Music. Stack manipulation seems pretty fundamental to me. I wonder why standard symbols have never been put forth for them?

Of course, what are the fundamental stack operations? 

A paper called Stack Quarks by Rob Chapman[2] gives one way to look at it, though it is very hardware oriented. He gives six elemental operations which can be combined to make the operations we use in Forth. For example, a DROP is DIP NIP, and DUP is a NUP DRIP. But I don't see how he accounts for, say, swapping the NOS and the top of the remaining stack (the third item).

In any case, the operations from a coder's perspective are probably the more pertinent operations for a symbolic notation, the fundamental operations seem to me to be:

    drop
    dup
    swap
    push (>r)
    pull (r>)

With these five I think all others are possible. Do you agree?

And if we were to assign a standard set of operator symbols to the fundamental stack manipulators, what do you think they should be?

[1] https://en.wikibooks.org/wiki/Unicode/List_of_useful_symbols
[2] http://clubweb.interbaun.com/~rc/Timbre/ContentPages/Timbre/SQP/StackQuarksPaper.html

[toc] | [next] | [standalone]

#52181

On Monday, October 24, 2016 at 8:43:00 PM UTC-7, trans wrote:
> I was looking at various Unicode symbols today[1], and noticing that there are symbols for Arithmetic, Calculus, Logic, Set Theory, even Music. Stack manipulation seems pretty fundamental to me. I wonder why standard symbols have never been put forth for them?
> 
> Of course, what are the fundamental stack operations? 
> 
> A paper called Stack Quarks by Rob Chapman[2] gives one way to look at it, though it is very hardware oriented. He gives six elemental operations which can be combined to make the operations we use in Forth. For example, a DROP is DIP NIP, and DUP is a NUP DRIP. But I don't see how he accounts for, say, swapping the NOS and the top of the remaining stack (the third item).
> 
> In any case, the operations from a coder's perspective are probably the more pertinent operations for a symbolic notation, the fundamental operations seem to me to be:
> 
>     drop
>     dup
>     swap
>     push (>r)
>     pull (r>)
> 
> With these five I think all others are possible. Do you agree?
> 
> And if we were to assign a standard set of operator symbols to the fundamental stack manipulators, what do you think they should be?
> 
> [1] https://en.wikibooks.org/wiki/Unicode/List_of_useful_symbols
> [2] http://clubweb.interbaun.com/~rc/Timbre/ContentPages/Timbre/SQP/StackQuarksPaper.html

You should ask this guy:
https://groups.google.com/forum/#!searchin/comp.lang.forth/heart%7Csort:date/comp.lang.forth/AtEWzxgrUEg/sngIhwHxPEwJ

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

#52199

Assuming you dont care about speed and implementation how about drop, pick and roll.

NN

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

#52254

On Mon, 24 Oct 2016 20:42:59 -0700 (PDT)
trans <transfire@gmail.com> wrote:

> A paper called Stack Quarks by Rob Chapman[2] gives one way to look
> at it, though it is very hardware oriented. He gives six elemental
> operations which can be combined to make the operations we use in
> Forth. For example, a DROP is DIP NIP, and DUP is a NUP DRIP. But I
> don't see how he accounts for, say, swapping the NOS and the top of
> the remaining stack (the third item).

: NIP SWAP DROP ;
: TUCK SWAP OVER ;
: NUP OVER SWAP ;
: DIP DROP DUP ;
: TAKE DROP SWAP ;
: DRIP SWAP DIP ;

> Of course, what are the fundamental stack operations? 
> [...]
> In any case, the operations from a coder's perspective are probably
> the more pertinent operations for a symbolic notation, the
> fundamental operations seem to me to be:
> 
>     drop
>     dup
>     swap
>     push (>r)
>     pull (r>)
> 
> With these five I think all others are possible. Do you agree?

Generally, you need DUP DROP SWAP >R R> to create the other
single-cell stack operators, efficiently.  Likewise, it's more efficient
for double-cell operators if you have 2DUP DROP 2SWAP 2>R 2R> available.
However, all the double-cell operators can be created using single-cell
operators DUP DROP SWAP >R R> .  Unfortunately, the length of some these
double-cell definitions can become very long, e.g., 18 to 22, when
using single-cell operations.

Alternately, you can use PICK ROLL -ROLL SWAP DROP.  Note that PICK
ROLL -ROLL take a size argument.


Rod Pemberton

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

#52259

On 10/27/16 1:13 PM, Rod Pemberton wrote:
> On Mon, 24 Oct 2016 20:42:59 -0700 (PDT)
> trans <transfire@gmail.com> wrote:
>
>> A paper called Stack Quarks by Rob Chapman[2] gives one way to look
>> at it, though it is very hardware oriented. He gives six elemental
>> operations which can be combined to make the operations we use in
>> Forth. For example, a DROP is DIP NIP, and DUP is a NUP DRIP. But I
>> don't see how he accounts for, say, swapping the NOS and the top of
>> the remaining stack (the third item).
>
> : NIP SWAP DROP ;
> : TUCK SWAP OVER ;
> : NUP OVER SWAP ;
> : DIP DROP DUP ;
> : TAKE DROP SWAP ;
> : DRIP SWAP DIP ;

In my experience, only the first 3 are really useful.

>> Of course, what are the fundamental stack operations?
>> [...]
>> In any case, the operations from a coder's perspective are probably
>> the more pertinent operations for a symbolic notation, the
>> fundamental operations seem to me to be:
>>
>>     drop
>>     dup
>>     swap
>>     push (>r)
>>     pull (r>)

Not much to be gained by synonyms for >R and R>.

>> With these five I think all others are possible. Do you agree?
>
> Generally, you need DUP DROP SWAP >R R> to create the other
> single-cell stack operators, efficiently.  Likewise, it's more efficient
> for double-cell operators if you have 2DUP DROP 2SWAP 2>R 2R> available.
> However, all the double-cell operators can be created using single-cell
> operators DUP DROP SWAP >R R> .  Unfortunately, the length of some these
> double-cell definitions can become very long, e.g., 18 to 22, when
> using single-cell operations.

Any implementation that cares anything about performance will define the 
basic 2's operators as primitives.

> Alternately, you can use PICK ROLL -ROLL SWAP DROP.  Note that PICK
> ROLL -ROLL take a size argument.

I wrote Forth professionally for 30 years without using PICK, ROLL, or 
-ROLL, suffering zero inconvenience.

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]

#52265

Elizabeth D. Rather wrote:
> ...
> I wrote Forth professionally for 30 years without using PICK, ROLL, or
> -ROLL, suffering zero inconvenience.
>
> Cheers,
> Elizabeth

Yet SwiftForth found uses for all of them :)

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

#52281

On Friday, October 28, 2016 at 3:53:39 AM UTC-7, HAA wrote:
> Elizabeth D. Rather wrote:
> > ...
> > I wrote Forth professionally for 30 years without using PICK, ROLL, or
> > -ROLL, suffering zero inconvenience.
> >
> > Cheers,
> > Elizabeth
> 
> Yet SwiftForth found uses for all of them :)

SwiftForth was written by Rick van Norman --- Elizabeth Rather has never written any Forth code in her entire life --- she is a sales-person, not a programmer.

Most likely Rick van Norman had no prior Forth experience --- a lot of weird things about SwiftForth (such as ALIGN and ALIGNED being no-ops) indicate that he didn't have any prior assembly-language experience either --- afaik, after writing SwiftForth he abandoned Forth and went back to whatever work it was that he normally did.

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

#52290

On 2016-10-28 11:42 PM, hughaguilar96@gmail.com wrote:
> On Friday, October 28, 2016 at 3:53:39 AM UTC-7, HAA wrote:
>> Elizabeth D. Rather wrote:
>>> ... I wrote Forth professionally for 30 years without using PICK,
>>> ROLL, or -ROLL, suffering zero inconvenience.
>>>
>>> Cheers, Elizabeth
>>
>> Yet SwiftForth found uses for all of them :)
>
> SwiftForth was written by Rick van Norman --- Elizabeth Rather has
> never written any Forth code in her entire life --- she is a
> sales-person, not a programmer.
>
> Most likely Rick van Norman had no prior Forth experience --- a lot
> of weird things about SwiftForth (such as ALIGN and ALIGNED being
> no-ops) indicate that he didn't have any prior assembly-language
> experience either --- afaik, after writing SwiftForth he abandoned
> Forth and went back to whatever work it was that he normally did.
>
  Rick must have done something right his code generated more revenue
than yours.

w..

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

#52299

On Saturday, October 29, 2016 at 2:15:46 PM UTC-7, Walter Banks wrote:
> On 2016-10-28 11:42 PM, hughaguilar96@gmail.com wrote:
> > On Friday, October 28, 2016 at 3:53:39 AM UTC-7, HAA wrote:
> >> Elizabeth D. Rather wrote:
> >>> ... I wrote Forth professionally for 30 years without using PICK,
> >>> ROLL, or -ROLL, suffering zero inconvenience.
> >>>
> >>> Cheers, Elizabeth
> >>
> >> Yet SwiftForth found uses for all of them :)
> >
> > SwiftForth was written by Rick van Norman --- Elizabeth Rather has
> > never written any Forth code in her entire life --- she is a
> > sales-person, not a programmer.
> >
> > Most likely Rick van Norman had no prior Forth experience --- a lot
> > of weird things about SwiftForth (such as ALIGN and ALIGNED being
> > no-ops) indicate that he didn't have any prior assembly-language
> > experience either --- afaik, after writing SwiftForth he abandoned
> > Forth and went back to whatever work it was that he normally did.
> >
>   Rick must have done something right his code generated more revenue
> than yours.
> 
> w..

What makes you think that SwiftForth has generated more revenue than MFX? You are buying into Elizabeth Rather's sales pitch blindly. All of Testra's motion-control boards are programmed in MFX, and have been for about a quarter century now. How many motion-control boards has Forth Inc. built and sold? None! They know nothing about the subject.

Also, note that SwiftForth is just a scam --- Forth Inc. sold SwiftForth version-2 to me for over $400 and it was so bug-ridden as to be worthless, so my money was lost --- I don't think that scamming customers really counts as "generating revenue."

Since you are a big fan of Rick van Norman, why don't you ask him why (LOCAL) crashes SwiftForth version-2 every time that it is used? And, since you are a big fan of Elizabeth Rather, why don't you ask her why she requires SwiftForth version-2 owners to pay an additional $300 to get SwiftForth version-3 in which this bug is fixed? The answer in both cases is: "SwiftForth is just a scam --- we sell bug-ridden crap to the customers and then demand more money to get a bug-fix version --- and that version is bug-ridden crap too!"

Here is a thought:
You should hire Rick van Norman at ByteCraft to write your compiler for you --- then your products can be total crap too --- but if you also hire Elizabeth Rather to do your marketing, you should be able to boost your revenue.

Forget about selling a quality product --- generate revenue the old-fashioned way --- scam your customers!

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

#52282

On 10/28/16 1:53 AM, HAA wrote:
> Elizabeth D. Rather wrote:
>> ...
>> I wrote Forth professionally for 30 years without using PICK, ROLL, or
>> -ROLL, suffering zero inconvenience.
>>
>> Cheers,
>> Elizabeth
>
> Yet SwiftForth found uses for all of them :)

Mostly, we found a demand for them.

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]

#52283

"Elizabeth D. Rather" <erather@forth.com> writes:
> I wrote Forth professionally for 30 years without using PICK, ROLL, or
> -ROLL, suffering zero inconvenience.

I needed a 3DUP word recently, and wrote something like:

   : 3dup ( a b c -- a b c a b c ) >r 2dup r@ -rot r> ;

Later I saw someone else's implementation:

   : 3dup ( a b c -- a b c a b c ) 2 pick 2 pick 2 pick ;

which I thought was much more symmetric and natural.  Of course for
non-purists,

   : 3dup { a b c } a b c a b c ;

is the simplest of all.

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

#52285

Paul Rubin <no.email@nospam.invalid> wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> I wrote Forth professionally for 30 years without using PICK, ROLL, or
>> -ROLL, suffering zero inconvenience.
> 
> I needed a 3DUP word recently, and wrote something like:
> 
>   : 3dup ( a b c -- a b c a b c ) >r 2dup r@ -rot r> ;
> 
> Later I saw someone else's implementation:
> 
>   : 3dup ( a b c -- a b c a b c ) 2 pick 2 pick 2 pick ;
> 
> which I thought was much more symmetric and natural.  Of course for
> non-purists,
> 
>   : 3dup { a b c } a b c a b c ;
> 
> is the simplest of all.

I might write

icode 3dup ( x1 x2 x3 -- x1 x2 x3 x1 x2 x3 )
   push(ebx)
   2 cells [ebp] ebx mov
   push(ebx)
   2 cells [ebp] ebx mov
   push(ebx)
   2 cells [ebp] ebx mov
   ret end-code

and maybe Elizabeth would too.  Mind you, first I'd try to understand
how I got into a situation which needed 3DUP.

Andrew.

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

#52289

On 10/29/2016 5:30 AM, Andrew Haley wrote:
> Paul Rubin <no.email@nospam.invalid> wrote:
>> "Elizabeth D. Rather" <erather@forth.com> writes:
>>> I wrote Forth professionally for 30 years without using PICK, ROLL, or
>>> -ROLL, suffering zero inconvenience.
>>
>> I needed a 3DUP word recently, and wrote something like:
>>
>>   : 3dup ( a b c -- a b c a b c ) >r 2dup r@ -rot r> ;
>>
>> Later I saw someone else's implementation:
>>
>>   : 3dup ( a b c -- a b c a b c ) 2 pick 2 pick 2 pick ;
>>
>> which I thought was much more symmetric and natural.  Of course for
>> non-purists,
>>
>>   : 3dup { a b c } a b c a b c ;
>>
>> is the simplest of all.
>
> I might write
>
> icode 3dup ( x1 x2 x3 -- x1 x2 x3 x1 x2 x3 )
>    push(ebx)
>    2 cells [ebp] ebx mov
>    push(ebx)
>    2 cells [ebp] ebx mov
>    push(ebx)
>    2 cells [ebp] ebx mov
>    ret end-code
>
> and maybe Elizabeth would too.  Mind you, first I'd try to understand
> how I got into a situation which needed 3DUP.

Too bad that only works on one line of processors.

-- 

Rick C

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

#52291

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> first I'd try to understand how I got into a situation which needed 3DUP.

I implemented the Tak function which is a widely used Lisp benchmark:

  https://en.wikipedia.org/wiki/Tak_(function)

I wrote a Gforth version with and without locals:

  : tak-locals { x y z -- n}
      y x >= if z else
          x 1- y z recurse
          y 1- z x recurse
          z 1- x y recurse
          recurse then ; 

  : 3dup ( a b c -- a b c a b c ) >r 2dup r@ -rot r> ;
  : tak ( x y z -- n ) 
      -rot 2dup <=
      if
          2drop ( z ) 
      else ( z x y )
          3dup rot 1- -rot recurse >r     \ tak (1- z) x y
          3dup 1- -rot recurse >r         \ tak (1- y) z x
          -rot 1- -rot recurse            \ tak (1- x) y z
          r> r> recurse
      then ;

  : run 18 12 6 tak cr . cr  ;

Using 3dup seems natural here.  Writing an asm version defeats the idea
of benchmarking Forth with this function.

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

#52306

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> first I'd try to understand how I got into a situation which needed 3DUP.
> 
> I implemented the Tak function which is a widely used Lisp benchmark:
> 
>  https://en.wikipedia.org/wiki/Tak_(function)

Oh, I see, so it's a way to benchmrk the speed of recursion: fair
enough.

> Using 3dup seems natural here.  Writing an asm version defeats the
> idea of benchmarking Forth with this function.

But there isn't much point benchmarking Forth with something that only
gets written in Forth as a benchmark, I would have thought.  To each
their own.  :-)

Andrew.

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

#52321

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> But there isn't much point benchmarking Forth with something that only
> gets written in Forth as a benchmark, I would have thought.  To each
> their own.  :-)

I compared it to some other languages.  Gforth was slower than C++ or
Luajit but faster than Python or regular Lua.  I have the timings around
here somewhere and can probably find and post them if anyone cares.

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

#52322

On Sun, 30 Oct 2016 18:06:31 -0700
Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> > But there isn't much point benchmarking Forth with something that only
> > gets written in Forth as a benchmark, I would have thought.  To each
> > their own.  :-)
> 
> I compared it to some other languages.  Gforth was slower than C++ or
> Luajit but faster than Python or regular Lua.  I have the timings around
> here somewhere and can probably find and post them if anyone cares.

I think "only gets written in Forth as a benchmark" was not meant as "the
benchmark only exists in Forth" but rather as "you wouldn't write code like
this in Forth for any other purpose than a benchmark".

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

#52323

Spiros Bousbouras <spibou@gmail.com> writes:
> "you wouldn't write code like this in Forth for any other purpose than
> a benchmark".

Would you code that function differently if it were for some purpose
other than benchmarking?

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

#52331

Paul Rubin <no.email@nospam.invalid> wrote:
> Spiros Bousbouras <spibou@gmail.com> writes:
>> "you wouldn't write code like this in Forth for any other purpose than
>> a benchmark".
> 
> Would you code that function differently if it were for some purpose
> other than benchmarking?

Perhaps.  To start with, the outermost recursive call could be turned
into a while loop and the args reordered to (z y x) to simplify stack
handling.  Also, the stack depth might be prohibitively large on some
systems, so maybe further action would be required.

Andrew.

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

#52334

In article <tMednQ-_iuzahIrFnZ2dnUU7-XednZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Paul Rubin <no.email@nospam.invalid> wrote:
>> Spiros Bousbouras <spibou@gmail.com> writes:
>>> "you wouldn't write code like this in Forth for any other purpose than
>>> a benchmark".
>>
>> Would you code that function differently if it were for some purpose
>> other than benchmarking?
>
>Perhaps.  To start with, the outermost recursive call could be turned
>into a while loop and the args reordered to (z y x) to simplify stack
>handling.  Also, the stack depth might be prohibitively large on some
>systems, so maybe further action would be required.

In early versions of ciforth I had it in the blocks as an example.
I remember that there were about a dozen versions as the requirements
do not fix the implementation.

It could be informative if somebody took the trouble (as Anton Ertl
sometimes does) to have a table with the timing for different
Forths and source formulations.

As long as speed differences are below 30% I would not give much
attention to the results however.

>
>Andrew.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

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

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

csiph-web