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

#26700

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>That's suprising to me too.  ?DUP WHILE is natural and elegant when
>>iterating over lists, for example.
> 
> ?DUP IF can save an ELSE DROP, and, depending on layout style,q up to
> two lines.  So i can understand the urge to use ?DUP IF there.
> 
> ?DUP WHILE only saves a DROP.  Natural and elegant?

Sure, it reduces stack noise.  What's not to like?  ;-)

> Maybe in the Bizarro World.

It's just natural and idiomatic for me.  I'd feel weird not using ?DUP .
That's almost certainly because the primary influence on my Forth is
Forth, Inc, and they've always used ?DUP .

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

There's no need: as well as not panicking about the compiler, it's
also good Forth style (IMO, YMMV, ect.)  not to panic about
microseconds which don't matter.  Having said that,  ?DUP IF  avoids
a couple of trips through NEXT , and this is a speed advantage in some
implementatons.  We shouldn't overgeneralize, because implementations
vary so much.

However, if you're going to write a full optimizing compiler, it's a
bit pathetic not to be able to turn  ?DUP IF ... THEN   into
DUP IF  ...  ELSE DROP  THEN .  I suppose it makes sense if that's
an idiom you don't use.

Andrew.

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

#26712

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>That's suprising to me too.  ?DUP WHILE is natural and elegant when
>>>iterating over lists, for example.
>> 
>> ?DUP IF can save an ELSE DROP, and, depending on layout style,q up to
>> two lines.  So i can understand the urge to use ?DUP IF there.
>> 
>> ?DUP WHILE only saves a DROP.  Natural and elegant?
>
>Sure, it reduces stack noise.  What's not to like?  ;-)

A word with a variable stack effect.

>> As for putting the burden on the compiler to correct for the
>> programmer's use of ?DUP: This is Forth.  We argue even about good
>> practices if they complicate the compiler.  Why should we complicate
>> the compiler for "?DUP"?  Better let the programmers fix the
>> programs.
>
>There's no need: as well as not panicking about the compiler, it's
>also good Forth style (IMO, YMMV, ect.)  not to panic about
>microseconds which don't matter.  Having said that,  ?DUP IF  avoids
>a couple of trips through NEXT , and this is a speed advantage in some
>implementatons.

If you care about speed, you will use a native code compiler, and
there are no trips through NEXT there; if you don't care about speed
(as the preceeding sentence indicates), why argue with speed?

Anyway, even if we want to optimize for a threaded-code
implementation, ?DUP IF is slower then ?DUP-IF, because it needs an
additional test and an additional NEXT.

Now for ?DUP WHILE ... REPEAT compared to DUP WHILE ... REPEAT DROP:
This costs one test per loop iteration, and saves one DROP for the
whole loop.  For loops with many iterations, it's a performance loss.

>However, if you're going to write a full optimizing compiler, it's a
>bit pathetic not to be able to turn  ?DUP IF ... THEN   into
>DUP IF  ...  ELSE DROP  THEN .  I suppose it makes sense if that's
>an idiom you don't use.

I guess I won't be writing a "full optimizing compiler", whatever that
may be.  The compilation techniques that I have in mind are capable of
producing good native code for a lot of Forth code, but they don't
produce good code for anything involving ?DUP.  One can add complexity
to the compiler for optimizing some of the code that uses ?DUP, but
that requires more than just adding a few more entries to an existing
table; it requires adding an otherwise unnecessary sequence
recognition capability; that's very low on my ToDo list.

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

#26715

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:
>>>>That's suprising to me too.  ?DUP WHILE is natural and elegant when
>>>>iterating over lists, for example.
>>> 
>>> ?DUP IF can save an ELSE DROP, and, depending on layout style,q up to
>>> two lines.  So i can understand the urge to use ?DUP IF there.
>>> 
>>> ?DUP WHILE only saves a DROP.  Natural and elegant?
>>
>>Sure, it reduces stack noise.  What's not to like?  ;-)
> 
> A word with a variable stack effect.

