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

Would ?EXIT work in all ANS-Forth systems?

Started by	lehs <skydda.barnen@gmail.com>
First post	2017-05-10 08:21 -0700
Last post	2017-05-15 11:23 +0000
Articles	20 on this page of 135 — 21 participants

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

  Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-10 08:21 -0700
    Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-10 16:39 +0100
      Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-10 08:46 -0700
      Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 16:04 +0000
      Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 04:22 -0500
        Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-11 10:35 +0100
          Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 05:08 -0500
            Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-11 03:51 -0700
              Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 07:02 -0500
              Re: Would ?EXIT work in all ANS-Forth systems? rickman <gnuarm@gmail.com> - 2017-05-13 11:55 -0400
          Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 09:32 -0500
            Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 11:56 -0500
              Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 12:20 -0500
                Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 12:31 -0500
                  Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 15:50 -0500
    Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 16:49 +0000
      Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-10 12:04 -0700
    Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-11 01:08 -0700
      Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-11 09:13 +0100
        Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-11 01:48 -0700
          Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-11 09:59 +0100
    Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-12 14:20 +0000
      Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-12 17:01 -0700
        Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-12 22:18 -0700
          Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-13 03:09 -0700
          Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-13 21:07 +1000
          Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:20 +0000
            Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-14 11:59 +1000
              Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-14 09:21 -0500
                Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-14 10:43 -0700
                  Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-14 18:35 -0500
                    Re: Would ?EXIT work in all ANS-Forth systems? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-15 07:11 +0200
                      Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 04:35 -0500
                        Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-15 03:54 -0700
                          Re: Would ?EXIT work in all ANS-Forth systems? mhx@iae.nl - 2017-05-15 04:07 -0700
                          Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 06:23 -0500
                            Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-15 06:53 -0700
                              Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 09:18 -0500
                    Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-14 22:44 -0700
                      Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 04:16 -0500
                        Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-16 02:00 -0700
                        Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-16 02:43 -0700
                          Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 05:08 -0500
                          Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 12:11 +0000
                            Re: Would ?EXIT work in all ANS-Forth systems? NN <november.nihal@gmail.com> - 2017-05-17 05:24 -0700
                              Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-17 07:35 -0500
                                Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-17 14:59 +0100
                              Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-17 13:30 +0000
                  Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-15 11:09 +1000
                    Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-14 21:17 -0700
                    Re: Would ?EXIT work in all ANS-Forth systems? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-15 07:13 +0200
                      Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-16 10:24 +1000
                        Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-16 01:13 -0700
                          Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 12:26 +0000
                            Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-17 01:58 -0700
                              Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-17 16:45 +0000
                                Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-25 12:04 -0700
                                  Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-26 10:02 +0000
                                    Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-26 07:46 -0500
                                      Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-26 13:53 +0000
                                        Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-26 10:14 -0500
                                      Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 10:16 -0500
                                        Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 08:59 -0700
                                          Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 11:27 -0500
                                            Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 10:19 -0700
                                              Re: Would ?EXIT work in all ANS-Forth systems? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-26 20:20 +0200
                                                Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 21:38 -0700
                                              Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 14:06 -0500
                                                Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 22:00 -0700
                            Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-26 17:06 +0000
                              Re: Would ?EXIT work in all ANS-Forth systems? hum9 <obi65537@gmail.com> - 2017-05-27 01:15 -0700
                                Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-28 14:17 +0000
                              Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-27 17:40 +0000
                          Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-24 15:46 +1000
                            Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <obi65537@gmail.com> - 2017-05-25 11:51 -0700
                            Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <obi65537@gmail.com> - 2017-05-25 20:38 -0700
                            Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-25 22:03 -0700
                              Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-25 22:09 -0700
                                Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-26 21:56 +1000
                                  Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-26 13:30 +0100
                                    Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-27 15:04 +1000
                                      Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-27 17:33 +0100
                                        Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-29 12:17 +1000
                                  Re: Would ?EXIT work in all ANS-Forth systems? hum9 <obi65537@gmail.com> - 2017-05-27 00:33 -0700
                                Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-27 14:53 +1000
                                  READ-FILE over-specified? "HAA" <someone@microsoft.com> - 2017-05-27 21:28 +1000
                                    Re: READ-FILE over-specified? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-27 13:11 +0000
                                      Re: READ-FILE over-specified? "HAA" <someone@microsoft.com> - 2017-05-29 13:47 +1000
                                    Re: READ-FILE over-specified? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-28 09:44 +0200
                                      Re: READ-FILE over-specified? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-28 13:41 +0000
                                        Re: READ-FILE over-specified? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-28 19:59 +0200
                        Re: Would ?EXIT work in all ANS-Forth systems? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-16 09:42 +0100
                          Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 09:53 +0100
                            Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 04:53 -0500
                              Re: Would ?EXIT work in all ANS-Forth systems? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-16 12:32 +0200
                              Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 12:35 +0100
                                Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 10:48 -0500
                                  Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 18:23 +0100
                                    Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-17 04:33 -0500
                                      Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-17 12:29 +0100
                              Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 10:28 +0000
                                Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 10:43 -0500
                                  Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 16:34 +0000
                                    Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 12:41 -0500
                                      Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-17 16:14 +0000
                                        Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 03:05 -0500
                                          Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-18 16:33 +0000
                                            Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 12:43 -0500
                                        Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 04:01 -0500
                                          Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-18 15:41 +0000
                                            Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 11:58 -0500
                                            Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-18 22:57 +0100
                            Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-17 00:32 +1000
                              Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 15:53 +0100
                  Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-15 05:29 +0000
                    Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-14 23:00 -0700
                  Re: Would ?EXIT work in all ANS-Forth systems? rickman <gnuarm@gmail.com> - 2017-05-17 12:27 -0400
              Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 09:16 +0000
              Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 09:55 +0000
          Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:25 +0000
            Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-13 07:49 -0700
              Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 09:59 +0000
              Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 12:22 +0000
        Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:19 +0000
    Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-14 23:23 -0700
      Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-15 00:10 -0700
        Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-15 09:35 +0000
      Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-15 00:54 -0700
        Return-address manipulation (was: Would ?EXIT ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-15 08:47 +0000
          Re: Return-address manipulation (was: Would ?EXIT ...) stephen@mpeforth.com (Stephen Pelc) - 2017-05-15 11:53 +0000
            Re: Return-address manipulation (was: Would ?EXIT ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 13:03 +0000
              Re: Return-address manipulation (was: Would ?EXIT ...) Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-16 07:06 -0700
                Re: Return-address manipulation (was: Would ?EXIT ...) Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-16 07:14 -0700
      Re: Would ?EXIT work in all ANS-Forth systems? "Elizabeth D. Rather" <erather@forth.com> - 2017-05-14 21:58 -1000
        Re: Would ?EXIT work in all ANS-Forth systems? stephen@mpeforth.com (Stephen Pelc) - 2017-05-15 11:23 +0000

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

#59357

From	humptydumpty <ouatubi@gmail.com>
Date	2017-05-16 02:00 -0700
Message-ID	<f095e157-4790-4a71-a64b-a6c960962aa2@googlegroups.com>
In reply to	#59276

On Monday, May 15, 2017 at 12:16:23 PM UTC+3, Andrew Haley wrote:
> humptydumpty wrote:
> > 
> > That I could understand: on 8086 push a pair segment:offset as a
> > return address, and have accordingly work on two items on return-stack.
> > 
> > What I do not understand is "And maybe you'd even be using a
> > different stack for return addresses." So there is a stack
> > (even not hardware) for returning addresses from a definition.
> > What could prevent to discard a return address to skip return
> > to the caller?
> 
> The return stack is internal to the processor, in internal RAM.  The
> stack used by >R and R is in external memory.  So you have three
> stacks, the hardware return stack being the third one.
> 
> > Having a quick look at how Scheme treats continuations,
> > I think there is more than a mere technique.
> 
> I don't think that you can glorify return stack hackery in this way.
> It's far less useful than continuations.  Real continuations would be
> quite interesting.
> 
> >> > What matter is idea behind code. User will modify  '?#'  definition
> >> > accordingly with used Forth implementation, if necessary, or choose
> >> > another Forth implementation.
> >> 
> >> : ?# ( ud -- ud' t )  #  2dup or ;
> >> : #,S ( ud -- 0 0 )
> >>    begin
> >>       ?# while  ?# while  ?# while
> >>       [char] , hold
> >>    repeat  then then ;
> >> 
> >> So, not quite as cute, but it does the job.  And the reader can see
> >> where the exits are.  What advantage did the return stack, er,
> >> technique :-) bring you?
> > 
> > Maybe compiled code size ?
> 
> Maybe, but it depends on the exact Forth.  I'd guess it's insignificant.

Insignificant, but additive. :)
 
