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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#52305

On 10/29/16 6:15 PM, Cecil Bayona wrote:
> On 10/29/2016 10:47 PM, hughaguilar96@gmail.com wrote:
>> On Saturday, October 29, 2016 at 8:29:24 PM UTC-7, hughag...@gmail.com
>> wrote:
>>> Forth-200x is all about supporting Forth Inc. and MPE --- they are
>>> not supporting the Forth community --- they are actively crippling
>>> the standard for the purpose of preventing the Forth community from
>>> writing Forth programs that are standard.
>>
>> Elizabeth Rather says this:
>> ---------------------------
>> I hate locals :-)
>> ---------------------------
>>
>> Elizabeth Rather's ANS-Forth provides LOCALS| for defining multiple
>> locals, but the parameters are backwards. How could anybody be so dumb
>> as to get the parameters backwards??? I think she purposely crippled
>> LOCALS| because she hates local variables and she wants everybody to
>> hate them as much as she does.
>>
>> This strategy actually worked quite well. After I bought SwiftForth, I
>> went for several years writing Forth code and not using locals. The
>> parameters in LOCALS| are backwards, so it was useless (that would
>> really make the source-code confusing). Also, in SwiftForth version-2
>> (what I bought), the (LOCAL) definer would crash SwiftForth when it
>> was used. How does a bug like this get past the testers??? This is not
>> a subtle bug that occurs only under certain circumstances --- any use
>> of (LOCAL) crashes the system --- obviously, (LOCAL) was never tested
>> even once.
>>
>
> Didn't it come with the source so you can fix it? I bought SwiftForth
> Version 3 a long time ago and it came with the source, although I have
> not kept up with it is an older 3.2.1 version. One day I might get a one
> year maintenance so I can get the Linux and Mac versions which I don't
> have, but money is something I'm don't have in abundance.
>
> The reason I bought MPE VFX Professional Forth and VFX ARM Professional
> Forth with source is because things happen in life that one can't
> foresee, and after spending a lot of money I don't want to become
> stranded with expensive software that is no longer supported.
>
> MPE has a good deal with the free lite versions for ARM, and MSP430, it
> has limits but you can get a lot done within the limits, such as
> non-commercial use, and memory limits. They also have a demo version of
> VFX for Windows with some limits such as not being able to save the
> system image, and for non-commercial use only but those are minor limits.
>

Hugh had SwiftForth 2.x when last I checked, and all purchased versions 
do come with complete source.

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]

#52313

On Sunday, October 30, 2016 at 12:37:40 AM UTC-7, Elizabeth D. Rather wrote:
> On 10/29/16 6:15 PM, Cecil Bayona wrote:
> > On 10/29/2016 10:47 PM, hughaguilar96@gmail.com wrote:
> >> Elizabeth Rather's ANS-Forth provides LOCALS| for defining multiple
> >> locals, but the parameters are backwards. How could anybody be so dumb
> >> as to get the parameters backwards??? I think she purposely crippled
> >> LOCALS| because she hates local variables and she wants everybody to
> >> hate them as much as she does.
> >>
> >> This strategy actually worked quite well. After I bought SwiftForth, I
> >> went for several years writing Forth code and not using locals. The
> >> parameters in LOCALS| are backwards, so it was useless (that would
> >> really make the source-code confusing). Also, in SwiftForth version-2
> >> (what I bought), the (LOCAL) definer would crash SwiftForth when it
> >> was used. How does a bug like this get past the testers??? This is not
> >> a subtle bug that occurs only under certain circumstances --- any use
> >> of (LOCAL) crashes the system --- obviously, (LOCAL) was never tested
> >> even once.
> >
> > Didn't it come with the source so you can fix it? I bought SwiftForth
> > Version 3 a long time ago and it came with the source, although I have
> > not kept up with it is an older 3.2.1 version. One day I might get a one
> > year maintenance so I can get the Linux and Mac versions which I don't
> > have, but money is something I'm don't have in abundance.
> > ...
> 
> Hugh had SwiftForth 2.x when last I checked, and all purchased versions 
> do come with complete source.

Well, since you now welcome my bug-fixes, how about making my disambiguifiers standard?

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

#52304

On 10/29/16 4:45 PM, Paul Rubin wrote:
> Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> writes:
>> : 3DUP DUP 2OVER ROT ;
>
> Doh, I missed that one.  Nice.
>