Sure, but that's just a religious thing; for those who don't follow
that religion it's meaningless.

>>> As for putting the burden on the compiler to correct for the
>>> programmer's use of ?DUP: This is Forth.  We argue even about good
>>> practices if they complicate the compiler.  Why should we complicate
>>> the compiler for "?DUP"?  Better let the programmers fix the
>>> programs.
>>
>>There's no need: as well as not panicking about the compiler, it's
>>also good Forth style (IMO, YMMV, ect.)  not to panic about
>>microseconds which don't matter.  Having said that,  ?DUP IF  avoids
>>a couple of trips through NEXT , and this is a speed advantage in some
>>implementatons.
> 
> If you care about speed, you will use a native code compiler

Not necessarily, because there is also some advantage to simplicity.
Like all engineering it's a trade-off.

> Anyway, even if we want to optimize for a threaded-code
> implementation, ?DUP IF is slower then ?DUP-IF, because it needs an
> additional test and an additional NEXT.

True, but ?DUP-IF is fugly.  IMO, YMMV, ect.  It's a trade-off.

> Now for ?DUP WHILE ... REPEAT compared to DUP WHILE ... REPEAT DROP:
> This costs one test per loop iteration, and saves one DROP for the
> whole loop.  For loops with many iterations, it's a performance
> loss.

It can be implemented that way; or not.  As we both know.  And if
> anyone really cares I guess there's ?DUP_WHILE .

>>However, if you're going to write a full optimizing compiler, it's a
>>bit pathetic not to be able to turn  ?DUP IF ... THEN   into
>>DUP IF  ...  ELSE DROP  THEN .  I suppose it makes sense if that's
>>an idiom you don't use.
> 
> I guess I won't be writing a "full optimizing compiler", whatever
> that may be.  The compilation techniques that I have in mind are
> capable of producing good native code for a lot of Forth code, but
> they don't produce good code for anything involving ?DUP.

Well, whose fault is that?  :-)

> One can add complexity to the compiler for optimizing some of the
> code that uses ?DUP, but that requires more than just adding a few
> more entries to an existing table; it requires adding an otherwise
> unnecessary sequence recognition capability; that's very low on my
> ToDo list.

OK.  But that's really just what I said: if it's not in your style,
there's no point for you in optimizing it.

Andrew.

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

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

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:
>>>>>That's suprising to me too.  ?DUP WHILE is natural and elegant when
>>>>>iterating over lists, for example.
>>>> 
>>>> ?DUP IF can save an ELSE DROP, and, depending on layout style,q up to
>>>> two lines.  So i can understand the urge to use ?DUP IF there.
>>>> 
>>>> ?DUP WHILE only saves a DROP.  Natural and elegant?
>>>
>>>Sure, it reduces stack noise.  What's not to like?  ;-)
>> 
>> A word with a variable stack effect.
>
>Sure, but that's just a religious thing; for those who don't follow
>that religion it's meaningless.

It's a technical thing.  Such words do not just cause overhead
in the compiler, but also in the brain.  The programmer has to take
two stack effects into consideration, and the condition under which
which stack effect happens.

>> Anyway, even if we want to optimize for a threaded-code
>> implementation, ?DUP IF is slower then ?DUP-IF, because it needs an
>> additional test and an additional NEXT.
>
>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.

>>>However, if you're going to write a full optimizing compiler, it's a
>>>bit pathetic not to be able to turn  ?DUP IF ... THEN   into
>>>DUP IF  ...  ELSE DROP  THEN .  I suppose it makes sense if that's
>>>an idiom you don't use.
>> 
>> I guess I won't be writing a "full optimizing compiler", whatever
>> that may be.  The compilation techniques that I have in mind are
>> capable of producing good native code for a lot of Forth code, but
>> they don't produce good code for anything involving ?DUP.
>
>Well, whose fault is that?  :-)

