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

#26765 — Re: ?DUP

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> 
>>> [Context omitted by Andrew Haley in an attempt to alter the meaning
>>> and topic of this part of the discussion:]
>>
>>Yes, right.  That must be the reason.  Not the interminable length of
>>the discussion.  Oh no.
> 
> You expect me to believe that you are not capable of following a line
> of reasoning that's 16 lines long and fully cited?

I don't know what you are referring to.

I was not attempting to alter the meaning and topic of this part of
the discussion; I was assuming that others don't need to see it
repeated.  I thought the text I snipped wasn't essential.  I try to
snip, as do you.  My intention was not malign.

Of course, if you really think anything I snip is essential, you can
re-insert it.

>>> The argument is if optimizing (not using) ?DUP is just a personal
>>> preference, there must be a well-known (i.e., published in a paper)
>>> method to optimize it without extra complexity.
>>
>>Why must there be?
> 
> If there is no such method, it's a technical choice, not a personal
> preference.  If there is such a method, but it's not known to the
> compiler writer, it's also a technical choice.

It's a trade-off between readability (to some) and compiler
complexity, and that is the personal preference to which I refer.  To
expand on that: someone might choose to write  ?DUP WHILE  even in the
certain knowledge that it would make the compiler slower or more
complex, purely because they prefer to do so.  Therefore, the use of
?DUP is still a personal preference, even if it makes the compiler
more complex.  I'm sure this is true of many words as well as ?DUP .

>>> Not "optimizing" ROT would not simplify the compiler.
>>
>>Why not?  Surely if you don't recognize ROT, but simply code it as a
>>call to a definition, the optimizer is simpler.
> 
> Even a definition of ROT as a colon definition would result in
> optimizing ROT.

Why would not the same reasoning apply to optimizing ?DUP ?

> And it's not really simpler than a more direct
> definition of ROT:
> 
> Colon definition:
> 
> : myrot >r swap r> swap ;
> 
> A direct definition would look maybe like this:
> 
> c: rot rot ; : rot rot ;

This only makes sense if the compiler already has a built-in
definition for ROT  .  Which makes the compiler more complex...

Andrew.

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

#26767 — Re: ?DUP

on 30/10/2013 17:44:35, Andrew Haley wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
[snip]
> 
>> And it's not really simpler than a more direct
>> definition of ROT:
>>
>> Colon definition:
>>
>> : myrot >r swap r> swap ;
>>
>> A direct definition would look maybe like this:
>>
>> c: rot rot ; : rot rot ;
> 
> This only makes sense if the compiler already has a built-in
> definition for ROT  .  Which makes the compiler more complex...
> 


I've chosen DUP SWAP >R R> and DROP as the only implicitly defined
definitions for my compiler. All others are constructed from them; I
think it's the minimum set to construct all other stack movement
operations. Here, redefine: is Anton's c:

redefine: dup     cb-spop dup cb-spush cb-spush           ;
redefine: swap    cb-spop cb-spop swap cb-spush cb-spush  ;
redefine: >r      cb-spop cb-rpush                        ;
redefine: r>      cb-rpop cb-spush                        ;
redefine: drop    cb-spop drop                            ;

redefine: rot          >r swap r> swap           ;
redefine: 2swap        rot >r rot r>             ;

etc. and then

: drop drop ;
: rot  rot  ;

Efficency's not the goal right now; good factoring is. At some later
stage, I can redefine ROT with cb-xxx primitives, but that won't buy me
much compile time speed improvements I suspect. 

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

#26770 — Re: ?DUP

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> 
>>>> [Context omitted by Andrew Haley in an attempt to alter the meaning
>>>> and topic of this part of the discussion:]
>>>
>>>Yes, right.  That must be the reason.  Not the interminable length of
>>>the discussion.  Oh no.
>> 
>> You expect me to believe that you are not capable of following a line
>> of reasoning that's 16 lines long and fully cited?
>
>I don't know what you are referring to.
>
>I was not attempting to alter the meaning and topic of this part of
>the discussion; I was assuming that others don't need to see it
>repeated.  I thought the text I snipped wasn't essential.  I try to
>snip, as do you.  My intention was not malign.