This problem is in one of the introductory chapters of Forth 
Programmer's Handbook (see Amazon). The solution is posted online, but 
is a basic test of stack proficiency.


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]

#52324

Elizabeth D. Rather wrote:
> On 10/29/16 4:45 PM, Paul Rubin wrote:
> > Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> writes:
> >> : 3DUP DUP 2OVER ROT ;
> >
> > Doh, I missed that one.  Nice.
> >
>
> This problem is in one of the introductory chapters of Forth
> Programmer's Handbook (see Amazon). The solution is posted online, but
> is a basic test of stack proficiency.
>
>
> Cheers,
> Elizabeth

What is in the introductory chapters of Forth Programmer's Handbook?
There's certainly no mention of 3DUP.

It's possible to estimate which stack sequence is going to deliver the better
performance.  Counting instructions is a good start.  The definition quoted
above comprises 3 instructions, as does the PICK version, so they're going
to be close (and they are).  Moving things to/from the return stack isn't cheap
so avoid it unless it's saving a lot of juggling on the data stack.

'common sense' strategies for choosing code work for all but the fanciest
code generators like Peter's where there's a lot going on 'behind your back'.
I personally would have a problem with a Forth compiler that removed the
programmer from the equation.

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

#52325

On Sunday, October 30, 2016 at 7:28:04 PM UTC-7, HAA wrote:
> Elizabeth D. Rather wrote:
> > On 10/29/16 4:45 PM, Paul Rubin wrote:
> > > Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> writes:
> > >> : 3DUP DUP 2OVER ROT ;
> > >
> > > Doh, I missed that one.  Nice.
> > >
> >
> > This problem is in one of the introductory chapters of Forth
> > Programmer's Handbook (see Amazon). The solution is posted online, but
> > is a basic test of stack proficiency.
> 
> What is in the introductory chapters of Forth Programmer's Handbook?
> There's certainly no mention of 3DUP.
> 
> It's possible to estimate which stack sequence is going to deliver the better
> performance.  Counting instructions is a good start.  The definition quoted
> above comprises 3 instructions, as does the PICK version, so they're going
> to be close (and they are).  Moving things to/from the return stack isn't cheap
> so avoid it unless it's saving a lot of juggling on the data stack.

All of this is a waste of time (the programmer's time, I mean). I can figure out how to write 3DUP as shown above (what Paul Rubin described as "nice"), but I doubt that I'm any faster at figuring out these puzzles than the first-day student in Elizabeth Rather's class who just learned the stack-juggling words that morning. Telling students to write 3DUP as a "basic test of stack proficiency" reinforces the idea that Forth is "Sudoku for programmers" --- at the end of the day, they say: "Well, that was fun; we solved puzzles, and we wrote puzzles for others to solve! What does any of this have to do with writing programs though?"

> 'common sense' strategies for choosing code work for all but the fanciest
> code generators like Peter's where there's a lot going on 'behind your back'.
> I personally would have a problem with a Forth compiler that removed the
> programmer from the equation.

Well, I'm writing Straight Forth to do optimization --- it is ITC though, not STC, so it is a lot different than Peter's or Stephen's --- I tell the programmers what is idiomatic so everybody's programs look similar and are readable, and I write the optimizer so it generates efficient code for idiomatic source-code.

The programmer is "removed from the equation" in so much as the common-sense strategy (counting words) doesn't relate to efficiency at all --- the programmer doesn't choose strategies for optimization at all --- the programmer focuses his mind on writing application programs (that is what the boss is paying him to do).

If you want to puzzle over which definition of 3DUP is more efficient,
: 3dup  dup 2over rot ;
: 3dup  2 pick  2 pick  2 pick ;
then Straight Forth will not be a good choice for you --- stick with ANS-Forth --- pass Elizabeth Rather's "basic test of stack proficiency" and get an 'A' in her class.

Since I began designing Straight Forth, I have not given any thought to the subject of 3DUP --- this is the first that the subject has come up --- I still haven't given any thought to the subject (it is too tedious and boring to think about).

When I wrote the novice-package, I spent about one minute writing 3DUP and I just used the obvious method --- that is about 1/8 the amount of time that I have wasted on writing this post --- write 3DUP in the more complicated way if doing so makes you feel like a clever puzzle-solver; I don't care.

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

#52326

On 10/30/16 4:11 PM, HAA wrote:
> Elizabeth D. Rather wrote:
>> On 10/29/16 4:45 PM, Paul Rubin wrote:
>>> Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> writes:
>>>> : 3DUP DUP 2OVER ROT ;
>>>
>>> Doh, I missed that one.  Nice.
>>>
>>
>> This problem is in one of the introductory chapters of Forth
>> Programmer's Handbook (see Amazon). The solution is posted online, but
>> is a basic test of stack proficiency.
>>
>>
>> Cheers,
>> Elizabeth
>
> What is in the introductory chapters of Forth Programmer's Handbook?
> There's certainly no mention of 3DUP.

Terribly sorry, it's in Forth Application Techniques, not named "3DUP" 
but in a problem set asking you to write a word that, given 1 2 3 on the 
stack produces 1 2 3 1 2 3 .

> It's possible to estimate which stack sequence is going to deliver the better
> performance.  Counting instructions is a good start.  The definition quoted
> above comprises 3 instructions, as does the PICK version, so they're going
> to be close (and they are).  Moving things to/from the return stack isn't cheap
> so avoid it unless it's saving a lot of juggling on the data stack.
>
> 'common sense' strategies for choosing code work for all but the fanciest
> code generators like Peter's where there's a lot going on 'behind your back'.
> I personally would have a problem with a Forth compiler that removed the
> programmer from the equation.

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]