Fault?  If you want to imply that it's just a personal preference,
please show me the paper that shows how to optimize ?DUP and get code
quality comparable to an analytic compiler without extra complexity
(compared to an analytic compiler that does not optimize ?DUP).

>> One can add complexity to the compiler for optimizing some of the
>> code that uses ?DUP, but that requires more than just adding a few
>> more entries to an existing table; it requires adding an otherwise
>> unnecessary sequence recognition capability; that's very low on my
>> ToDo list.
>
>OK.  But that's really just what I said: if it's not in your style,
>there's no point for you in optimizing it.

No, this has nothing to do with compiling code I have written.  It
adds a substantial amount of extra complexity to the compiler also if
the compiler compiles your code.  The Forth way is to avoid that
complexity and leave it to the programmer to avoid ?DUP.

I just tried out whether VFX optimizes ?DUP IF.  It does; the result
is interesting:

variable a  ok
: foo dup if a ! else drop then ;  ok
: bar ?dup if a ! then ;  ok
see foo 
FOO 
( 080BF310    85DB )                  TEST      EBX, EBX
( 080BF312    0F8411000000 )          JZ/E      080BF329
( 080BF318    891D3C240A08 )          MOV       [080A243C], EBX
( 080BF31E    8B5D00 )                MOV       EBX, [EBP]
( 080BF321    8D6D04 )                LEA       EBP, [EBP+04]
( 080BF324    E906000000 )            JMP       080BF32F
( 080BF329    8B5D00 )                MOV       EBX, [EBP]
( 080BF32C    8D6D04 )                LEA       EBP, [EBP+04]
( 080BF32F    C3 )                    NEXT,
( 32 bytes, 9 instructions )
 ok
see bar 
BAR 
( 080BF350    85DB )                  TEST      EBX, EBX
( 080BF352    750B )                  JNZ/NE    080BF35F
( 080BF354    8B5D00 )                MOV       EBX, [EBP]
( 080BF357    8D6D04 )                LEA       EBP, [EBP+04]
( 080BF35A    E90C000000 )            JMP       080BF36B
( 080BF35F    891D3C240A08 )          MOV       [080A243C], EBX
( 080BF365    8B5D00 )                MOV       EBX, [EBP]
( 080BF368    8D6D04 )                LEA       EBP, [EBP+04]
( 080BF36B    C3 )                    NEXT,
( 28 bytes, 9 instructions )

The native code difference between these two versions is that the two
branches of the IF are exchanged, and that BAR uses a short branch,
while FOO uses a long one (resulting in the 4-byte size difference).

I tried to generate the BAR code with

: flip dup 0= if drop else a ! then ;  ok

and it gives the same code, except that it uses a long branch
instruction:

see flip 
FLIP 
( 080BF390    85DB )                  TEST      EBX, EBX
( 080BF392    0F850B000000 )          JNZ/NE    080BF3A3
( 080BF398    8B5D00 )                MOV       EBX, [EBP]
( 080BF39B    8D6D04 )                LEA       EBP, [EBP+04]
( 080BF39E    E90C000000 )            JMP       080BF3AF
( 080BF3A3    891D3C240A08 )          MOV       [080A243C], EBX
( 080BF3A9    8B5D00 )                MOV       EBX, [EBP]
( 080BF3AC    8D6D04 )                LEA       EBP, [EBP+04]
( 080BF3AF    C3 )                    NEXT,
( 32 bytes, 9 instructions )

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

#26725 — 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:
>>>>>>That's suprising to me too.  ?DUP WHILE is natural and elegant when
>>>>>>iterating over lists, for example.
>>>>> 
>>>>> ?DUP IF can save an ELSE DROP, and, depending on layout style,q up to
>>>>> two lines.  So i can understand the urge to use ?DUP IF there.
>>>>> 
>>>>> ?DUP WHILE only saves a DROP.  Natural and elegant?
>>>>
>>>>Sure, it reduces stack noise.  What's not to like?  ;-)
>>> 
>>> A word with a variable stack effect.
>>
>>Sure, but that's just a religious thing; for those who don't follow
>>that religion it's meaningless.
> 
> It's a technical thing.  Such words do not just cause overhead
> in the compiler, but also in the brain.

