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

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

Would ?EXIT work in all ANS-Forth systems?

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

Contents

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

#59176

On Saturday, May 13, 2017 at 9:25:09 AM UTC-5, Rudy Velthuis wrote:
>
> Indeed. Now I am wondering what the fun is about. Why the LOL! and whom
> are you telling this?
>

Lotta direct questions here for Mr. "I can imagine some solutions /
nah too much work to state any / you're being hyperbolic, saying there
ain't any / yeah well *I* believe in *other* *solutions* (that I won't
tell you about)".

> I already said it won't work in general, but it
> may work on *some* indirect threading systems (obviously the ones that
> do not do inlining or tail-recursion optimization and that push two
> cells when entering a definition).

The two cells is probably a mistake.

The technique also works on direct threading systems and on native-coded
systems: gforth (usually direct-threaded), iForth, SwiftForth, VFX, for a lot
of examples. There's no 'indirect threading' connection at all. Your "that'll
work with *some* indirect threading systems" is why you're getting laughed at.

Inlining and TCO are problems one would have with an optimizer, not a threading
model, and Forths with inlining and TCO therefore have optimizer directives to
help permit return-stack manipulation.

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

#59285

Julian Fondren wrote:

> On Saturday, May 13, 2017 at 9:25:09 AM UTC-5, Rudy Velthuis wrote:
> > 
> > Indeed. Now I am wondering what the fun is about. Why the LOL! and
> > whom are you telling this?
> > 
> 
> Lotta direct questions here for Mr. "I can imagine some solutions /
> nah too much work to state any / you're being hyperbolic, saying there
> ain't any / yeah well I believe in other solutions (that I won't
> tell you about)".

Hmmm... ISTM that my previous reply to this did not come through yet.
So again:

I see I made some friends here.

Fact is that using recognizers is certainly not the only way, or the
only *extensible* way to do this. It is nice, and works well, but it is
certainly not the only way to do this.

And no, I will not write a new system for this. Why should I? Just
because I can imagine different ways?

That it is the *only* way this can be done is hyperbole. If that is not
what was meant, then it should have been worded differently.

-- 
Rudy Velthuis        http://www.rvelthuis.de

Ninety-ninety Rule Of Project Schedules: The first ninety percent 
of the task takes ninety percent of the time, and the last ten 
percent takes the other ninety percent.

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

#59299

Julian Fondren wrote:

> Lotta direct questions here for Mr. "I can imagine some solutions /
> nah too much work to state any / you're being hyperbolic, saying there
> ain't any / yeah well I believe in other solutions (that I won't
> tell you about)".

Oh, I see I made friends. <g> 

Sorry if that stepped on people's toes, but heck, what I say is true.
Recognizers are certainly not the only way to handle such things, or
even just the only *extensible* way to handle such things. Such things
are handled by others as well, and I bet most of them don't use
recognizers.

And no, there is no need for me to write a new system just to see that
it was hyperbole. I don't have to design a new car to make the remark
that, say, a car with an USB slot is not unique.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"O'Toole's Corollary of Finagle's Law: The perversity of the 
 Universe tends towards a maximum."

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

#59170

lehs wrote:

> Den fredag 12 maj 2017 kl. 16:20:24 UTC+2 skrev Rudy Velthuis:
> > lehs wrote:
> > 
> > > : ?exit ( flag -- )  if 2r> 2drop then ;
> > > 
> > > I'm doing a kind of filtering word and want to replace  IF EXIT
> > > THEN with  ?EXIT if this works.
> > 
> > Probably only on indirectly threaded systems, and even there, there
> > may be more or fewer items on the return stack.
> > 
> > -- 
> > Rudy Velthuis        http://www.rvelthuis.de
> > 
> > "In the 1980s capitalism triumphed over communism. In the 1990s
> >  it triumphed over democracy."
> >  -- David Korten
> 
> Yes you are right. Anton Ertls suggestion is perfect:
> 
> : ?exit postpone if postpone exit postpone then ; immediate 

