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

Groups > comp.lang.forth > #21291

Re: Difficulty with Brad Rodriguez' screenful

Show all headers | View raw

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>>>It still can.  It only needs to fill in the return stack with data when it
>>>calls EXECUTE and DEFER.
>> 
>> Ok, that can be done.  But you lose much of the benefit of inlining:
>> With your language feature, you have to treat every original return
>> address as control-flow boundary and have to reach the canonical stack
>> state there, unless you can prove that the address is never returned
>> to, which you cannot prove for words that call EXECUTE or DEFERred
>> words directly or indirectly.
>
>Yes.  That's how the language works.  What you suggest is to misread the 
>standard, and redefine the language to something it isn't, because that 
>allows you to optimize things which breaks programs.
>
>Can you please move to the GCC team?  This is not a language feature I 
>invented, this is a language feature Chuck invented.

For quite some time Chuck Moore's Forths have used tail-call
optimization, so he apparently has not considered this feature as
important as you do.

Concerning "misreading the standard", it's a feature that's not in the
standard.  We can discuss whether it would be a good idea if this
feature were in the standard or not, or maybe some other feature that
provides the same benefits; we can also discuss whether our system
provides this feature.  But if you make counterfactual claims, there
will not be any productive discussion.

>> Now EXITs are every 6-8 primitives
>> dynamically, so your feature might seriously limit the benefit of an
>> analytical compiler.
>
>Supposed the inner loop does some EXECUTE or DEFER.  This usually breaks 
>most of the benefits of an analytic inlining compiler, anyways

Yes, it means we have to return to the canonical stack representation
at the EXECUTE or the call to the deferred word.  With your feature,
there are now a number of additional places where we have to return to
the canonical stack representation: Dynamically viewed, one for every
return address that's on the return stack.

>> In addition, you replace every call with an rpush and every EXIT with
>> an rpop unless you can prove that that's not needed.
>
>Yes.  Which is the whole point of optimization: You have to do all the 
>things the language model does, unless you can prove that it is not 
>necessary.

Yes, but we have not yet agreed that the return addresses are part of
the language model or just an artifact of the implementation.

>> Also, it's not as simple as just adding another stack, because the
>> return addresses you push are influenced by inlining (and other
>> transformations); that requires quite a bit of work, not just one
>> index more in an array.
>
>Ah, come on, that is an open forward reference; something an analytic 
>compiler has to deal with anyhow.

An analytic compiler that deals only with basic blocks (like VFX) does
not have to do this anyway.  VFX still does it, but there it's extra
complexity.

>we had some discussions about this problem a while ago, and the idea was to 
>annotate EXECUTEs and related words with their respective stack effect, 
>which helps the compiler.  That's a good idea, and such an annotation also 
>could be made wrt. return stack.  Then you can optimize.

You mean that almost every EXECUTE and DEFERred word should be
annotated as not calling words that manipulate return addresses above
the EXECUTE/DEFERred word?

>Or you add some non-default optimization switch, which allows the user to 
>say "I don't use this language feature in this part of the code".  It's not 
>a sane default.

I am not comfortable with a regional optimization switch for a feature
that has the potential for very non-local effects.  It should rather
be an annotation switch; the difference being that the annotation can
have a non-local effect, it just makes it unnecessary to annotate
every EXECUTE or DEFER.

Even so I am uncomfortable with the amount of compiler complexity that
you assume as given.  It essentially means that only complex compilers
are allowed to inline or tail-call optimize.

>This is a possible way to do it, and it is just a counter-argument: If you 
>do implement this feature right in the inlining compiler, it offers an 
>opportunity for optimization that wasn't there before, and that's easier to 
>do than CATCH/THROW heroics.