Not in *my* brain. 

To expand a little: in general, words with a variable stack effect are
confusing, but but this

  begin  ...  ?dup while  ...  repeat

is not confusing at all to me, because that's what I expect.  It's
absolutely natutural classic Forth, which you apparently want
programmers not to use in order to simplify optimization.

> Fault?  If you want to imply that it's just a personal preference,

I'm not implying that, I'm flat-out *stating* it!

> please show me the paper that shows how to optimize ?DUP and get
> code quality comparable to an analytic compiler without extra
> complexity (compared to an analytic compiler that does not optimize
> ?DUP).

There must be a line of reasoning in this paragraph, but I can't find
it.  Your argument seems to be that if the use of  ?DUP  is just a
personal preference, then there must exist a paper that shows how to
optimize it without adding complexity.  How does this follow?

Of course it adds extra complexity to optimize a word.  That's true of
every word.  You could decide not to optimize ROT , and presumably
that would simplify your optimizer too.

>>> One can add complexity to the compiler for optimizing some of the
>>> code that uses ?DUP, but that requires more than just adding a few
>>> more entries to an existing table; it requires adding an otherwise
>>> unnecessary sequence recognition capability; that's very low on my
>>> ToDo list.
>>
>>OK.  But that's really just what I said: if it's not in your style,
>>there's no point for you in optimizing it.
> 
> No, this has nothing to do with compiling code I have written.  It
> adds a substantial amount of extra complexity to the compiler also if
> the compiler compiles your code.  The Forth way is to avoid that
> complexity and leave it to the programmer to avoid ?DUP.

?DUP is in CORE.  It's been in Forth forever. The only reason to leave
it out from an optimizer is that you don't use it.

> I just tried out whether VFX optimizes ?DUP IF.  It does; the result
> is interesting:

Indeed.

Andrew.

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

#26727 — Re: ?DUP

On Mon, 28 Oct 2013 14:54:04 -0400, Andrew Haley  
<andrew29@littlepinkcloud.invalid> wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

>> [...]
> [...]
> absolutely natutural classic Forth, which you apparently want

natural

> ?DUP is in CORE.  It's been in Forth forever. The only
> reason to leave it out from an optimizer is that you
> don't use it.

Or, it's just so low usage that there is no point bothering
with it ...  Of course, I don't think I've ever heard of a
*selective* code optimizer, i.e., one where you could select
or not select words like ?DUP or ROT to be optimized or not.
Have you?  Is that another bit in the dictionary header?


Rod Pemberton

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

#26728 — Re: ?DUP

On 10/28/13 10:30 AM, Rod Pemberton wrote:
> On Mon, 28 Oct 2013 14:54:04 -0400, Andrew Haley
...
>> ?DUP is in CORE.  It's been in Forth forever. The only
>> reason to leave it out from an optimizer is that you
>> don't use it.
>
> Or, it's just so low usage that there is no point bothering
> with it ...  Of course, I don't think I've ever heard of a
> *selective* code optimizer, i.e., one where you could select
> or not select words like ?DUP or ROT to be optimized or not.
> Have you?  Is that another bit in the dictionary header?

It's a matter of taste. In my experience (and Andrew's, and others), 
it's extensively used. Anton doesn't use it, so doesn't bother with 
whatever optimizing rule would help it.

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]

#26737 — 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:
>>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
[...]
>> It's a technical thing.  Such words do not just cause overhead
>> in the compiler, but also in the brain.
>
>Not in *my* brain. 
>
>To expand a little: in general, words with a variable stack effect are
>confusing, but but this
>
>  begin  ...  ?dup while  ...  repeat
>
>is not confusing at all to me, because that's what I expect.