> 
> Andrew.

Have a nice day,
hum9

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

#59358

From	humptydumpty <ouatubi@gmail.com>
Date	2017-05-16 02:43 -0700
Message-ID	<7cdf9d7b-0c9d-4e30-97d1-5bb653f76a15@googlegroups.com>
In reply to	#59276

On Monday, May 15, 2017 at 12:16:23 PM UTC+3, Andrew Haley wrote:
> humptydumpty wrote:
> > 
> > That I could understand: on 8086 push a pair segment:offset as a
> > return address, and have accordingly work on two items on return-stack.
> > 
> > What I do not understand is "And maybe you'd even be using a
> > different stack for return addresses." So there is a stack
> > (even not hardware) for returning addresses from a definition.
> > What could prevent to discard a return address to skip return
> > to the caller?
> 
> The return stack is internal to the processor, in internal RAM.  The
> stack used by >R and R is in external memory.  So you have three
> stacks, the hardware return stack being the third one.
> 
> > Having a quick look at how Scheme treats continuations,
> > I think there is more than a mere technique.
> 
> I don't think that you can glorify return stack hackery in this way.
> It's far less useful than continuations.  Real continuations would be
> quite interesting.

Having direct access to return-stack means access to future evolution of
running program. I'm curious how real continuations could be adapted to
Forth. Backup/restore of return-stack content is a relatively easy job.
But I guess that real continuations means something more than that.
Or not much more, in the Forth case (implicit parameter passing, etc.) ?

> Andrew.

Have a nice day,
hum9

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

#59361

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2017-05-16 05:08 -0500
Message-ID	<47Odnd60lM4MUofEnZ2dnUU7-Q3NnZ2d@supernews.com>
In reply to	#59358