#52330

"HAA" <someone@microsoft.com> writes:
>It's possible to estimate which stack sequence is going to deliver the better
>performance.  Counting instructions is a good start.  The definition quoted
>above comprises 3 instructions, as does the PICK version, so they're going
>to be close (and they are).

If you mean primitives, the PICK version uses 6 primites (3 LITs, 3
PICKs) and will be relatively slow on a pure threaded-code Forth
implementation.

>  Moving things to/from the return stack isn't cheap
>so avoid it unless it's saving a lot of juggling on the data stack.

It's not particularly expensive, either, so I don't see a reason to
give this advice.

>'common sense' strategies for choosing code work for all but the fanciest
>code generators like Peter's where there's a lot going on 'behind your back'.
>I personally would have a problem with a Forth compiler that removed the
>programmer from the equation.

What do you mean by that?

Do you mean that, instead of putting as many stack items and locals
in registers as we can to gain efficiency and relieve programmers from
worrying about how to write 3DUP, we should have compilers that
produce slower code with hard-to-predict performance characteristics,
in order to "leave the programmer in the equation"?

I would like to learn more about Peter Faelth's compiler, and, if
possible, get a copy for benchmarking.

- 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 2016: http://www.euroforth.org/ef16/

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

#52409

Anton Ertl wrote:
> "HAA" <someone@microsoft.com> writes:
> >It's possible to estimate which stack sequence is going to deliver the better
> >performance.  Counting instructions is a good start.  The definition quoted
> >above comprises 3 instructions, as does the PICK version, so they're going
> >to be close (and they are).
>
> If you mean primitives, the PICK version uses 6 primites (3 LITs, 3
> PICKs) and will be relatively slow on a pure threaded-code Forth
> implementation.

Did you try it?  PICK doesn't involve stack gymnastics so I expect it to
do well.  On a x86 DTC, 3DUP using PICK was 20% slower than the best
alternative DUP 2OVER ROT.  Not bad, but obviously you would go with
the fastest and shortest.

> >  Moving things to/from the return stack isn't cheap
> >so avoid it unless it's saving a lot of juggling on the data stack.
>
> It's not particularly expensive, either, so I don't see a reason to
> give this advice.
>
> >'common sense' strategies for choosing code work for all but the fanciest
> >code generators like Peter's where there's a lot going on 'behind your back'.
> >I personally would have a problem with a Forth compiler that removed the
> >programmer from the equation.
>
> What do you mean by that?
>
> Do you mean that, instead of putting as many stack items and locals
> in registers as we can to gain efficiency and relieve programmers from
> worrying about how to write 3DUP, we should have compilers that
> produce slower code with hard-to-predict performance characteristics,
> in order to "leave the programmer in the equation"?