So it's not ?DUP you are using, but ?DUP WHILE and ?DUP IF, right.
You just don't want to write ?DUP WHILE or ?WHILE for religious
reasons.

>It's
>absolutely natutural classic Forth, which you apparently want
>programmers not to use in order to simplify optimization.

You can use it all right, but don't complain if the code is slow.

[Context omitted by Andrew Haley in an attempt to alter the meaning
 and topic of this part of the discussion:]
|>>>>The compilation techniques that I have in mind are
|>>>>capable of producing good native code for a lot of Forth code, but
|>>>>they don't produce good code for anything involving ?DUP.
|>>>
|>>>Well, whose fault is that?  :-)

>> Fault?  If you want to imply that it's just a personal preference,
>
>I'm not implying that, I'm flat-out *stating* it!
>
>> please show me the paper that shows how to optimize ?DUP and get
>> code quality comparable to an analytic compiler without extra
>> complexity (compared to an analytic compiler that does not optimize
>> ?DUP).
>
>There must be a line of reasoning in this paragraph, but I can't find
>it.  Your argument seems to be that if the use of  ?DUP  is just a
>personal preference, then there must exist a paper that shows how to
>optimize it without adding complexity.  How does this follow?

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.

>Of course it adds extra complexity to optimize a word.  That's true of
>every word.  You could decide not to optimize ROT , and presumably
>that would simplify your optimizer too.

Not "optimizing" ROT would not simplify the compiler.

>> No, this has nothing to do with compiling code I have written.  It
>> adds a substantial amount of extra complexity to the compiler also if
>> the compiler compiles your code.  The Forth way is to avoid that
>> complexity and leave it to the programmer to avoid ?DUP.
>
>?DUP is in CORE.  It's been in Forth forever.

So what?  So is DEPTH.  I won't add extra compexity to optimize that,
either (and, judging from the SORTD timings, VFX does not optimize it,
either).

> The only reason to leave
>it out from an optimizer is that you don't use it.

If it was just a matter of using an existing mechanism and adding a
specification for ?DUP, as your finely spin-doctored words "leave it
out from an optimizer" imply, I would do it.  But optimizing ?DUP
requires adding a new optimization mechanism without any foreseeable
benefit beyond optimizing ?DUP.  Adding that is very low on my ToDo
list.

And since the programmers can easily avoid ?DUP, that's the Forth way:
Avoid unnecessary complexity.

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

#26741 — Re: ?DUP

Anton Ertl wrote:
> 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.

My suggested optimization would be:

Create two static superinstruction for ?DUP+?BRANCH and for ?DUP+0=+?BRANCH.  
Use standard VM opcode combining to match those superinstructions to code 
where ?DUP IF or ?DUP 0= UNTIL occurs.  The superinstruction stuff itself is 
found in a published paper by Anton Ertl, David Gregg, and Helmut Eller. 
Compiling these superinstructions to native code should not be too 
difficult, although the semantics requires expansion to something not 
completely trivial.

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

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

#26745 — Re: ?DUP

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> 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.
>
>My suggested optimization would be:
>
>Create two static superinstruction for ?DUP+?BRANCH and for ?DUP+0=+?BRANCH.  
>Use standard VM opcode combining to match those superinstructions to code 
>where ?DUP IF or ?DUP 0= UNTIL occurs.  The superinstruction stuff itself is 
>found in a published paper by Anton Ertl, David Gregg, and Helmut Eller. 
>Compiling these superinstructions to native code should not be too 
>difficult, although the semantics requires expansion to something not 
>completely trivial.

That would require adding superinstructions at that level, i.e.,
additional complexity.  I don't plan adding such superinstructions,
because they buy little benefit (except for ?DUP) once we have decent
instruction selection (e.g., tree parsing), which combines sequences
like CELLS + @ +, but at a different level and more effectively (e.g.,
they can also combine CELLS + @ ROT + without adding an extra
pattern).

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