The problem was not the snipping, but the combination of snipping and
changing the topic; the snipping made it non-obvious that you were not
replying to what I had written, but to a straw man.

>>>> Not "optimizing" ROT would not simplify the compiler.
>>>
>>>Why not?  Surely if you don't recognize ROT, but simply code it as a
>>>call to a definition, the optimizer is simpler.
>> 
>> Even a definition of ROT as a colon definition would result in
>> optimizing ROT.
>
>Why would not the same reasoning apply to optimizing ?DUP ?

Because ?DUP cannot just be performed at compile time on the
compile-time representation of the run-time stack, because what ?DUP
does to the stack depends on run-time values.

>> A direct definition would look maybe like this:
>> 
>> c: rot rot ; : rot rot ;
>
>This only makes sense if the compiler already has a built-in
>definition for ROT  .  Which makes the compiler more complex...

The Forth system on which the compiler is running (build system in gcc
terminology, I think) certainly has a built-in definition for ROT.
This does not make the compiler more complex, because it's the build
system's ROT, not the compiler's ROT.

For more explanations, see my answer to Rod Pemberton.  If there are
any questions remaining after that, I would be happy to answer them.

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

#26776 — Re: ?DUP

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> 
>>>>> [Context omitted by Andrew Haley in an attempt to alter the meaning
>>>>> and topic of this part of the discussion:]
>>>>
>>>>Yes, right.  That must be the reason.  Not the interminable length of
>>>>the discussion.  Oh no.
>>> 
>>> You expect me to believe that you are not capable of following a line
>>> of reasoning that's 16 lines long and fully cited?
>>
>>I don't know what you are referring to.
>>
>>I was not attempting to alter the meaning and topic of this part of
>>the discussion; I was assuming that others don't need to see it
>>repeated.  I thought the text I snipped wasn't essential.  I try to
>>snip, as do you.  My intention was not malign.
> 
> The problem was not the snipping, but the combination of snipping and
> changing the topic; the snipping made it non-obvious that you were not
> replying to what I had written, but to a straw man.

I still don't know what you are talking about.  I've been over the
list of messages three times now, and I'm looking for the straw man
you say I used, and I can't find it.  I can't find any place where I
have misrepresented you.  If I did do so it was not intentional, and
I only snipped for brevity.

>>Why would not the same reasoning apply to optimizing ?DUP ?
> 
> Because ?DUP cannot just be performed at compile time on the
> compile-time representation of the run-time stack, because what ?DUP
> does to the stack depends on run-time values.

Sure, I get that.

Andrew.

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

#26726 — Re: ?DUP (was: Floating Point : To Stack or Not To Stack)

On Mon, 28 Oct 2013 11:19:30 -0400, Anton Ertl  
<anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:

>> [...]
>> True, but ?DUP-IF is fugly.
>
> Compared to ?DUP IF it's beautiful.  Faster on threaded-code and
> native-code systems without adding extra complexity to the compiler.
>

Um, why wouldn't it be named ?IF ?
Ditto for ?DUP-WHILE as ?WHILE .


Rod Pemberton
--
Brian: "Why are you putting so much emphasis on the H?"
-Family Guy, TV show
http://familyguy.wikia.com/wiki/Cool_Whip

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

#26729 — Re: ?DUP

On 10/28/13 10:30 AM, Rod Pemberton wrote:
> On Mon, 28 Oct 2013 11:19:30 -0400, Anton Ertl
> <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>
>>> [...]
>>> True, but ?DUP-IF is fugly.
>>
>> Compared to ?DUP IF it's beautiful.  Faster on threaded-code and
>> native-code systems without adding extra complexity to the compiler.
>>
>
> Um, why wouldn't it be named ?IF ?
> Ditto for ?DUP-WHILE as ?WHILE .

Yes, I've seen both ?IF and ?WHILE in use for these functions. I agree, 
if you're going to define these, those are much better names.

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]

#26730 — Re: ?DUP

Elizabeth D. Rather wrote:
> Yes, I've seen both ?IF and ?WHILE in use for these functions. I agree,
> if you're going to define these, those are much better names.

