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

Groups > comp.lang.forth > #21321

Re: Difficulty with Brad Rodriguez' screenful

Show all headers | View raw

Anton Ertl wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>But it's in a lot of Forth systems.  The point with "misreading the
>>standard" is that something that didn't made it into the standard, isn't a
>>language feature.
> 
> I think you mean that it can still be a language feature.  Yes, but
> then it's a non-standard language feature.

Yes, as Elizabeth explained, standards seek for least common denominator.  
Some language features may be too hard to standardize.  When we complain 
about GCC, we usually complain, because they take away things that are in 
our opinion language features, though not standardized features.  They 
pessimize computed gotos?  We need them.  They fail on overflow?  We need 
that.  They don't provide double sized words on 64 bit systems?  Those all 
are not standard language features.

Sometimes, when they are used often enough, they become language features.  
Especially GCC is in a position to create new language features, it's 
already a de facto standard.

>>This sort of things are things which contribute to the "portable
>>assembler"
>>semantics of the Forth VM.  In an assembler, return addresses are really
>>there, and you can access them.
> 
> In an assembler, yes, if the machine supports it, in a portable
> assembler, not necessarily.
> 
> E.g., C was a portable assembler without return-address manipulation;

That's wrong, too.  You can manipulate your return address in C, but the 
usual programs that use that feature is malware, and they use the feature of 
C to allow random input to manipulate the return address ;-).  The way to 
manipulate the return address is even "standardized", it's platform 
specific, but it works across all C compilers on one plattform; the thing is 
called ABI.

> it also had relatively little else to offer for dealing with certain
> forms of control flow; that's a deficiency that should be addressed in
> some way, but I don't think that return-address manipulation is the
> best way to do it.

There are certain uses of return stack trickery which certainly benefit from 
quotations.

> Or, to get back to Forth, many Forth systems support accessing the
> stack in memory, and some might think that's a language feature worth
> supporting in more systems and in a "portable assembler edition" of
> Forth, but I don't think so.

Even the ANS Forth Standard rationale contains a definition of CATCH and 
THROW that make use of this fact.  This is also used in the (not 
standardized) simple multi-tasker which comes with Gforth EC.  So why do you 
think this is not something nice to have?

There are Forth systems which don't have a memory accessible stack, usually 
in the size of the b16.  Nobody claims that the b16 assembly language is 
standard Forth.  It's too small to be fully standard, it doesn't make sense 
to implement an ANS Forth system on such small hardware.

When we are looking for least common denonimantors here, we would have to 
split core into some "baseline core", which is somewhat less than normal 
core.

On the other hand, b16 assembler provides you with things that a portable 
assembler would feature, too, but standard Forth doesn't, like multiple 
entry points.  Though it doesn't need much carnal knowledge to implement 
another entry point; all you need is REVEAL and the knowledge how big a 
orig-sys is, and then the additional entry point is a piece of cake (this is 
for Gforth):

: [:] reveal postpone ahead 2>r >r : r> 2r> postpone then ; immediate

Test it:

: foo ." Foo "
[:] bar ." Bar" ;  ok
foo Foo Bar ok
bar Bar ok

> I think that, in a portable assembler edition it's better to make the
> return addresses that you want to manipulate explicit instead of
> having all the implicit ones that are generated by calls available for
> manipulation.  That approach may also be a better way for general
> Forth.

I don't quite see why you call those "implicit".  This is Forth, this isn't 
C, where the fact that there is a return address is tucked away in some ABI.  
The return stack is something that beginners literature like Starting Forth 
explains.  This is part of the language model, though it is not a standard 
feature.  Where do you think return addresses are created if not in a call?

>>Annotating EXECUTE/DEFER is an optimization, the annotation format is
>>probably something like a stack effect.  If you annotate it, the default
>>would be "it's not doing return stack trickery".  Annotations like this
>>are usually for code generators, e.g. an OOP system can put the annotation
>>into the method invocation code.
> 
> Which would mean that one could not use that OOP system in the
> return-address manipulating code.

No, you just have to deliberately annotate those methods which do use that 
stuff.  I don't see much of a problem here: You should do that anyways, it's 
somehow part of the stack effect.  Return-address manipulating code has a 
visible return stack effect, and should say so.

> I am not a fan of implementing language features by having complex
> compilers recognize special idioms of other features.  Instead, the
> feature should be made explicit.

Me, too.  It's not about recognizing special idioms.  It is just this thing:  
A call pushes an address to the return stack.  This address is the code 
space that immediately follows that call.  If you inline, you have to 
transform this property accordingly.

> Concerning skip-one-level, is that the language feature?

It's a consequence of having user-mainpulations of the return stack 
available.

> Or is there
> some other purpose that may be less problematic to implement; maybe,
> having two different return targets for the call?

This feature is not problematic to implement.

>>Works as expected, the output is identical to Gforth.
> 
> It's no wonder that the tail-call optimization did not trigger in an
> example that has no tail calls.
> 
> Try one that has a tail call:
> 
> : a r> drop ;
> : b a ;
> : c ." <c" b ." c>" ;
> : d ." <d" c ." d>" ;
> d
> 
> Gforth says:
> <d<cc>d>
> 
> while SwiftForth says:
> <d<cd>

IMHO the main reason why early exits and tail call optimizations usually 
don't clash is that it doesn't make sense to call an early-exit word as last 
word.  The whole point of doing the early exit is that it makes a 
difference.

>>> 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.
>>
>>libcc.h gives access to the throw_jump_handler, because that's needed for
>>the pthreads stuff.  And a throw from C is just a
>>longjmp(*throw_jump_handler, code).  It may not be formally documented,
>>but it is very straight-forward, and actually documenting it might benefit
>>people who use the C interface - because they then can add throws inside C
>>code.
> 
> And if we do that, we could decide to specify that only codes in a
> certain range are allowed, leaving open the option to heroically
> optimize such a CATCH.

I'd expect that most libcc.fs users would throw errno-generated throw codes 
from their C code, because that makes the most sense.

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