#26746 — Re: ?DUP

In article <l4olbt$u2n$1@online.de>, Bernd Paysan  <bernd.paysan@gmx.de> wrote:
>Anton Ertl wrote:
>> 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.
>
>My suggested optimization would be:
>
>Create two static superinstruction for ?DUP+?BRANCH and for ?DUP+0=+?BRANCH.
>Use standard VM opcode combining to match those superinstructions to code
>where ?DUP IF or ?DUP 0= UNTIL occurs.  The superinstruction stuff itself is
>found in a published paper by Anton Ertl, David Gregg, and Helmut Eller.
>Compiling these superinstructions to native code should not be too
>difficult, although the semantics requires expansion to something not
>completely trivial.

I'd hate to have special code just for ?DUP apart from dropping ?DUP
if the argument is known to be non-zero.

Think about it this way:
   - DUP? is a conditional, WHILE is a conditional.
   - An optimisation is possible whenever two conditionals are known
       to use the same condition.

That is probably much more worth the effort.

>
>--
>Bernd Paysan
>"If you want it done right, you have to do it yourself"
>http://bernd-paysan.de/
>
-- 
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]

#26749 — Re: ?DUP

Albert van der Horst wrote:
> I'd hate to have special code just for ?DUP apart from dropping ?DUP
> if the argument is known to be non-zero.
> 
> Think about it this way:
>    - DUP? is a conditional, WHILE is a conditional.
>    - An optimisation is possible whenever two conditionals are known
>        to use the same condition.
> 
> That is probably much more worth the effort.

Yes, that should work.  GCC can combine two conditionals that either have 
the same or the opposite condition into one single branch, too.

So the definition of ?DUP is just

: ?dup ( n / 0 -- n n / 0 )  dup if dup then ;

and the control flow handling should figure out what to do.

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

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

#26755 — Re: ?DUP

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Albert van der Horst wrote:
>> I'd hate to have special code just for ?DUP apart from dropping ?DUP
>> if the argument is known to be non-zero.
>> 
>> Think about it this way:
>>    - DUP? is a conditional, WHILE is a conditional.
>>    - An optimisation is possible whenever two conditionals are known
>>        to use the same condition.
>> 
>> That is probably much more worth the effort.
>
>Yes, that should work.

Yes.  But that's also extra complexity.  And beyond ?DUP, how often
does it apply in Forth code?

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

#26750 — 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:
>>>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> [...]
>>> It's a technical thing.  Such words do not just cause overhead
>>> in the compiler, but also in the brain.
>>
>>Not in *my* brain. 
>>
>>To expand a little: in general, words with a variable stack effect are
>>confusing, but but this
>>
>>  begin  ...  ?dup while  ...  repeat
>>
>>is not confusing at all to me, because that's what I expect.
> 
> So it's not ?DUP you are using, but ?DUP WHILE and ?DUP IF, right.

Yes, exactly.  AFAIK that's what ?DUP is for.

> You just don't want to write ?DUP WHILE or ?WHILE for religious
> reasons.

I presume this means "?DUP WHILE as ?WHILE".  That's right.  As I
said, it's a matter of style.

>>It's absolutely natutural classic Forth, which you apparently want
>>programmers not to use in order to simplify optimization.
> 
> You can use it all right, but don't complain if the code is slow.

I'm not complaining.  Please try to remember that you brought up the
issue of speed as an onjection to ?DUP , not me.

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

>>> please show me the paper that shows how to optimize ?DUP and get
>>> code quality comparable to an analytic compiler without extra
>>> complexity (compared to an analytic compiler that does not optimize
>>> ?DUP).
>>
>>There must be a line of reasoning in this paragraph, but I can't find
>>it.  Your argument seems to be that if the use of  ?DUP  is just a
>>personal preference, then there must exist a paper that shows how to
>>optimize it without adding complexity.  How does this follow?
> 
> 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?