I've looked through my code, and ?DUP is only used together with either IF 
or WHILE (sometimes in the form of ?DUP 0= IF). So this is really 
overfactored.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#26732 — Re: ?DUP

> Elizabeth D. Rather wrote:
> 
> > Yes, I've seen both ?IF and ?WHILE in use for these functions. I agree,
> 
> > if you're going to define these, those are much better names.
> 
> 
> 
> I've looked through my code, and ?DUP is only used together with either IF 
> 
> or WHILE (sometimes in the form of ?DUP 0= IF). So this is really 
> 
> overfactored.
> 
> 

I always use ?IF, ?WHILE and ?UNTIL instead of ?DUP IF, ?DUP WHILE and ?DUP UNTIL. They are in my basic wordlist.

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

#26734 — Re: ?DUP

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Elizabeth D. Rather wrote:
>> Yes, I've seen both ?IF and ?WHILE in use for these functions. I agree,
>> if you're going to define these, those are much better names.
> 
> I've looked through my code, and ?DUP is only used together with either IF 
> or WHILE (sometimes in the form of ?DUP 0= IF). So this is really 
> overfactored.

That's right, just like NOT (when it existed) was almost always used
as  NOT IF  .  It's nice to read, that's all.

Andrew.

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

#26735 — Re: ?DUP

On Tuesday, October 29, 2013 10:37:16 AM UTC+1, Andrew Haley wrote:
> Bernd Paysan <bernd.paysan@gmx.de> wrote: 
>> I've looked through my code, and ?DUP is only used together with 
>> either IF or WHILE (sometimes in the form of ?DUP 0= IF). So this 
>> is really overfactored. 

> That's right, just like NOT (when it existed) was almost always used as 
> NOT IF . It's nice to read, that's all. 

So why introduce ?IF ?NIF ?WHILE ( and NIF ?NWHILE ) as 'protected names'?
I find that I use use ?DUP quite often, even while I certainly don't like 
the word.

-marcel

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

#26738 — Re: ?DUP

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> Elizabeth D. Rather wrote:
>>> Yes, I've seen both ?IF and ?WHILE in use for these functions. I agree,
>>> if you're going to define these, those are much better names.
>> 
>> I've looked through my code, and ?DUP is only used together with either IF 
>> or WHILE (sometimes in the form of ?DUP 0= IF). So this is really 
>> overfactored.
>
>That's right, just like NOT (when it existed) was almost always used
>as  NOT IF  .

NOT can be used and was used in other ways, e.g., NOT AND.  That's not
the case for ?DUP.  There are only very few correct ways to use ?DUP;
an EBNF for those few uses is:

?DUP [ 0= ] ( IF | WHILE | UNTIL )

And of those even fewer are used in practice, and all of them can be
avoided.

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

#26693

Paul Rubin <no.email@nospam.invalid> writes:
>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?

Yes.  In particular I don't expect such practices to be used for
embedded targets where stack space is so precious that you don't want
to have a separate FP stack.

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

As Elizabeth Rather writes, not everyone considers it bad style.
However, the compiler can determine the stack effect statically for
common uses of ?DUP (i.e., ?DUP IF and ?DUP 0= IF).  The major
obstacle in standard code is EXECUTE/DEFER.

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

#26695

In article <2013Oct26.114518@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Paul Rubin <no.email@nospam.invalid> writes:
>>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?
>
>Yes.  In particular I don't expect such practices to be used for
>embedded targets where stack space is so precious that you don't want
>to have a separate FP stack.
>
>> 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.
>
>As Elizabeth Rather writes, not everyone considers it bad style.
>However, the compiler can determine the stack effect statically for
>common uses of ?DUP (i.e., ?DUP IF and ?DUP 0= IF).  The major
>obstacle in standard code is EXECUTE/DEFER.

Whether or not it's bad style, I find myself avoiding it.
Take this implementation of the greatest common divider

( n1 n2 -- gcd )
: gcd   begin over mod dup while swap repeat drop ;

This would be a text book example

: gcd   begin over mod ?dup while swap repeat ;

I somehow find it harder to understand, and I feel an aversion
against an extra path through the code.
The optimising compiler agrees with me. The first translate
to primitive operations and a jump. The second to two jumps.