humptydumpty <ouatubi@gmail.com> wrote:
> On Monday, May 15, 2017 at 12:16:23 PM UTC+3, Andrew Haley wrote:
>> humptydumpty wrote:
>> > 
>> > Having a quick look at how Scheme treats continuations,
>> > I think there is more than a mere technique.
>> 
>> I don't think that you can glorify return stack hackery in this way.
>> It's far less useful than continuations.  Real continuations would be
>> quite interesting.
> 
> Having direct access to return-stack means access to future evolution of
> running program. I'm curious how real continuations could be adapted to
> Forth. Backup/restore of return-stack content is a relatively easy job.
> But I guess that real continuations means something more than that.
> Or not much more, in the Forth case (implicit parameter passing, etc.) ?

I think you'd need (at least) both stacks, and without a garbage
collection mechanism to decide when to free unused continuations,
they'd be tricky and error-prone to use.  To do the sorts of things
people do with continuations you'd also need a way to determine what
return stack items meant, i.e to find return addresses, find out what
words they refer to, and so on.

Andrew.

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

#59367

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2017-05-16 12:11 +0000
Message-ID	<2017May16.141156@mips.complang.tuwien.ac.at>
In reply to	#59358

humptydumpty <ouatubi@gmail.com> writes:
>Having direct access to return-stack means access to future evolution of
>running program. I'm curious how real continuations could be adapted to
>Forth. Backup/restore of return-stack content is a relatively easy job.
>But I guess that real continuations means something more than that.

A real continuation represents the remaining computation, so it means
that you have to store the whole to-be-modified (or, if you cannot
determine that, modifyable) state of the program, in a way that allows
restoring that state.

I don't think it's very appropriate for Forth.

- 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 2017: http://www.euroforth.org/ef17/

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

#59426

From	NN <november.nihal@gmail.com>
Date	2017-05-17 05:24 -0700
Message-ID	<f64c536f-dd65-482d-bb2b-e733cc6c8824@googlegroups.com>
In reply to	#59367

Would I be correct in assuming that the state of the remaining  computation is = the data stack + return stack + variables in forth ?

Not just return stack only ?


NN

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

#59428

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2017-05-17 07:35 -0500
Message-ID	<psWdnQZbtc4M3oHEnZ2dnUU7-d3NnZ2d@supernews.com>
In reply to	#59426

NN <november.nihal@gmail.com> wrote:
> Would I be correct in assuming that the state of the remaining
> computation is = the data stack + return stack + variables in forth
> ?
> 
> Not just return stack only ?

Assuming no I/O, yes.

This came up with the transactional memory system I wrote.  There it
was necessary to snapshot both stacks at the start of a transaction
and track all memory stores and loads.  If a transaction aborts,
restore the stacks and throw away all the memory changes.  It's quite
a lot of effort.  And even then it's not a real continuation, which
can be executed multiple times, even by different threads.

Andrew.

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

#59429

From	Alex <alex@rivadpm.com>
Date	2017-05-17 14:59 +0100
Message-ID	<ofhkpi$c5r$1@dont-email.me>
In reply to	#59428

On 5/17/2017 13:35, Andrew Haley wrote:
> NN <november.nihal@gmail.com> wrote:
>> Would I be correct in assuming that the state of the remaining
>> computation is = the data stack + return stack + variables in forth
>> ?
>>
>> Not just return stack only ?
> 
> Assuming no I/O, yes.
> 
> This came up with the transactional memory system I wrote.  There it
> was necessary to snapshot both stacks at the start of a transaction
> and track all memory stores and loads.  If a transaction aborts,
> restore the stacks and throw away all the memory changes.  It's quite
> a lot of effort.  And even then it's not a real continuation, which
> can be executed multiple times, even by different threads.
> 
> Andrew.
> 

We have no problem doing this with VMs and storage based snapshots; and 
it can account for the I/O as well. But doing it at the MMU level is 
hard. We may need to crack this nut though. The growth of persistent 
memory will require it.

-- 
Alex

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

#59430

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2017-05-17 13:30 +0000
Message-ID	<2017May17.153044@mips.complang.tuwien.ac.at>
In reply to	#59426

NN <november.nihal@gmail.com> writes:
[continuations]
>Would I be correct in assuming that the state of the remaining  computation is = the data stack + return stack + variables in forth ?

Plus other stuff in the dictionary plus ALLOCATEd memory.

>Not just return stack only ?

That will not be enough in general, no.

- 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 2017: http://www.euroforth.org/ef17/

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

#59235

From	"HAA" <someone@microsoft.com>
Date	2017-05-15 11:09 +1000
Message-ID	<ofav51$1t52$1@gioia.aioe.org>
In reply to	#59223