>>Of course it adds extra complexity to optimize a word.  That's true of
>>every word.  You could decide not to optimize ROT , and presumably
>>that would simplify your optimizer too.
> 
> 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.

>>?DUP is in CORE.  It's been in Forth forever.
> 
> So what?  So is DEPTH.  I won't add extra compexity to optimize that,
> either (and, judging from the SORTD timings, VFX does not optimize it,
> either).

Well, yes.  It's exactly the same situation.  If DEPTH was important
to you, you'd optimize it.

>> The only reason to leave it out from an optimizer is that you don't
>> use it.
> 
> If it was just a matter of using an existing mechanism and adding a
> specification for ?DUP, as your finely spin-doctored words "leave it
> out from an optimizer" imply, I would do it.  But optimizing ?DUP
> requires adding a new optimization mechanism without any foreseeable
> benefit beyond optimizing ?DUP.

I don't disagree with that, because ?DUP is a special case.  But (IMO,
YMMV) ?DUP is useful enough that it's well worth doing.  Even if only
to convert it to ?DUP-IF or ?DUP-WHILE .

I really do not understand why you are making so much fuss about this
rather trivial matter.

There is a possible interesting discussion to come out of this,
though, which is the extent to which the existence of optimizers
should influence the language, if at all.

Andrew.

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

#26751 — Re: ?DUP

On Tue, 29 Oct 2013 17:29:42 -0400, Andrew Haley  
<andrew29@littlepinkcloud.invalid> wrote:

> Not the interminable length of the discussion.

One or both of you could end the "discussion" at any point,
i.e., it's not really interminable.  You might not be willing
to end the "discussion," but he might.

So, did you want "indeterminable" instead of "interminable"?


Rod Pemberton

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

#26756 — Re: ?DUP

Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote:
> On Tue, 29 Oct 2013 17:29:42 -0400, Andrew Haley  
> <andrew29@littlepinkcloud.invalid> wrote:
> 
>> Not the interminable length of the discussion.
> 
> One or both of you could end the "discussion" at any point,
> i.e., it's not really interminable.  You might not be willing
> to end the "discussion," but he might.

Indeed.

> So, did you want "indeterminable" instead of "interminable"?

No.

Andrew.

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

#26754 — Re: ?DUP

In article <ur-dnbVptuRbte3PnZ2dnUVZ_vCdnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>
>I don't disagree with that, because ?DUP is a special case.  But (IMO,
>YMMV) ?DUP is useful enough that it's well worth doing.  Even if only
>to convert it to ?DUP-IF or ?DUP-WHILE .
>
>I really do not understand why you are making so much fuss about this
>rather trivial matter.
>
>There is a possible interesting discussion to come out of this,
>though, which is the extent to which the existence of optimizers
>should influence the language, if at all.

I agree with Anton (and others) that there is something to dislike
about ?DUP. So we both can avoid it in our code, or even ban it in
our company using coding guidelines.

However Anton is also a compiler writer and part of the prestigious
gforth team. As such he has to accept that ?DUP is in the standard
and must be handled by the compiler. If enough users of gforth
find optimisation of ?DUP important, it is something to consider.
That doesn't mean Anton has to do it, of course.

I think that somehow efficiency influence the design of a language.
If a language implementation can accommodate new and old things
easily that is something to be proud of. I don't think it should
go the other way, avoiding things because they are hard to implement.


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

#26757 — 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:
>>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
[...]
>> You just don't want to write ?DUP WHILE or ?WHILE for religious
>> reasons.
>
>I presume this means "?DUP WHILE as ?WHILE".

I meant that you don't want to write ?DUP-WHILE or ?WHILE.

>> You can use it all right, but don't complain if the code is slow.
>
>I'm not complaining.  Please try to remember that you brought up the
>issue of speed as an onjection to ?DUP , not me.

Actually Albert van der Horst brought it up, to which you replied in
<1b-dnapgsMauI_bPnZ2dnUVZ_qidnZ2d@supernews.com>:

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