I can view the first code in two ways
  1. loop content:    over mod swap
     it is easy to see that this keeps two things on the stack
     it is easy to see that the gcd is a loop invariant
  2. stop criterion: if the second is zero.

?DUP confounds the two, at least in my mind. Maybe it is just
inertia ...

>- anton
>--
>M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
-- 
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]

#26696

Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:

> 
> Whether or not it's bad style, I find myself avoiding [ ?DUP ].
> Take this implementation of the greatest common divider
> 
> ( n1 n2 -- gcd )
> : gcd   begin over mod dup while swap repeat drop ;
> 
> This would be a text book example
> 
> : gcd   begin over mod ?dup while swap repeat ;
> 
> I somehow find it harder to understand, and I feel an aversion
> against an extra path through the code.

Eh?  It's just a loop.

> The optimising compiler agrees with me. The first translate
> to primitive operations and a jump. The second to two jumps.
> 
> I can view the first code in two ways
>  1. loop content:    over mod swap
>     it is easy to see that this keeps two things on the stack
>     it is easy to see that the gcd is a loop invariant
>  2. stop criterion: if the second is zero.
> 
> ?DUP confounds the two, at least in my mind. Maybe it is just
> inertia ...

I've never had a problem with ?DUP , but then I've always used it for
this purpose.  I think it's a "cliche", just like OVER + SWAP .

Surely it wouldn't take long to convince an optimizer that ?DUP WHILE
is one conditional branch, not two.

Andrew.

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

#26697

On Saturday, October 26, 2013 1:30:14 PM UTC+2, Albert van der Horst wrote:
[..]
> The optimising compiler agrees with me. The first translate
> to primitive operations and a jump. The second to two jumps.

... which can have substantial effects:

FORTH> : t1  ?dup if 1 + endif ;  ok
FORTH> : t2   dup if 1 + else  drop  endif ;  ok
FORTH> 1000000000 value #t 
: bm cr timer-reset 1 #t 0 do  t1  loop . .elapsed  
     cr timer-reset 1 #t 0 do  t2  loop . .elapsed ;  ok
FORTH> bm
1000000001 3.767 seconds elapsed.
1000000001 1.513 seconds elapsed. ok

-marcel

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

#26702

On Sat, 26 Oct 2013 09:09:45 -0400, <mhx@iae.nl> wrote:
> On Saturday, October 26, 2013 1:30:14 PM UTC+2, Albert van der Horst  
> wrote:
> [..]

>> The optimising compiler agrees with me. The first translate
>> to primitive operations and a jump. The second to two jumps.
>
> ... which can have substantial effects:
>
> FORTH> : t1  ?dup if 1 + endif ;  ok
> FORTH> : t2   dup if 1 + else  drop  endif ;  ok
> FORTH> 1000000000 value #t
> : bm cr timer-reset 1 #t 0 do  t1  loop . .elapsed
>      cr timer-reset 1 #t 0 do  t2  loop . .elapsed ;  ok
> FORTH> bm
> 1000000001 3.767 seconds elapsed.
> 1000000001 1.513 seconds elapsed. ok
>

In this context, is ?DUP a "primitive" or defined
as "DUP IF DUP THEN" or some other sequence?

If ?DUP is a sequence, like "DUP IF DUP THEN",
then it should be fairly obvious that it results
in longer, more complicated code, if there is no
optimization.

Is this for an optimizing Forth?  If so, I'd expect
it to result in the same optimized code for both
definitions: t1 and t2, i.e., their times should be
the same.


Rod Pemberton

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

#26703