It's optimizing compilers that are hard to predict.  You discover defining
3DUP with locals is just as good as PICK.  You then try locals elsewhere
only to discover the code produced is terrible.  With optimizing compilers
you have to check every time, and there may be no logical reason why
one strategy works better than another.  If I need 3DUP to be fast, I just
write it in machine code myself.  Maybe simple is best.

> I would like to learn more about Peter Faelth's compiler, and, if
> possible, get a copy for benchmarking.
>
> - anton

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

#52413

"HAA" <someone@microsoft.com> writes:
>Anton Ertl wrote:
>> "HAA" <someone@microsoft.com> writes:
>> >It's possible to estimate which stack sequence is going to deliver the better
>> >performance.  Counting instructions is a good start.  The definition quoted
>> >above comprises 3 instructions, as does the PICK version, so they're going
>> >to be close (and they are).
>>
>> If you mean primitives, the PICK version uses 6 primites (3 LITs, 3
>> PICKs) and will be relatively slow on a pure threaded-code Forth
>> implementation.
>
>Did you try it?  PICK doesn't involve stack gymnastics so I expect it to
>do well.

Cycles (on a Core i7-6700K) with "gforth-fast --no-dynamic
--ss-number=0" (i.e., direct-threaded code) for the tak benchmark:

2077960654 : 3dup ( a b c -- a b c a b c ) >r 2dup r@ -rot r> ;
1944817489 : 3dup dup 2over rot ;
2137982996 : 3dup 2 pick 2 pick 2 pick ;
2376062674 : 3dup { a b c } a b c a b c ;

So, yes, the PICK variant is slower on a threaded-code system than the
other stack-juggling variants.  The locals variant is even slower
because is performs even more primitives.  Indeed, they all perform in
the order corresponding to the number of primitives.

>On a x86 DTC, 3DUP using PICK was 20% slower than the best
>alternative DUP 2OVER ROT.

So the slowdown is even bigger on that system.

>Not bad, but obviously you would go with
>the fastest and shortest.

Yes.  And I consider a slowdown by 10% or 20% without any redeeming
qualities justifying the slowdown bad.

>> Do you mean that, instead of putting as many stack items and locals
>> in registers as we can to gain efficiency and relieve programmers from
>> worrying about how to write 3DUP, we should have compilers that
>> produce slower code with hard-to-predict performance characteristics,
>> in order to "leave the programmer in the equation"?
>
>It's optimizing compilers that are hard to predict.  You discover defining
>3DUP with locals is just as good as PICK.  You then try locals elsewhere
>only to discover the code produced is terrible.  With optimizing compilers
>you have to check every time, and there may be no logical reason why
>one strategy works better than another.

It depends on the kind of optimization or code generation that's in
play.  E.g., Gforth heavily depends on copy propagation by gcc, and it
works like a charm.  And then there are some special-purpose
optimizations that only work in special cases (typically built in for
benchmarks); these are of course unreliable.

Allocating stack items or locals to registers is reliable as long as
there are enough registers (which is certainly the case for 3DUP, and
for a lot of other Forth code).  And the nice thing is, if you have
this kind of compiler (Peter Faelth seems to have such a compiler),
you don't need to worry about which 3DUP variant is fastest, because
they are all equally fast, and you can decide based on other criteria,
such as clarity.

>If I need 3DUP to be fast, I just
>write it in machine code myself.  Maybe simple is best.

Does not necessarily give you the fastest result: On VFX running TAK
with the builtin 3DUP (which probably is a CODE word) is slower then
with the Forth-defined stack-juggling variants.

Of course, you can choose to use a threaded-code Forth, then the
CODE-defined 3DUP will give you a speedup in TAK, maybe to the 1.5G
cycles that TAK1 takes.  Then you will be >3 times slower than any of
the stack-juggling 3DUP variants on VFX, but hey, at least your old
knowledge of what's fast and what's slow is still relevant.

- 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 2016: http://www.euroforth.org/ef16/

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

#52418

On Thu, 03 Nov 2016 15:33:27 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> Cycles (on a Core i7-6700K) with "gforth-fast --no-dynamic
> --ss-number=0" (i.e., direct-threaded code) for the tak benchmark:
> 
> 2077960654 : 3dup ( a b c -- a b c a b c ) >r 2dup r@ -rot r> ;
> 1944817489 : 3dup dup 2over rot ;
> 2137982996 : 3dup 2 pick 2 pick 2 pick ;
> 2376062674 : 3dup { a b c } a b c a b c ;