humptydumpty wrote:
> On Sunday, May 14, 2017 at 5:21:50 PM UTC+3, Andrew Haley wrote:
> > HAA wrote:
> >
> > > In the days when "return stack" meant return stack and threaded code
> > > was the norm R> DROP is what you would use.  ANS precludes this,
> > > forcing programmers to adopt inefficient solutions.
> >
> > No.  That is not how it happened.  ANS did not preclude return stack
> > hackery because it wasn't portable anyway.  Before the ANS process
> > began, the number of return stack items pushed by a colon definition
> > wasn't always 1.  And maybe you'd even be using a different stack for
> > return addresses.
>
> This is mind boggling! Was that Forth? What is the percentage
> of such implementations from all Forth implementations?
>
> >  So maybe the R> DROP trick would work, maybe not.
>
> But this is not a trick. Is applying knowledge that on return-stack
> is the address of continuation(partial) of current definition caller.

Correct.  It expresses a functionality which at the time was implemented
through R> DROP.   For all I know ANS TC simply forgot to consider this
use in its deliberations.  There's no reason it couldn't be added as a new
word.

> > In that sense, the situation is not any different post-ANS: if you
> > want to depend on a colon definition pushing one item onto the return
> > stack you can still assume that.  ANS did not cause this trick to stop
> > working: it was descriptive rather than prescriptive.
> >
> > > Here's an example of a routine that deserves to be as efficient as
> > > it looks.
> > >
> > > : ?# ( ud -- ud )  #  2dup d0= if  r> drop  then ;
> > >
> > > : #,S ( ud -- 0 0 )  begin ?#  ?#  ?#  [char] , hold  again ;
> >
> > I hope that wouldn't pass review.
>
> This is a very nice factored code!

I think so too.  It came from Greenarrays polyForth.  I've used 'R> DROP'
(under a different name) in low level code to good effect but the above was
an example everybody could recognize.

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

#59242

From	Raimond Dragomir <raimond.dragomir@gmail.com>
Date	2017-05-14 21:17 -0700
Message-ID	<38e74117-563a-40a3-a748-996a52dbeca7@googlegroups.com>
In reply to	#59235

> > > > Here's an example of a routine that deserves to be as efficient as
> > > > it looks.
> > > >
> > > > : ?# ( ud -- ud )  #  2dup d0= if  r> drop  then ;
> > > >
> > > > : #,S ( ud -- 0 0 )  begin ?#  ?#  ?#  [char] , hold  again ;
> > >
> > > I hope that wouldn't pass review.
> >
> > This is a very nice factored code!
> 
> I think so too.  It came from Greenarrays polyForth.  I've used 'R> DROP'
> (under a different name) in low level code to good effect but the above was
> an example everybody could recognize.

While this is very nice, it's totally not portable. I don't think this
would work on any of my systems. Or may work on some cases and not on
other ones. As Antons says: "edge" cases.

