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

Groups > comp.lang.forth > #21279

Re: Difficulty with Brad Rodriguez' screenful

Show all headers | View raw

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.  It doesn't work on all 
possible implementations, which is why the standard weasel words around its 
existence.  But this is exactly the same thing the C standard does when 
concerning overflows, and the GCC maintainer used that weasel words as lame 
excuse to their weird optimization of a loop that runs 31 times into an 
infinite loop.  Or eliminating all the conditional code after if(x<x+1).

> 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, unless you 
find out by inlining and constant folding that the EXECUTE is going to just 
one word, and then you can inline that and proof that it doesn't do return 
stack tricks.

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

> 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.  This adds absolutely nothing to the 
complexity.

> Yes, words with internal EXIT also need that
> if they are inlined.  But if a compiler writer does not do that work
> (yet), your feature excludes all words from inlining that call EXECUTE
> or deferred words directly or indirectly.

Yes.  EXECUTE and related are by the way the Forth virtual machine works 
pretty much blockers of any optimization beyond them.  You don't know how 
much they affect the stack, so you need a full canonization, and the result 
is even worse: it renders the stack effect of the word that contains EXECUTE 
into "unknown", which means that you can't fold any constants beyond that 
EXECUTE.  E.g.

Defer foo ( -- )

...
2 3 foo +

could be optimized to

foo 5

if we knew that foo really does what it's stack effect promises us.  IIRC, 
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.

>>However, as far as I know, the only return stack
>>trickery that usually crosses an EXECUTE/DEFER boundary is that of THROW.
> 
> If your language feature is "return-address manipulation like in the
> systems before inlining and tail-call optimization", that does not
> help the compiler.  It still has to implement your language feature.

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.

> If your feature is something else, how do you justify it?  And if
> somebody happens to replace a regular word with a DEFERred word in a
> piece of code that uses return-address manipulation, it would be
> pretty nasty if that code stopped working.

Yes.

>> And when you need
>>an early termination from a higher order function, you can just do the
>>RDROP EXIT trick, and the compiler can convert that into a
>>straight-forward jump.
> 
> So you suggest crossing an EXECUTE with RDROP EXIT?

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.

>>Come on Anton, now compare that to you insisting on COMPILE,'s semantics.
> 
> I have used it and you have used it, and probably Michael Gassananko,
> too.  And probably others.
> 
> Also look at the cost side.  A correct COMPILE, costs little, whereas
> your feature requires complicating inlining compilers and reduces the
> benefit of inlining and an analytic compiler.

Anton, you still don't understand: There is no way to have a correct 
COMPILE,, because the definition differs from the intent *and* the usage.  
It's broken.  You either limit the way to deal with special compilation 
semantics to the attempts that didn't work very well, or break the user-
written compiler.  IIRC, MPE's smart COMPILE, came last, after people tried 
sepearate wordlists (cmForth - fail), special double-xt headers (works for 
colon words, failed for create-does> words, which is the majority of words 
where I need special compilation semantics), and of course it came after 
state-smart words, which are the most troublesome.

That's certainly not the intention of the standard.

>>Nobody uses what you want, except you yourself, and it's non-standard.
> 
> Read the standard!  BTW, you found the DEFERS definition that uses it
> yourself, and it was not written by me.

A standard program shall not ' a special compilation semantics word (I think 
we agree that the allowance to ' S" is limited to the kernel S", which does 
not have special compilation semantics - it's just a normal immediate word), 
since all other words like IS and TO are mentioned.  So a standard program 
can't say

' to is some-deferred-word

Since it can't do this, the wrong definition of DEFERS is not a real 
problem.  In any case, the definition of DEFERS can be fixed, as we probably 
want to entitle people to ' special-compilation semantics, and then do what 
they like with it.  I found it, because I was looking for this kind of 
problems.  And my point was: Whether you use the new, "broken" COMPILE, 
here, or the correct POSTPONE LITERAL POSTPONE EXECUTE doesn't matter.  Both 
work.

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

>>> I outlined how a heroic compiler could optimize CATCH and THROW in an
>>> answer to Andrew Haley.
>>
>>As long as we keep CATCHing signals, we can't.
> 
> 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?  In any case, this sounds like 
real heoric stuff to me.  The compiler knows that this CATCH is re-THROWn 
for all throw-codes that come from a signal handler, so it can optimize away 
the effort to deal with signal handlers.  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.

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

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

Thread

Re: Difficulty with Brad Rodriguez' screenful stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-18 12:40 +0000
  Re: Difficulty with Brad Rodriguez' screenful Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-18 17:23 +0100
    Re: Difficulty with Brad Rodriguez' screenful stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-18 17:35 +0000
      Re: Difficulty with Brad Rodriguez' screenful Brad Eckert <hwfwguy@gmail.com> - 2013-03-18 11:02 -0700
      Re: Difficulty with Brad Rodriguez' screenful "WJ" <w_a_x_man@yahoo.com> - 2013-03-19 03:25 +0000
    Re: Difficulty with Brad Rodriguez' screenful albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-18 19:35 +0000
  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