Well yes, of course.


-- 
Rudy Velthuis        http://www.rvelthuis.de

"In all large corporations, there is a pervasive fear that 
 someone, somewhere is having fun with a computer on company time. 
 Networks help alleviate that fear." -- John C. Dvorak.

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

#59262

ANS Forth define the return stack as "A stack that may be used for program execution nesting, do-loop execution, temporary storage, and other purposes." No return stack address techniques are ANS portable. But if it works and you don't need the code to be portable it's still possible to do.

But ANS-Forth is general enough to make the most code portable (except for calls of peripherals as the screen). There is always a nice solution.

But I wonder why the portability is important for the embedding industry? Is it for educational purposes? It seems there could be two standards: one very small that defines Forth and an ever expanding Forth striving for portability of all kind of utilities used in desktop computing.

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

#59265

EXIT is portable as much as DUP DROP are portable.
That's why I suggest a RETURN word, so you don't have
to research how to do it in a system or another.
It's a nice word to have in Forth due to the forth nature.
In other languages it is almost impossible I think
(anyway not that simple and elegant as in forth).

Also, ?EXIT is another nice word to have.
Implementation may be different among the systems
but once you have it right, it's usefull and elegant.

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

#59280

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>Also, ?EXIT is another nice word to have.
>Implementation may be different among the systems
>but once you have it right, it's usefull and elegant.

You can easily implement it in standard Forth:

: ?EXIT ( -- ) ( compilation -- ; run-time nest-sys f -- | nest-sys )
    POSTPONE if POSTPONE exit POSTPONE then ; immediate

As has been discussed a few months ago, you often want to put some
cleanup stuff between the IF and the EXIT, so ?EXIT is not that useful.

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

#59267

Den måndag 15 maj 2017 kl. 08:23:18 UTC+2 skrev lehs:
> ANS Forth define the return stack as "A stack that may be used for program execution nesting, do-loop execution, temporary storage, and other purposes." No return stack address techniques are ANS portable. But if it works and you don't need the code to be portable it's still possible to do.
> 
> But ANS-Forth is general enough to make the most code portable (except for calls of peripherals as the screen). There is always a nice solution.
> 
> But I wonder why the portability is important for the embedding industry? Is it for educational purposes? It seems there could be two standards: one very small that defines Forth and an ever expanding Forth striving for portability of all kind of utilities used in desktop computing.

In the ever expanding Forth the return addresses could defined to be on the return stack. If there is no need for a hardware stack there is no need for hidden return addresses.

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

#59278 — Return-address manipulation (was: Would ?EXIT ...)

lehs <skydda.barnen@gmail.com> writes:
>In the ever expanding Forth the return addresses could defined to be on the=
> return stack. If there is no need for a hardware stack there is no need fo=
>r hidden return addresses.

There are other reasons, too; they were not as prominent at the time
of Forth-94 standardization, but now they are:

* Forth systems use tail-call elimination and inlining; both
  optimizations mean that the return address that a traditional system
  would put on the return stack is not there.

* Locals need to be cleaned up if present.

Some people propose putting in a lot of effort to make return-address
manipulation work in the presence of these issues.

In particular, Bernd Paysan proposed to deal with tail-call
elimination and inlining by doing data-flow analysis of the return
addresses and then using that information to implement the control
flow intended by the programmer.

One problem with that is that there are cases where you do not get
precise information out of the data-flow analysis (e.g., in connection
with EXECUTE; you can solve some of these cases with more data-flow
analysis, but not all).

The other issue is that we end up with a lot of complex mechanism to
preserve the behaviour of an implementation model that our compilers
no longer follow.  Is this the Forth way?

Or should we rather use programming techniques that fit our
implementation techniques better, e.g., THROW for multi-level exits,
and quotations for some other uses of return-address manipulation?
Or, alternatively, turn off tail-call elimination and inlining, and
take a significant performance hit, in order to continue to use
return-address manipulation?