I found the tak benchmark, but how do I get gforth to give me the
cycles?  I'm interested in seeing how these two compare to those:

: 3DUP DUP >R SWAP DUP >R SWAP >R >R DUP R> SWAP R> SWAP R> R> ;
: 3DUP OVER >R >R OVER R> SWAP OVER R> SWAP ;


Rod Pemberton

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

#52424

Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> writes:
>On Thu, 03 Nov 2016 15:33:27 GMT
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> Cycles (on a Core i7-6700K) with "gforth-fast --no-dynamic
>> --ss-number=0" (i.e., direct-threaded code) for the tak benchmark:
>> 
>> 2077960654 : 3dup ( a b c -- a b c a b c ) >r 2dup r@ -rot r> ;
>> 1944817489 : 3dup dup 2over rot ;
>> 2137982996 : 3dup 2 pick 2 pick 2 pick ;
>> 2376062674 : 3dup { a b c } a b c a b c ;
>
>I found the tak benchmark, but how do I get gforth to give me the
>cycles?  I'm interested in seeing how these two compare to those:

I used Linux's perf stat tool:

perf stat -r 20 -x" " -e cycles -e instructions $FORTH "$i" >/dev/null

where $FORTH is the Forth system, and $i is a string that loads and
invokes the benchmark we are interested in.

>: 3DUP DUP >R SWAP DUP >R SWAP >R >R DUP R> SWAP R> SWAP R> R> ;
>: 3DUP OVER >R >R OVER R> SWAP OVER R> SWAP ;

For the same threaded-code Gforth as above:

2896959312 : 3DUP DUP >R SWAP DUP >R SWAP >R >R DUP R> SWAP R> SWAP R> R> ;
2349720167 : 3DUP OVER >R >R OVER R> SWAP OVER R> SWAP ;

- 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 2016: http://www.euroforth.org/ef16/

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

#52260

On Monday, October 24, 2016 at 8:43:00 PM UTC-7, trans wrote:
> 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?