I am not convinced of CATCH/THROW heroics myself (also assumes a very
complex compiler).  Instead, I wonder if there is a quotation-like
solution for the remaining uses of return-address manipulation.  I.e.,
many of your uses of return addresses could be expressed in a way that
does not need return-address manipulation with quotations (and some of
us think that it's also more readable).  Maybe we can find such
solutions for the remaining uses, too.

[COMPILE, discussion]

I will answer that elsewhere.

>On the other hand, adding an inliner that doesn't work with return stack 
>trickery would instantly fail.

SwiftForth does not work with return stack trickery (and it does not
even have an inliner).  I think there are a number of SwiftForth users
that don't agree that it has failed.

>> Sure we can.  Take a look at the example again.  Hint: Signals don't
>> throw a REGEXP-BALL.
>
>How do you know?  How does the compiler know?

It knows because the compiler is part of the system and the system's
signal handler does not throw a REGEXP-BALL.

>In any case, this sounds like 
>real heoric stuff to me.

Yes, that's what I wrote.  But to me also your optimization ideas and
Andrew Haleys ideas about optimizing CATCH-THROW into something
cheaper sound more heroic and complex than I want to implement.

> Gforth's C interface allows you to 
>change the signal handler to whatever you want at run-time, so a compiler 
>just can't assume that the standard system signal handler is in place.

There is no documented way to THROW from the signal handler, so making
a signal handler do REGEXP-BALL THROW is not supported by Gforth.

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

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-18 18:17 +0000
  Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-19 03:29 +0100
    Re: Difficulty with Brad Rodriguez' screenful Paul Rubin <no.email@nospam.invalid> - 2013-03-19 00:06 -0700
      Re: Difficulty with Brad Rodriguez' screenful Paul Rubin <no.email@nospam.invalid> - 2013-03-19 00:11 -0700
        Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-19 16:16 +0100
    Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-19 15:06 +0000
      Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-19 22:27 +0100
        Re: Difficulty with Brad Rodriguez' screenful Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-20 03:49 -0500
          Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-20 11:09 +0000
            Re: Difficulty with Brad Rodriguez' screenful Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-20 10:25 -0500
              Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-20 18:08 +0100
                Re: Difficulty with Brad Rodriguez' screenful Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-20 13:04 -0500
                Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-20 20:12 +0100
                Re: Difficulty with Brad Rodriguez' screenful Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-21 04:39 -0500
                Re: Difficulty with Brad Rodriguez' screenful albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-20 19:22 +0000
              Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-30 17:35 +0000
                Re: Difficulty with Brad Rodriguez' screenful Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-31 08:51 -0500
                Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-02 15:50 +0000
                Re: Difficulty with Brad Rodriguez' screenful Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-02 16:16 -0500
                Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-03 11:57 +0000
                Re: Difficulty with Brad Rodriguez' screenful Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-03 10:25 -0500
                Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-03 16:45 +0000
                Re: Difficulty with Brad Rodriguez' screenful Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-03 15:12 -0500
                Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-04 15:29 +0000
                Re: Difficulty with Brad Rodriguez' screenful Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-05 09:11 -0500
            Re: Difficulty with Brad Rodriguez' screenful Alex McDonald <blog@rivadpm.com> - 2013-03-20 10:27 -0700
        Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-20 12:03 +0000
          Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-20 18:47 +0100
            Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-30 16:40 +0000
              Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-01 02:12 +0200
                Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-01 16:58 +0000
                Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-02 04:20 +0200
                Re: Difficulty with Brad Rodriguez' screenful "Elizabeth D. Rather" <erather@forth.com> - 2013-04-01 16:39 -1000
                Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-02 14:15 +0000
                Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-02 21:12 +0200
                Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-04 13:58 +0000
                Re: Difficulty with Brad Rodriguez' screenful Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-02 04:17 -0500
                Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-02 15:35 +0000
                Re: Difficulty with Brad Rodriguez' screenful Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-02 16:36 -0500
                Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-03 04:10 +0200
                Re: Difficulty with Brad Rodriguez' screenful Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-03 04:03 -0500
                Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-03 21:14 +0200
                Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-03 16:13 +0000
                Re: Difficulty with Brad Rodriguez' screenful Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-03 11:54 -0500
                Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-03 22:24 +0200
                Re: Difficulty with Brad Rodriguez' screenful stephenXXX@mpeforth.com (Stephen Pelc) - 2013-04-04 11:53 +0000
                Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-04 18:13 +0200
                Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-04 15:53 +0000
                Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-04 22:11 +0200
                Re: Difficulty with Brad Rodriguez' screenful Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-04-04 21:35 +0100
                Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-04 23:06 +0200
                Re: Difficulty with Brad Rodriguez' screenful stephenXXX@mpeforth.com (Stephen Pelc) - 2013-04-05 10:57 +0000
                Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-05 14:47 +0000
                Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-05 14:28 +0000
                Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-06 03:35 +0200
                Re: Difficulty with Brad Rodriguez' screenful "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-04-08 23:50 -0400
                Re: Difficulty with Brad Rodriguez' screenful "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-04-08 23:49 -0400
                Re: Difficulty with Brad Rodriguez' screenful m.a.m.hendrix@tue.nl - 2013-04-05 02:49 -0700
                Re: Difficulty with Brad Rodriguez' screenful anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-04-05 14:55 +0000
                Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-05 22:05 +0200

csiph-web