For dealing with locals, Bernd Paysan proposed UNLOCAL (similar to
UNLOOP), so you would write

: foo {: ... :} 
   ... ?do
   ... if
      unloop unlocal r> drop unloop unlocal exit then
   ... loop
   ... ;

: bar {: ... :}
   ... ?do
      ... foo ... loop
   ... ;

in order to perform a two-level exit from FOO to the caller of BAR.

We implemented UNLOCAL in connection with our attempt to make 

['] exit execute

work
<http://www.complang.tuwien.ac.at/anton/euroforth/ef15/papers/ertl.pdf>

Despite revising the implementation quite a lot, there remained a
mismatch between the implementation and the programming model that led
to complications in the implementation and wrong behaviour in corner
cases.  Fixing that would have required even more implementation
complexity, or a slower implementation even for code that does not use
return-address manipulation.  Eventually (after the paper linked above
was published) Bernd Paysan himself ripped much of the complications
out again.  ['] EXIT EXECUTE reverted to not performing the execution
semantics of EXIT, and UNLOCAL did not work properly in many cases, so
I then ripped that out.

Conclusion: supporting return-address manipulation constrains you a
lot in the rest of the Forth system, in particular when it comes to
performance-enhancing techniques.  Is this feature worth this price,
or are we better off using alternative programming techniques that do
not put as heavy constraints on the 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]

#59297 — Re: Return-address manipulation (was: Would ?EXIT ...)

On Mon, 15 May 2017 08:47:22 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>We implemented UNLOCAL in connection with our attempt to make 
>
>['] exit execute
>
>work

The interpretation action of EXIT is undefined. Within a word, making
the compilation action of EXIT sensitive to locals is easy. Outside
a word making the UNLOCAL portion of EXIT sensitive to some
word or other is a complication too far. I, for one, am not going
there.

>Conclusion: supporting return-address manipulation constrains you a
>lot in the rest of the Forth system, in particular when it comes to
>performance-enhancing techniques.  Is this feature worth this price,
>or are we better off using alternative programming techniques that do
>not put as heavy constraints on the system?

It's worth looking at Michael Gassanenko's return stack manipulation
wordset - I don't have the reference to hand. That wordset does at
least make return address manipulation code much easier to identify
and port.

I note that such activity splits words into separately compiled
portions and we have no way to identify the portions. Such an
identification is also needed in DOES>. I suspect that allowing for
return address manipulators and word portions in the standard
is more practical than just saying "don't do that". 

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#59369 — Re: Return-address manipulation (was: Would ?EXIT ...)

stephen@mpeforth.com (Stephen Pelc) writes:
>On Mon, 15 May 2017 08:47:22 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>We implemented UNLOCAL in connection with our attempt to make 
>>
>>['] exit execute
>>
>>work
>
>The interpretation action of EXIT is undefined. Within a word, making
>the compilation action of EXIT sensitive to locals is easy. Outside
>a word making the UNLOCAL portion of EXIT sensitive to some
>word or other is a complication too far. I, for one, am not going
>there.

Right.  We tried to go there, and found that it is even more trouble
than we expected, and eventually went back.  A slightly longer version
of that story is in the posting you replied to.

>>Conclusion: supporting return-address manipulation constrains you a
>>lot in the rest of the Forth system, in particular when it comes to
>>performance-enhancing techniques.  Is this feature worth this price,
>>or are we better off using alternative programming techniques that do
>>not put as heavy constraints on the system?
>
>It's worth looking at Michael Gassanenko's return stack manipulation
>wordset - I don't have the reference to hand. That wordset does at
>least make return address manipulation code much easier to identify
>and port.

I remember that Gordon Charlton proposed such a wordset.

>I note that such activity splits words into separately compiled
>portions and we have no way to identify the portions.

As for identifying, if you are analytical about return addresses, you
can identify this stuff relatively easily: when a definition accesses
anything on the return stack that it did not put there, it has left
the realm of the standard.

Alternatively, you could require the programmers to use Gordon
Charlton's words.  But I think that those who don't want to rewrite
their programs to use quotations, CATCH and THROW, or macros (which
covers the vast majority of return-address manipulations), won't be
using Gordon Charlton's words, either.

> Such an
>identification is also needed in DOES>.

DOES> identifies itself.  But yes, it's another case of using
return-address manipulation to divide a definition into several parts
that are executed at different times, and different numbers of times.
It could be replaced with a better-behaved word, such as

<does-create ( xt "name" -- )

used as in:

: myconst ( n ) ['] @ <does-create , ;

Further advantages:

* No overwriting problem on flash-based systems.

* Can be used interpretively.

>I suspect that allowing for
>return address manipulators and word portions in the standard
>is more practical than just saying "don't do that". 

Yes, "don't do that" alone is insufficient, as evidenced by the fact
that return-address manipulation is still used and advocated.  We also
need to provide good alternatives.  In particular, quotations are an
alternative in many cases.

Will having these alternatives standardized be enough to wean
programmers and clf posters off return-address manipulation?  For some
probebly yes, for others maybe not; after all, it's so cool to be able
to do this, and you cannot do it in most other languages.

As for standardization, I don't think that we will be able to
standardize it in a way that works with locals.  And having two
mutually exclusive features (locals and return-address manipulation)
in the same standard is a bad idea.

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

#59370 — Re: Return-address manipulation (was: Would ?EXIT ...)

> DOES> identifies itself.  But yes, it's another case of using
> return-address manipulation to divide a definition into several parts
> that are executed at different times, and different numbers of times.
> It could be replaced with a better-behaved word, such as
> 
> <does-create ( xt "name" -- )
> 
> used as in:
> 
> : myconst ( n ) ['] @ <does-create , ;
> 
> Further advantages:
> 
> * No overwriting problem on flash-based systems.
> 
> * Can be used interpretively.
> 

I have BUILD and IBUILD words that do the same thing using 
quotations (or just anonymous embedded definitions):

: enum  \ <name> val -- val+1 , name: -- val
  { @ } ibuild
  dup , 1+ ;

: field  \ <name> offset size -- offset+size , name: x -- x+offset
  { @ eval + } ibuild
  over , + ;

{ ... } are the quotations.
IBUILD builds immediate words (for the sake of having optimizing
built words - for example ENUMs will compile literals, FIELDs will
do constant folding).
EVAL is an "ugly" state-smart optimizing compiling word. 
Anyone not liking this can do:

: field  \ <name> offset size -- offset+size , name: x -- x+offset
  { @ + } ibuild
  over , + ;

:D

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

#59372 — Re: Return-address manipulation (was: Would ?EXIT ...)

marți, 16 mai 2017, 17:06:59 UTC+3, Raimond Dragomir a scris:
> > DOES> identifies itself.  But yes, it's another case of using
> > return-address manipulation to divide a definition into several parts
> > that are executed at different times, and different numbers of times.
> > It could be replaced with a better-behaved word, such as
> > 
> > <does-create ( xt "name" -- )
> > 
> > used as in:
> > 
> > : myconst ( n ) ['] @ <does-create , ;
> > 
> > Further advantages:
> > 
> > * No overwriting problem on flash-based systems.
> > 
> > * Can be used interpretively.
> > 
> 
> I have BUILD and IBUILD words that do the same thing using 
> quotations (or just anonymous embedded definitions):
> 
> : enum  \ <name> val -- val+1 , name: -- val
>   { @ } ibuild
>   dup , 1+ ;
> 
> : field  \ <name> offset size -- offset+size , name: x -- x+offset
>   { @ eval + } ibuild
>   over , + ;
> 
> { ... } are the quotations.
> IBUILD builds immediate words (for the sake of having optimizing
> built words - for example ENUMs will compile literals, FIELDs will
> do constant folding).
> EVAL is an "ugly" state-smart optimizing compiling word. 
> Anyone not liking this can do:
> 
> : field  \ <name> offset size -- offset+size , name: x -- x+offset
>   { @ + } ibuild
>   over , + ;
> 
> :D

And I also have $BUILD and $IBUILD variants that expects the
name on the stack (they are the base words in fact for the
parsing BUILD and IBUILD).

Here is an example of how simple you can create a lot of
words from a simple definition (like a class of words):

\ Stacks
\ v1.23 12jan2016
\ =============================================================================
\ usage:
\   256 stack:new S
\ then we have the following words:
\   S         -- a        address of the whole stack structure (good for dump)
\   S:clear   --          reset the stack
\   S:push    x --        push x on S stack
\   S:pop     -- x        pop x from S stack
\   S:peek    -- x        peek x from S stack (doesn't pop it)

\ The entire stack data structure will consists of one first cell used as the
\ stack pointer followed by the actual data buffer.

: stack:new \ <name> size --
  bl parse              \ size str len
  here @ >r             \ size str len     R: ptr    ptr points to our memory area (fifo)
  2dup $data            \                            <name> is just as any other var
  rot 1+                \ str len size+1             one more cell for stack pointer
  cells allot           \ str len          R: ptr    allocate the memory
  r@ cell+ r@ !         \                            init the stack
  2dup s" :clear" strcat { @ cell+ dup cell- ! }        $build r@ ,
  2dup s" :push"  strcat { @ tuck @ ! w swap +! }       $build r@ ,
  2dup s" :pop"   strcat { @ dup w negate swap +! @ @ } $build r@ ,
       s" :peek"  strcat { @ @ cell- @ }                $build r> ,
;

It's almost like a library! (oops).

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

#59268

On 5/14/17 8:23 PM, lehs wrote:
...
> But I wonder why the portability is important for the embedding industry? Is it for educational purposes? It seems there could be two standards: one very small that defines Forth and an ever expanding Forth striving for portability of all kind of utilities used in desktop computing.
>

It's an interesting question, particularly since virtually every 
embedded system is characterized by custom hardware (replacing, added 
to, or driven by a micro-controller board), so the possibility of 
porting a whole program is essentially non-existent.

The answers are numerous, IMO, and include:

* The need to reuse specific techniques or algorithms that are 
independent of hardware.

* The need to be able to easily identify the parts of code that need 
attention when porting.

* Programmer portability (the more techniques that are shared, the less 
re-training is required).

What more can you add?

In late 90's I worked hard on a draft standard for embedded systems, 
based on work done by Forth, Inc. and MPE. I still think it would be 
useful to have a separate standard (maybe a superset of Forth 20xx) 
dealing with issues peculiar to cross compilers.


Cheers,
Elizabeth

-- 
Elizabeth D. Rather
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

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

#59294

On Sun, 14 May 2017 21:58:51 -1000, "Elizabeth D. Rather"
<erather@forth.com> wrote:

>In late 90's I worked hard on a draft standard for embedded systems, 
>based on work done by Forth, Inc. and MPE. I still think it would be 
>useful to have a separate standard (maybe a superset of Forth 20xx) 
>dealing with issues peculiar to cross compilers.

That draft standard will require a lot of work to allow for
changes in cross-compiler design sign then. The proposal 
worked for Europay because the FI and MPE cross compilers
used very similar internal structures, leading to a compatible
notation that was easy to implement.

Essentially, the ASSEMBLER scope will not have much to offer
until there is compatibility of assemblers; and there's fat chance
of that. INTERPRETER scope defines compiler directives and there's
certainly a chance of stndardising a lot of that. COMPILER scope
just doesn't work interoperably at the moment, but could be renamed
and probably made to work. Leon and I have discussed this several
times.

I have a play cross-compiler in development to explore this, but do
not have enough time to complete it. Both Leon and I are busy, so
don't hold your breath.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [standalone]

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

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

csiph-web