When I was at Testra in 1994, the MiniForth was originally going to be a very crude Forth processor with 32 primitives in hardware and everything else written in terms of these (similar to what Bernd Paysan's B16 is now). At this time I gave some thought to this question of which primitives are absolutely necessary, allowing what would normally be primitives to be written in terms of these. That phase of the MiniForth development lasted about one week and then was discarded --- it is a dead end with no hope for efficiency --- you are better off to have an assembly language that primitives can be written in, and then have hundreds of primitives (many of which are meta-compiled rather than hand-written).

Nowadays I'm designing Straight Forth which is for 64-bit desktop computers.

I don't have R> anymore --- I do have >R R@ and RDROP --- to get the effect of R> use R@ RDROP instead.

In colon words, it is not necessary to balance >R with RDROP because EXIT will automatically discard any >R data still on the return-stack. So, for the most part, RDROP is never used. Quotations don't have this feature though, so RDROP is needed to explicitely discard >R data before exiting --- this shouldn't be a problem; quotations are usually short and simple and don't need to use >R at all anyway.

Here is an excerpt from my Straight Forth document discussing |DIP and |KEEP etc., which are borrowed from DIP and KEEP etc. in Factor (in Straight Forth the naming convention is that HOFs always have a bar in front):
----------------------------------------------------------------------------


section 1.5. --- light-weight HOFs
==================================

We have some light-weight HOFs that don't iterate and aren't associated with any data-structure.

If the top value of the data-stack is in the way, the Forth programmer would typically use >R to get it out of the way temporarily, then use R> to put it back. This isn't done in Straight Forth because >R nd R> are not idiomatic. In Straight Forth it is idiomatic to use |DIP that is borrowed from Factor. We have several related HOFs:

|DIP                ( i*x a xt -- j*x a )                       execute the xt with A out of the way, then put A back
|2DIP               ( i*x a b xt -- j*x a b )                   execute the xt with A and B out of the way, then put A and B back
|3DIP               ( i*x a b c xt -- j*x a b c )               execute the xt with A, B and C out of the way, then put A, B and C back
|KEEP               ( i*x a xt -- j*x a )                       execute the xt with A kept on the stack, then put A back
|2KEEP              ( i*x a b xt -- j*x a b )                   execute the xt with A and B kept on the stack, then put A and B back
|3KEEP              ( i*x a b c xt -- j*x a b c )               execute the xt with A, B and C kept on the stack, then put A, B and C back

Here is an ANS-Forth function:

: test ( x y a -- x+y a )
    >r  +  r> ;

Here is another ANS-Forth function that does the same thing:

: test ( x y a -- x+y a )
    -rot  +  swap ;

Here is a Straight Forth function that does this:

: test ( x y a -- x+y a )
    { + } dip ;

DIP holds A out of the way (on the return-stack) while it executes the xt which is a quotation in this example. There are some pitfalls to be aware of. For one thing, using RBUF inside of the quotation is a bad idea because the RBUF memory-block will get discarded when the quotation exits, so RT won't be valid afterward. Also, EXIT can't be used inside of the quotation to exit from the function, because the quotation is a sub-function itself. In addition to |DIP, we also have |2DIP and |3DIP that are similar except that they hold 2 or 3 data out of the way.

Here is another ANS-Forth function:

: test ( x a -- x+a a )
    dup >r  +  r> ;

Here it is with stack-juggling:

: test ( x a -- x+a a )
    tuck  +  swap ;

Here is the Straight Forth function that does this:

: test ( x a -- x+a a )
    { + } keep ;

KEEP holds a copy of A out of the way (on the return-stack) while it executes the xt which is a quotation in this example. When the xt executes, A is still kept on the data-stack. In addition to |KEEP, we also have |2KEEP and |3KEEP that are similar except that they keep 2 or 3 data.


subsection 1.5.1. --- |TRUE and |TRUE/FALSE
===========================================

In Straight Forth we have IF ELSE THEN just like in traditional Forth --- this is the idiomatic way to do conditionals.

As an alternative we also have these HOFs:

|TRUE               { flag true-xt -- }
                    Executes TRUE-XT if FLAG is TRUE.

|TRUE-FALSE         { flag true-xt false-xt-- }
                    Executes TRUE-XT if FLAG is TRUE, else executes FALSE-XT.

For example, here is some idiomatic code:

: maybe-negate ( a flag -- -a|a )
    if  negate  then ;

: maybe-plus/minus ( a b flag -- a+b|a-b )
    if  +  else  -  then ;

Here are some alternate versions:

: maybe-negate ( a flag -- -a|a )
    { negate } |true ;

: maybe-plus/minus ( a b flag -- a+b|a-b )
    { + } { - } |true-false ;

I think that |DIP and |KEEP etc., which are derived from Factor, improve readability a lot. |TRUE and |TRUE-FALSE are also derived from Factor, but it is debatable if they improve or degrade readability as compared to the idiomatic versions --- they are provided so we can have the debate, but they may be removed from Straight Forth in the future if nobody wants to use them.

|TRUE and |TRUE-FALSE have some limitations that you don't get with IF ELSE THEN which are traditional. On limitation is that if RBUF is used inside of the quotation it doesn't remain valid outside of the quotation. Another limitation is that REG and ACC can't be used to pass data out of the quotation. Another limitation is that EXIT can't be used inside of the quotation to exit from the function outside of the quotation.

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

#52271

http://tunes.org/~iepos/joy.html

I thought you might find this useful if you want to include more combinators.

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

#52280

On Friday, October 28, 2016 at 9:52:37 AM UTC-7, novembe...@gmail.com wrote:
> http://tunes.org/~iepos/joy.html
> 
> I thought you might find this useful if you want to include more combinators.

I assume that you are responding to my post where I discussed |DIP and |KEEP etc..

Thanks for the link; I'll read it. I mostly learned about this concept from Factor --- Joy is an older similar language --- both Factor and Joy are similar to where I'm going with Straight Forth (except that I don't have tagged data).

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

#52308

On Tuesday, 25 October 2016 04:43:00 UTC+1, 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?

: |> ( n - n n ) dup ;
: <| ( n n - n ) drop ;
: >< ( a b -- b a ) swap ;

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

#52309

Op Sun, 30 Oct 2016 04:49:46 -0700 (PDT) schreef Mark Wills:

> On Tuesday, 25 October 2016 04:43:00 UTC+1, 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?
> 
> :|> ( n - n n ) dup ;
>: <| ( n n - n ) drop ;
>:>< ( a b -- b a ) swap ;

From Forth-79.pdf:

><     n1 --- n2
  Swap the high and low bytes within n1. "byte-swap"

I don't know if anyone still uses this ;-)

groet Coos

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

#52336

> From Forth-79.pdf:
> 
><     n1 --- n2
>   Swap the high and low bytes within n1. "byte-swap"
> 
> I don't know if anyone still uses this ;-)

I do occasionally. MSP430 chips have an opcode for it :-)

Matthias

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

#52337

Op Mon, 31 Oct 2016 13:31:03 +0100 schreef Matthias Koch:

>> From Forth-79.pdf:
>> 
>><     n1 --- n2
>>   Swap the high and low bytes within n1. "byte-swap"
>> 
>> I don't know if anyone still uses this ;-)
> 
> I do occasionally. MSP430 chips have an opcode for it :-)
> 
> Matthias