And my comment on not complicating the compiler was a reaction to that.

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

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

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

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

#26758 — Re: ?DUP

On Wed, 30 Oct 2013 04:22:13 -0400, Anton Ertl  
<anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

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

Are you two talking about different things here?

ISTM, that Anton is discussing optimization down to the
assembly level for a Forth that compiles, but Andrew might
be discussing optimization which stops at the level of
low-level words, e.g., for a thread-code interpreted Forth.
In one case, everything is optimized, both high- and low-level
Forth words.  In the other, just the high-level words.

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

Interesting, but is there really a need for "c:" definition?

I.e., if you're just defining "rot" to be "rot", what's the
purpose of "c:" ?  Symbolic?

Anyway, how ROT is defined depends on what you have available.

If you have >R and SWAP , then ">R SWAP >R SWAP" works.

Of course, you could also implement ROT in assembly or C, etc
as a low-level word.

Or, you could use one of many other high-level definitions:

: ROT 2 ROLL ;
: ROT TUCK 2SWAP DROP ;
: ROT NUP 2SWAP DROP ;
: ROT >R SWAP >R 2R> ;
: ROT >R 2>R R> 2R> ;
etc...

E.g., ROT using one register A:
: ROT >R >R A! R> R> A@ ;
: ROT A! SWAP A@ SWAP ;

E.g., ROT using two registers A and B:
: ROT A! B! >R B@ A@ R> ;

If you have more precise stack control, other definitions
are possible, but likely longer sequences.

Of course, you really want to pick whatever is fastest,
or that which optimizes the best, not necessarily that
which is the shortest.  That could mean using operations
that you wouldn't normally choose.


Rod Pemberton

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

#26762 — Re: ?DUP

"Rod Pemberton" <dont_use_email@xnohavenotit.cnm> writes:
>On Wed, 30 Oct 2013 04:22:13 -0400, Anton Ertl  
>> c: rot rot ; : rot rot ;
>>
>
>Interesting, but is there really a need for "c:" definition?
>
>I.e., if you're just defining "rot" to be "rot", what's the
>purpose of "c:" ?  Symbolic?

C: rot rot ;

says that when COMPILE, processes the xt of rot, it rotates the top
three items on the compile-time representation of the run-time data
stack.  Thinking about it again, if we do it right when we perform the
"COMPILE,", we probably don't want these items to be on the data
stack, but elsewhere, so this definition would be something like:

C: rot 3c> rot 3>c ;

I.e., move three items from the internal COMPILE, stack to the data
stack, rotate them, move three items back.  If, OTOH, COMPILE, just 

Now the compiler knows how to COMPILE, ROT, and since ROT has default
compilation semantics, it also knows how to compile ROT, but it does
not know how to interpret nor EXECUTE ROT.  So we add

: rot rot ;

which uses the compilation semantics to create the
execution/interpretation semantics.

>Of course, you could also implement ROT in assembly or C, etc
>as a low-level word.

Would not be any simpler.

>Or, you could use one of many other high-level definitions:
>
>: ROT 2 ROLL ;
>: ROT TUCK 2SWAP DROP ;
>: ROT NUP 2SWAP DROP ;
>: ROT >R SWAP >R 2R> ;
>: ROT >R 2>R R> 2R> ;
>etc...
[...]
>Of course, you really want to pick whatever is fastest,
>or that which optimizes the best, not necessarily that
>which is the shortest.

These all produce the same code in the kind of compiler I am thinking
of (except maybe 2 ROLL, which requires a mechanism that the others
don't need, and which may not be present).  The difference is that all
such definitions require more compile time: the definition of ROT has
to be inlined, and each of the words in the definition has to do it's
compile-time thing.  And of course, at some point you have to reach a
primitive level; you cannot define both: 2SWAP in terms of ROT and ROT
in terms of 2SWAP.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

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

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

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

csiph-web