We have EXIT.
Maybe a RETURN word would be nice (returning to the caller's caller).

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

#59248

From	Lars Brinkhoff <lars.spam@nocrew.org>
Date	2017-05-15 07:13 +0200
Message-ID	<86inl266tx.fsf@molnjunk.nocrew.org>
In reply to	#59235

HAA wrote:
> It expresses a functionality which at the time was implemented through
> R> DROP.  For all I know ANS TC simply forgot to consider this use in
> its deliberations.

Isn't it the case that the 1994 ANS explicitly spells out that return
addresses may not be accessible at all by R>?

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

#59339

From	"HAA" <someone@microsoft.com>
Date	2017-05-16 10:24 +1000
Message-ID	<ofdgrt$6cd$1@gioia.aioe.org>
In reply to	#59248

Lars Brinkhoff wrote:
> HAA wrote:
> > It expresses a functionality which at the time was implemented through
> > R> DROP.  For all I know ANS TC simply forgot to consider this use in its
> > R> deliberations.
>
> Isn't it the case that the 1994 ANS explicitly spells out that return
> addresses may not be accessible at all by R>?

Exactly.  So if you want to drop a level in ANS you'll need another
mechanism to do it.  I chose to implement a word called UNNEST,
the definition of which will vary from system to system.

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

#59352

From	humptydumpty <ouatubi@gmail.com>
Date	2017-05-16 01:13 -0700
Message-ID	<0a413040-f9d7-479f-b24a-894d0985ba84@googlegroups.com>
In reply to	#59339

On Tuesday, May 16, 2017 at 3:24:34 AM UTC+3, HAA wrote:
> Lars Brinkhoff wrote:
> > HAA wrote:
> > > It expresses a functionality which at the time was implemented through
> > > R> DROP.  For all I know ANS TC simply forgot to consider this use in its
> > > R> deliberations.
> >
> > Isn't it the case that the 1994 ANS explicitly spells out that return
> > addresses may not be accessible at all by R>?
> 
> Exactly.  So if you want to drop a level in ANS you'll need another
> mechanism to do it.  I chose to implement a word called UNNEST,
> the definition of which will vary from system to system.

One of quick & dirty multilevel drop that I thought is pair:

: ESC  ( rp -- )   RP! ;
: ESCAPES>  ( xt[rp--] -- )   RP@ swap EXECUTE ;

And used something like:

: escaping-word  ( .. rp -- ... )  .. IF ESC THEN ... ;
: working-word   ( .. rp -- ... )  .. escaping-word ... ;
: current-word   ( .. -- ... )     ['] working-word ESCAPES> ... ;   

Another one, more flexible, but same principle is at:
http://theforth.net/package/callec

--
Have a nice day,
hum9

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

#59368

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2017-05-16 12:26 +0000
Message-ID	<2017May16.142647@mips.complang.tuwien.ac.at>
In reply to	#59352

humptydumpty <ouatubi@gmail.com> writes:
>One of quick & dirty multilevel drop that I thought is pair:
>
>: ESC  ( rp -- )   RP! ;
>: ESCAPES>  ( xt[rp--] -- )   RP@ swap EXECUTE ;
>
>And used something like:
>
>: escaping-word  ( .. rp -- ... )  .. IF ESC THEN ... ;
>: working-word   ( .. rp -- ... )  .. escaping-word ... ;
>: current-word   ( .. -- ... )     ['] working-word ESCAPES> ... ;   

What's wrong with

: escaping-word  ( .. -- ... )  .. THROW ... ;
: working-word   ( .. -- ... )  .. escaping-word ... ;
: current-word   ( .. -- ... )     ['] working-word CATCH ... ;

Advantages: no np to pass around, no IF, and it's standard.  In
practice you will probably want to throw and catch a specific ball,
but that's still easier than passing np through various words.

- 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 2017: http://www.euroforth.org/ef17/

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

#59420

From	humptydumpty <ouatubi@gmail.com>
Date	2017-05-17 01:58 -0700
Message-ID	<cba716b2-b3ae-4f1a-93b1-cb54251f467f@googlegroups.com>
In reply to	#59368

On Tuesday, May 16, 2017 at 3:34:28 PM UTC+3, Anton Ertl wrote:
> humptydumpy writes:
> >One of quick & dirty multilevel drop that I thought is pair:
> >
> >: ESC  ( rp -- )   RP! ;
> >: ESCAPES>  ( xt[rp--] -- )   RP@ swap EXECUTE ;
> >
> >And used something like:
> >
> >: escaping-word  ( .. rp -- ... )  .. IF ESC THEN ... ;
> >: working-word   ( .. rp -- ... )  .. escaping-word ... ;
> >: current-word   ( .. -- ... )     ['] working-word ESCAPES> ... ;   
> 
> What's wrong with
> 
> : escaping-word  ( .. -- ... )  .. THROW ... ;
> : working-word   ( .. -- ... )  .. escaping-word ... ;
> : current-word   ( .. -- ... )     ['] working-word CATCH ... ;

Is not OK because if an exception happens in 'working-word' or
in his lower level called words, that exception is CATCH-ed as
if it was THROW-ed inside 'escaping-word'.

Also, ESC/ESCAPES> has 2 one-liners, total 6 forth-words.
THROW/CATCH  has 66 lines, total 181 forth-words - from gforth sources.
Difference of complexity, size and speed is easily seen.

> 
> Advantages: no np to pass around,

in the case of 'callec' having an xt on top of stack
is an advantage in testing composing words in isolation,
also as a whole, see the example.

> no IF, 

there should be an 'IF ELSE THEN' if some exceptions happens,not
that THROW-ed programmatically by 'escaping-word'. Also those
exceptions should be reTHROW-ed.

> and it's standard.

OK :) But AFAIK, there is no standard for exception numbers
 to be THROW-ed.

Here are some bench/tests (THROW/CATCH borrowed from Julien Fondren post):

~$ time gforth-fast b.fs -e 'bench.e/e bye'

real    0m0.261s
user    0m0.252s
sys     0m0.008s
~$ time gforth-fast b.fs -e 'bench.e/c bye'

real    0m0.306s
user    0m0.298s
sys     0m0.008s
~$ time gforth-fast b.fs -e 'bench.c/t bye'

real    0m0.790s
user    0m0.784s
sys     0m0.004s

\  e/e means 'ESC/ESCAPES>' version
\  e/c ->    'callec'       version
\  c/t ->    'CATCH/THROW'  version

~$ gforth-fast b.fs -e 'T.ISOLATED cr bye'

Inspect '-scroll'
--> : 0 0

--> : 0 59
 : 0 59

Inspect '-wrap'
--> : 0 0

--> : 0 59

--> : 0 59
 : 0 60
 : 0 60

--> : 0 1
 : 0 1

~$ gforth-fast b.fs -e 'T.INTEGRATED .s cr bye'
(78 ,58 )
(79 ,58 )
 : 0 59
(0 ,59 )
(1 ,59 )
(2 ,59 )
...
(78 ,59 )
(79 ,59 )
 : 0 59
(0 ,59 )
(1 ,59 )
...
<0>

Here is the source for b.fs:

5000000 constant CLIM  \ count limit

variable cx
variable cy

: b-edge?  ( -- f )   cy @ 59 = ;
: r-edge?  ( -- f )   cx @ 79 = ;

: -scroll.C/T  ( -- )   b-edge? IF 8 THROW THEN ;
: -wrap.C/T    ( -- )   r-edge? IF 0 cx ! -scroll.C/T 1 cy +! 8 noop THROW THEN ;
: bumped.C/T   ( -- )   -wrap.C/T 1 cx +! ;
: bench.C/T
  0 cx ! 0 cy ! CLIM 0 DO
    ['] bumped.C/T CATCH dup 8 = IF drop ELSE THROW THEN
  LOOP ;


: ESC  ( rp -- )   RP! ;
: ESCAPES>  ( xt[rp--] -- )   RP@ swap EXECUTE ;

: -scroll.E/E  ( rp -- |rp)   b-edge? IF ESC THEN ;
: -wrap.E/E    ( rp -- |rp)   r-edge? IF 0 cx ! -scroll.E/E 1 cy +! ESC THEN ;
: bumped.E/E   ( rp -- )     -wrap.E/E 1 cx +! drop ;
: bench.E/E
  0 cx ! 0 cy ! CLIM 0 DO
    ['] bumped.E/E ESCAPES>
  LOOP ;

include callec.fs

        CALL/EC: ESCPOINT>

: -scroll.E/C  ( xt -- |xt)   b-edge? IF dup execute THEN ;
: -wrap.E/C    ( xt -- |xt)   r-edge? IF 0 cx ! -scroll.E/C 1 cy +! dup execute THEN ;
: bumped.E/C    -wrap.E/C   1 cx +! ;
: bench.E/C
  0 cx ! 0 cy ! CLIM 0 DO
    ['] bumped.E/C ESCPOINT> drop
  LOOP ;


\ TESTING. For CALL/EC only.

:noname ."  : " cx ? cy ? cr ;  constant INS ( PECT)

\ Test words in isolation:
: T.ISOLATED
  cr ." Inspect '-scroll'"
  cr ." -->"  0 cx !  0 cy !  INS -scroll.E/C execute clearstack
  cr ." -->"  0 cx ! 59 cy !  INS -scroll.E/C execute clearstack

  cr ." Inspect '-wrap'"
  cr ." -->"  0 cx !  0 cy !  INS -wrap.E/C execute clearstack
  cr ." -->"  0 cx ! 59 cy !  INS -wrap.E/C execute clearstack
  cr ." -->" 79 cx ! 59 cy !  INS -wrap.E/C execute clearstack                        ;

\ Test integrated
: restore-xt-esc              \* xt-cc -- xt-esc
               >BODY  dup @   \ a xt
               CREATE swap , ,
               DOES>  2@ !
;
' ESCPOINT> restore-xt-esc restore.ESCPOINT>
: YY  ( xt xt -- xt)
  >R >R :noname R> compile, R> compile, postpone ;
;
: T.INTEGRATED
\ Modify escaping-xt
  ['] ESCPOINT> >BODY INS over @ YY swap !
\ Test
  78 cx ! 58 cy !
  90 0
  DO
     ." (" cx ? ." ," cy ? ." )" cr
     ['] bumped.E/C ESCPOINT> drop
  LOOP
\ Revert to original escaping-xt
  restore.ESCPOINT>
;

\ End of b.fs


> 
> - 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 2017: http://www.euroforth.org/ef17/


Have a nice day,
hum9

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

#59438

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2017-05-17 16:45 +0000
Message-ID	<2017May17.184527@mips.complang.tuwien.ac.at>
In reply to	#59420

humptydumpty <ouatubi@gmail.com> writes:
>On Tuesday, May 16, 2017 at 3:34:28 PM UTC+3, Anton Ertl wrote:
>> humptydumpy writes:
>> >One of quick & dirty multilevel drop that I thought is pair:
>> >
>> >: ESC  ( rp -- )   RP! ;
>> >: ESCAPES>  ( xt[rp--] -- )   RP@ swap EXECUTE ;
>> >
>> >And used something like:
>> >
>> >: escaping-word  ( .. rp -- ... )  .. IF ESC THEN ... ;
>> >: working-word   ( .. rp -- ... )  .. escaping-word ... ;
>> >: current-word   ( .. -- ... )     ['] working-word ESCAPES> ... ;   
>> 
>> What's wrong with
>> 
>> : escaping-word  ( .. -- ... )  .. THROW ... ;
>> : working-word   ( .. -- ... )  .. escaping-word ... ;
>> : current-word   ( .. -- ... )     ['] working-word CATCH ... ;
>
>Is not OK because if an exception happens in 'working-word' or
>in his lower level called words, that exception is CATCH-ed as
>if it was THROW-ed inside 'escaping-word'.

True; so you better throw a specific ball, and if CATCH catches
something else, it throws it onwards.

>Also, ESC/ESCAPES> has 2 one-liners, total 6 forth-words.
>THROW/CATCH  has 66 lines, total 181 forth-words - from gforth sources.
>Difference of complexity, size and speed is easily seen.

THROW and CATCH and their complexity and size don't go away if you use
ESC.  As for speed, ESC/ESCAPES> may not work on compilers that give
good speed.  This results in the following options:

1) Forego the speed advantages of inlining and tail-call elimination
everywhere in order to support ESC/ESCAPES> etc. without incurring
analysis effort.

2) At least recognize that there is return-address manipulation going
on, and disable inlining and tail-call elimination in that case.  The
recognition may cost more complexity and size than the implementation
of CATCH and THROW, and the disabling will hit much more code than
just the words that contain ESC/ESCAPES>.

3) Build a full-blown analysis of return-address data-flow and use the
results for optimization.  In cases where this succeeds, you get the
full speed, but the complexity is likely to be thousands of lines (and
lots of bugs).

>> and it's standard.
>
>OK :) But AFAIK, there is no standard for exception numbers
> to be THROW-ed.

Actually, there is: There are standard and system-defined throw code
assignments in the range -4095...-1, and the rest can be used by
programs as they please.

There is, admittedly a problem when you write a library and need to
define an exception value.  But given the widespread "Libraries are
evil!" attitude (among others), I see little chance in getting a
library-oriented proposal like
<http://www.forth200x.org/exception.html> accepted, and therefore have
not even tried.

- 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 2017: http://www.euroforth.org/ef17/

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

#59836

From	obi65537@gmail.com
Date	2017-05-25 12:04 -0700
Message-ID	<362f4652-8030-4fad-867e-a942b6bdb236@googlegroups.com>
In reply to	#59438

On Wednesday, May 17, 2017 at 8:13:08 PM UTC+3, Anton Ertl wrote:
> humptydumpty writes:
> >On Tuesday, May 16, 2017 at 3:34:28 PM UTC+3, Anton Ertl wrote:
> >> humptydumpy writes:
> >> >One of quick & dirty multilevel drop that I thought is pair:
> >> >
> >> >: ESC  ( rp -- )   RP! ;
> >> >: ESCAPES>  ( xt[rp--] -- )   RP@ swap EXECUTE ;
> >> >
> >> >And used something like:
> >> >
> >> >: escaping-word  ( .. rp -- ... )  .. IF ESC THEN ... ;
> >> >: working-word   ( .. rp -- ... )  .. escaping-word ... ;
> >> >: current-word   ( .. -- ... )     ['] working-word ESCAPES> ... ;   
> >> 
> >> What's wrong with
> >> 
> >> : escaping-word  ( .. -- ... )  .. THROW ... ;
> >> : working-word   ( .. -- ... )  .. escaping-word ... ;
> >> : current-word   ( .. -- ... )     ['] working-word CATCH ... ;
> >
> >Is not OK because if an exception happens in 'working-word' or
> >in his lower level called words, that exception is CATCH-ed as
> >if it was THROW-ed inside 'escaping-word'.
> 
> True; so you better throw a specific ball, and if CATCH catches
> something else, it throws it onwards.
> 
> >Also, ESC/ESCAPES> has 2 one-liners, total 6 forth-words.
> >THROW/CATCH  has 66 lines, total 181 forth-words - from gforth sources.
> >Difference of complexity, size and speed is easily seen.
> 
> THROW and CATCH and their complexity and size don't go away if you use
> ESC.  As for speed, ESC/ESCAPES> may not work on compilers that give
> good speed.  This results in the following options:
> 
> 1) Forego the speed advantages of inlining and tail-call elimination
> everywhere in order to support ESC/ESCAPES> etc. without incurring
> analysis effort.
> 
> 2) At least recognize that there is return-address manipulation going
> on, and disable inlining and tail-call elimination in that case.  The
> recognition may cost more complexity and size than the implementation
> of CATCH and THROW, and the disabling will hit much more code than
> just the words that contain ESC/ESCAPES>.
> 
> 3) Build a full-blown analysis of return-address data-flow and use the
> results for optimization.  In cases where this succeeds, you get the
> full speed, but the complexity is likely to be thousands of lines (and
> lots of bugs).


1. Not every Forth implementation should be a native optimizing compiler.

2. Sane Forth native optimizing compiler implementations should switch
optimization per defined word, as user needs.

As for ESC/ESCAPES> it is needed to turn off automatic inlining & TCO
just those 2 words: 'ESC' 'ESCAPES>'.  For 'callec' just turn off
inlining & TCO for the anonymous definition and for DOES> part. 


> 
> - 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 2017: http://www.euroforth.org/ef17/

Have a nice day,
hum9

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

#59850

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2017-05-26 10:02 +0000
Message-ID	<2017May26.120243@mips.complang.tuwien.ac.at>
In reply to	#59836

obi65537@gmail.com writes:
>On Wednesday, May 17, 2017 at 8:13:08 PM UTC+3, Anton Ertl wrote:
>> humptydumpty writes:
>> >On Tuesday, May 16, 2017 at 3:34:28 PM UTC+3, Anton Ertl wrote:
>> >> humptydumpy writes:
>> >> >One of quick & dirty multilevel drop that I thought is pair:
>> >> >
>> >> >: ESC  ( rp -- )   RP! ;
>> >> >: ESCAPES>  ( xt[rp--] -- )   RP@ swap EXECUTE ;
>> >> >
>> >> >And used something like:
>> >> >
>> >> >: escaping-word  ( .. rp -- ... )  .. IF ESC THEN ... ;
>> >> >: working-word   ( .. rp -- ... )  .. escaping-word ... ;
>> >> >: current-word   ( .. -- ... )     ['] working-word ESCAPES> ... ;   
>> >> 
>> >> What's wrong with
>> >> 
>> >> : escaping-word  ( .. -- ... )  .. THROW ... ;
>> >> : working-word   ( .. -- ... )  .. escaping-word ... ;
>> >> : current-word   ( .. -- ... )     ['] working-word CATCH ... ;
[...]
>> >Also, ESC/ESCAPES> has 2 one-liners, total 6 forth-words.
>> >THROW/CATCH  has 66 lines, total 181 forth-words - from gforth sources.
>> >Difference of complexity, size and speed is easily seen.
>> 
>> THROW and CATCH and their complexity and size don't go away if you use
>> ESC.  As for speed, ESC/ESCAPES> may not work on compilers that give
>> good speed.  This results in the following options:
>> 
>> 1) Forego the speed advantages of inlining and tail-call elimination
>> everywhere in order to support ESC/ESCAPES> etc. without incurring
>> analysis effort.
>> 
>> 2) At least recognize that there is return-address manipulation going
>> on, and disable inlining and tail-call elimination in that case.  The
>> recognition may cost more complexity and size than the implementation
>> of CATCH and THROW, and the disabling will hit much more code than
>> just the words that contain ESC/ESCAPES>.
>> 
>> 3) Build a full-blown analysis of return-address data-flow and use the
>> results for optimization.  In cases where this succeeds, you get the
>> full speed, but the complexity is likely to be thousands of lines (and
>> lots of bugs).
>
>
>1. Not every Forth implementation should be a native optimizing compiler.

Not sure I agree with "should be", but anyway, let's talk about "is".
Yes, there are Forth systems that do not produce native code and
optimize.

If we want to make a fast CATCH and THROW on such systems, we can do
so, and then it might be faster to THROW than to 2DROP R> DROP FDROP ESC.

But even if that was not the case, should we add features to the
language that make fast implementations slower (and not just when
using this feature) and/or more complicated in order to allow a usage
that saves some time on a slow system?  If the users were interested
in speed, they would switch to a fast system.

>2. Sane Forth native optimizing compiler implementations should switch
>optimization per defined word, as user needs.
>
>As for ESC/ESCAPES> it is needed to turn off automatic inlining & TCO
>just those 2 words: 'ESC' 'ESCAPES>'.  For 'callec' just turn off
>inlining & TCO for the anonymous definition and for DOES> part. 

Either a programming language has a feature or it doesn't.

If it has the feature, then the compiler, including the optimizer,
must implement it correctly, and switching optimization off is
unnecessary; that's the scenario I discussed above.

If the programming language does not have the feature, the optimizer
may do things you do not have in mind, and then turning off the
optimizer per word may not achieve what you want.  E.g., in the
example above, the WORKING-WORD may keep the updated value of a stack
item in %r11 while calling ESCAPING-WORD and do some more with it
afterwards and eventually store the final value into memory before the
";".  And CURRENT-WORD expects that stack value there.  When
ESCAPING-WORD perfoorms its non-local exit, the value of that memory
location will not be up-to-date.  So, despite having turned off the
optimizer for ESC and ESCAPES>, the Forth system does not work as you
intended.

Turning off optimization may be a system-version-specific way to get
some behaviour that is not a proper feature of that system, but is not
a stable and portable solution to get that behaviour.

- 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 2017: http://www.euroforth.org/ef17/

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

#59859

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2017-05-26 07:46 -0500
Message-ID	<ndGdnX0hW-A7vrXEnZ2dnUU7-QmdnZ2d@supernews.com>
In reply to	#59850

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> obi65537@gmail.com writes:
> 
> But even if that was not the case, should we add features to the
> language that make fast implementations slower (and not just when
> using this feature) and/or more complicated in order to allow a usage
> that saves some time on a slow system?  If the users were interested
> in speed, they would switch to a fast system.

That's not entirely sound reasoning.  Fast is good, small is good,
simple is good.  Every Forth system chooses some mix of these.  It's
wrong to say that someone who wants a simple system and is prepared
somewhat to compromise speed to get simplicity is not interested in
speed.

Andrew.

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

#59868

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2017-05-26 13:53 +0000
Message-ID	<2017May26.155351@mips.complang.tuwien.ac.at>
In reply to	#59859

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> obi65537@gmail.com writes:
>> 
>> But even if that was not the case, should we add features to the
>> language that make fast implementations slower (and not just when
>> using this feature) and/or more complicated in order to allow a usage
>> that saves some time on a slow system?  If the users were interested
>> in speed, they would switch to a fast system.
>
>That's not entirely sound reasoning.  Fast is good, small is good,
>simple is good.  Every Forth system chooses some mix of these.  It's
>wrong to say that someone who wants a simple system and is prepared
>somewhat to compromise speed to get simplicity is not interested in
>speed.

Sure, in that case you choose some balance between speed and
simplicity.  Does that give you the right to demand that other systems
become slower and/or more complicated so that you can use a technique
that may save time on your system?

- 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 2017: http://www.euroforth.org/ef17/

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

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

csiph-web

Would ?EXIT work in all ANS-Forth systems?

Contents

#59357

#59358

#59361

#59367

#59426

#59428

#59429

#59430

#59235

#59242

#59248

#59339

#59352

#59368

#59420

#59438

#59836

#59850

#59859

#59868