That's the reason noForth has this word ;-)

groet Coos

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

#52338

Dear Coos,

there is even a more generalised variant of >< in Hacker's Delight:

Generalized Bit Reversal
[GLS1] suggests that the following sort of generalization of bit reversal, which he calls "flip," is a good
candidate to consider for a computer's instruction set:

if (k & 1)  x = (x & 0x55555555) << 1  | (x & 0xAAAAAAAA) >> 1;
if (k & 2)  x = (x & 0x33333333) << 2  | (x & 0xCCCCCCCC) >> 2;
if (k & 4)  x = (x & 0x0F0F0F0F) << 4  | (x & 0xF0F0F0F0) >> 4;
if (k & 8)  x = (x & 0x00FF00FF) << 8  | (x & 0xFF00FF00) >> 8;
if (k & 16) x = (x & 0x0000FFFF) << 16 | (x & 0xFFFF0000) >> 16;

(The last two and operations can be omitted.) For k = 31, this operation reverses the bits in a word. For k = 24,
it reverses the bytes in a word. For k = 7, it reverses the bits in each byte, without changing the positions of the
bytes. For k = 16, it swaps the left and right halfwords of a word, and so on. In general, it moves the bit at
position m to position (m + k) mod 32. It can be implemented in hardware very similarly to the way a rotate shifter is
usually implemented (five stages of MUX's, with each stage controlled by a bit of the shift amount k).

Do you think this would be a nice addition ?

Here comes my ARM implementation:

Matthias

@ -----------------------------------------------------------------------------
 Wortbirne Flag_foldable_2, "flip" @ ( x u -- x* ) @ Bit flip operation.
flip: @ A special bit reversal routine from "Hacker's Delight".
@ -----------------------------------------------------------------------------

 popda r0 @ Control value

 tst r0, #1
 beq 1f
   ands r2, tos, #0x55555555
   lsls r2, #1
   ands r3, tos, #0xAAAAAAAA
   orrs tos, r2, r3, lsr #1
1:

 tst r0, #2
 beq 1f
   ands r2, tos, #0x33333333
   lsls r2, #2
   ands r3, tos, #0xCCCCCCCC
   orrs tos, r2, r3, lsr #2
1:

 tst r0, #4
 beq 1f
   ands r2, tos, #0x0F0F0F0F
   lsls r2, #4
   ands r3, tos, #0xF0F0F0F0
   orrs tos, r2, r3, lsr #4
1:

 tst r0, #8
 beq 1f
   ands r2, tos, #0x00FF00FF
   lsls r2, #8
   ands r3, tos, #0xFF00FF00
   orrs tos, r2, r3, lsr #8
1:

 tst r0, #16
 beq 1f
   lsls r2, tos, #16
   orrs tos, r2, tos, lsr #16
1:

 bx lr
 

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

#52419

On Monday, 31 October 2016 12:28:10 UTC, Matthias Koch  wrote:
> > From Forth-79.pdf:
> > 
> ><     n1 --- n2
> >   Swap the high and low bytes within n1. "byte-swap"
> > 
> > I don't know if anyone still uses this ;-)
> 
> I do occasionally. MSP430 chips have an opcode for it :-)
> 
> Matthias

It's useful on big-endian systems that favour the high-byte. It's essential
on the TMS99xx family.

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web