On 10/26/13 9:01 PM, Rod Pemberton wrote:
> On Sat, 26 Oct 2013 09:09:45 -0400, <mhx@iae.nl> wrote:
>> On Saturday, October 26, 2013 1:30:14 PM UTC+2, Albert van der Horst
>> wrote:
>> [..]
>
>>> The optimising compiler agrees with me. The first translate
>>> to primitive operations and a jump. The second to two jumps.
>>
>> ... which can have substantial effects:
>>
>> FORTH> : t1  ?dup if 1 + endif ;  ok
>> FORTH> : t2   dup if 1 + else  drop  endif ;  ok
>> FORTH> 1000000000 value #t
>> : bm cr timer-reset 1 #t 0 do  t1  loop . .elapsed
>>      cr timer-reset 1 #t 0 do  t2  loop . .elapsed ;  ok
>> FORTH> bm
>> 1000000001 3.767 seconds elapsed.
>> 1000000001 1.513 seconds elapsed. ok
>>
>
> In this context, is ?DUP a "primitive" or defined
> as "DUP IF DUP THEN" or some other sequence?
>
> If ?DUP is a sequence, like "DUP IF DUP THEN",
> then it should be fairly obvious that it results
> in longer, more complicated code, if there is no
> optimization.
>
> Is this for an optimizing Forth?  If so, I'd expect
> it to result in the same optimized code for both
> definitions: t1 and t2, i.e., their times should be
> the same.

It isn't supposed to matter. It may be any of the above.

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]

#26691

In article <l4fnpl$fju$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>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?

It is not very common, but common enough to be considered normal.

Examples:
My WORDS puts a zero on the stack and then all Dictionary Entry
Addresses. Then it prints all names from the entries until the zero.
This way the most recent words are on the bottom. Those are probably
the words you're most interested in.

You need a set of all dividers of a number consisting of different
prime products on behalf of a Moebius sum. For 12 this means the
set {1,-2,-3,+6} .
This is done by me as follows.
    Put 1 in a bag.
       For all prime dividers: (e.g. 2)
          Remove them from the number: (leaves 3)
          Negate it ( so -2)
          Put a zero on the stack.       ( 0
          For all numbers in bag:
             push it on the stack.        ( 0 1 0
             push the product with prime divider ( 0 1 -2 )
          Empty the bag and move the content of the
              stack back to the bag (1 -2)

>
>--
>
>Rick

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]

#26692

In article <526b8dbd$0$1683$e4fe514c@dreader35.news.xs4all.nl>,
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
>In article <l4fnpl$fju$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>>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?
>
>It is not very common, but common enough to be considered normal.
>
>Examples:
>My WORDS puts a zero on the stack and then all Dictionary Entry
>Addresses. Then it prints all names from the entries until the zero.
>This way the most recent words are on the bottom. Those are probably
>the words you're most interested in.
>
>You need a set of all dividers of a number consisting of different
>prime products on behalf of a Moebius sum. For 12 this means the
>set {1,-2,-3,+6} .
>This is done by me as follows.
>    Put 1 in a bag.
>       For all prime dividers: (e.g. 2)
>          Remove them from the number: (leaves 3)
>          Negate it ( so -2)
>          Put a zero on the stack.       ( 0
>          For all numbers in bag:
>             push it on the stack.        ( 0 1 0
>             push the product with prime divider ( 0 1 -2 )
>          Empty the bag and move the content of the
>              stack back to the bag (1 -2)

The brackets went astray, sorry.

This is done by me as follows.
    Put 1 in a bag.
       For all prime dividers: (e.g. 2)
          Remove them from the number: (leaves 3)
          Negate it ( so -2)
          Put a zero on the stack.       ( 0 )
          For all numbers in bag:
             push it on the stack.        ( 0 1 )
             push the product with prime divider ( 0 1 -2 )
          Empty the bag and move the content of the
              stack back to the bag (bag: 1 -2)

>>
>>--
>>
>>Rick
>
>Groetjes Albert
>--
>Albert van der Horst, UTRECHT,THE NETHERLANDS
>
-- 
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]

#26623

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?

The argument goes that a separate f.p stack is necessary and/or easier to use.

I find the claim to be exaggerated if not false.

To demonstrate to myself that a separate f.p stack is *not* required, I have
made it a point to code all my f.p apps to use the data stack.  Not only is it
no harder, I find the resulting code easier to read as there is one less stack
to deal with.

I do have versions of my forth which use a separate stack.  That's to
accommodate *other peoples* separate stack code - not that there is
much forth f.p code available in any case.

If one has an f.p chip such as an 80x87 and want maximum speed then one
might choose to implement a separate f.p stack.  However this too has its
complications as f.p chip stacks are often limited.

Just as some believe locals are necessary to Forth, so there will be those
who believe a separate f.p stack is necessary.  I'm not one of them.

[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