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

Groups > comp.lang.forth > #33856

Re: uninitialized and implicitly initialized locals (was: More ranting)

From mhx@iae.nl (Marcel Hendrix)
Subject Re: uninitialized and implicitly initialized locals (was: More ranting)
Newsgroups comp.lang.forth
Message-ID <78179291938433@frunobulax.edu> (permalink)
Date 2014-10-12 11:18 +0200
References <658808e2-74fc-47d0-8d54-85f51e1466e2@googlegroups.com>
Organization SunSITE.dk - Supporting Open source

Show all headers | View raw

Bernd Paysan <bernd.paysan@gmx.de> writes Re: uninitialized and implicitly initialized locals (was: More ranting)

> BTW: I know you have made the design decision of using rsp as data stack, 
> and rbp as return stack.  The consequence is that you can't use call, but 
> you have to push return addresses pretty much manually on the return stack.

Actually no, iForth uses <call> if you instruct it to do so by inverting
this entry in iForth.prf:

[DEFINED] XCALL-used@ 
  [IF]  TRUE  XCALL-used! ( jmp imm | call )
[THEN]

E.g.
FORTH> TRUE  XCALL-used!  ok
FORTH> : (test) params| a b c | a b + c ;  : test 1 2 3 (test) . . ;   ok
FORTH> see test
Flags: ANSI
$01220A80  : test
$01220A8A  push          3 b#
$01220A8C  push          3 b#
$01220A8E  lea           rbp, [rbp -8 +] qword
$01220A92  mov           [rbp 0 +] qword, $01220A9F d#
$01220A9A  jmp           .+10 ( $0113A97A ) offset NEAR
$01220A9F  jmp           .+10 ( $0113A97A ) offset NEAR
$01220AA4  ;
FORTH> FALSE  XCALL-used!  ok
FORTH> : (test) params| a b c | a b + c ;  : test 1 2 3 (test) . . ;
Redefining (test)
Redefining test  ok
FORTH> see test
Flags: ANSI
$01220B40  : test
$01220B4A  push          3 b#
$01220B4C  push          3 b#
$01220B4E  call          . ( $0113A970 ) offset NEAR
$01220B53  jmp           .+10 ( $0113A97A ) offset NEAR
$01220B58  ;

You may note that all iForth non-inlined words have a standard prologue
than can be skipped.

> That comes at a cost: the CPU actually has an internal return stack used to 
> predict rets (to a limited level of call depth, which is probably enough for 
> Forth to work almost perfectly).  The costs of using something other than 
> esp as data stack comes at a cost, too - you can't do push/pop.  The way 
> push/pop are implemented now probably means just more code space used, but 
> no performance degradation if you do it manually - actually, IIRC, the 
> Pentium was the last x86 CPU which could do two pushs or pops in one cycle; 
> starting with the Pentium Pro, there's a sp update register dependency which 
> prevents the CPU to do more than one push/pop per cycle, while you certainly 
> can do more than one of those moves with offset per cycle (as long as you 
> merge all stack pointer updates to the start/end of one basic block).

This is the theory, and I looked into that a long time ago. At that time, in 
practice, push and pop proved to be slow no matter what I did. TRUE XCALL-used! 
is better than FALSE XCALL-used!. One possible explanation might be that the 
internal return stack looked at ALL rsp-related operations (not just calls).
At the time, I thought having 16 registers would minimize the number of push/pops
to a very low number and that therefore the effect, if it existed at all, would
not be noticeable.

Maybe I should do these benchmarks again.

Experiments with mxforth (oh my, how long ago that is) indicated that 
having rbp for the datastack is MUCH better than rsp. Also, caching the top of the 
(rbp) data stack in a register is much better than letting the compiler 
allocate it, especially if I want to win a particular standard (recursive) 
benchmark.

> Have you done some calculation on the tradeoffs?  I'm pretty sure I would go 
> for rsp as return stack, and rbp or some other easily used pointer register 
> as data stack, even though then push/pop sequences are out of question.  But 
> that's because Intel has stopped making them run real fast a long time ago.

At the time I wanted to make it possible that a C function could call Forth
directly. 
Changing rbp<->rsp is on my list of things to do. (It is a long list and at 
the moment I much prefer using Forth over 'improving' it).

-marcel

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

Thread

Re: Why smudge? hughaguilar96@yahoo.com - 2014-09-30 19:25 -0700
  Re: Why smudge? november.nihal@gmail.com - 2014-10-01 08:54 -0700
    Re: Why smudge? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-01 19:09 +0000
  Re: Why smudge? november.nihal@gmail.com - 2014-10-01 10:16 -0700
    Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-01 18:54 -0700
  Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-02 15:31 -0700
    Re: Why smudge? Michael Barry <barrym95838@yahoo.com> - 2014-10-02 16:35 -0700
      Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-02 17:02 -0700
        Re: Why smudge? Michael Barry <barrym95838@yahoo.com> - 2014-10-02 17:51 -0700
          Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-02 18:50 -0700
        Re: Why smudge? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-04 00:30 +0100
          Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-03 17:40 -0700
            Re: Why smudge? Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-10-03 23:00 -0700
              Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-04 21:14 -0700
                Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-05 03:42 -0500
                Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Enoch <emc.consultants@gmail.com> - 2014-10-05 10:43 -0700
                Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-05 20:21 -0700
                Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-06 03:58 -0500
                Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-05 17:09 -0700
                Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Michael Barry <barrym95838@yahoo.com> - 2014-10-06 11:15 -0700
                Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-06 18:52 -0700
                More ranting Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-07 03:48 -0500
                Re: More ranting albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-07 12:43 +0000
                Re: More ranting Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-07 16:23 +0200
                Re: More ranting "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-16 01:03 -0400
                Re: More ranting Just Ian <superian@gmail.com> - 2014-10-16 07:14 -0700
                Re: More ranting Michael Barry <barrym95838@yahoo.com> - 2014-10-16 13:23 -0700
                uninitialized and implicitly initialized locals (was: More ranting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-07 15:36 +0000
                Re: uninitialized and implicitly initialized locals (was: More ranting) Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-07 22:15 +0200
                Re: uninitialized and implicitly initialized locals (was: More ranting) mhx@iae.nl - 2014-10-07 15:07 -0700
                Re: uninitialized and implicitly initialized locals (was: More ranting) Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-08 03:11 +0200
                Re: uninitialized and implicitly initialized locals (was: More ranting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-08 13:25 +0000
                Re: uninitialized and implicitly initialized locals (was: More ranting) hughaguilar96@yahoo.com - 2014-10-09 16:22 -0700
                Re: uninitialized and implicitly initialized locals (was: More ranting) "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-17 21:58 -0400
                Re: uninitialized and implicitly initialized locals (was: More ranting) mhx@iae.nl (Marcel Hendrix) - 2014-10-12 11:18 +0200
                Re: uninitialized and implicitly initialized locals (was: More ranting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-08 12:35 +0000
                Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-07 15:27 -0500
                Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-08 12:56 +0000
                Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-08 08:24 -0500
                Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-08 15:32 +0000
                Simplified automatic scoping (was: uninitialized ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-08 16:06 +0000
                Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-08 11:57 -0500
                Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-08 12:18 -0500
                Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-09 14:19 +0000
                Re: uninitialized and implicitly initialized locals hughaguilar96@yahoo.com - 2014-10-09 14:42 -0700
                Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-09 14:07 +0000
                Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-09 10:44 -0500
                Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-10 16:03 +0000
                Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-10 13:35 -0500
                Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-11 10:53 +0000
                Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-12 11:34 -0500
                Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-15 12:44 +0000
                Re: uninitialized and implicitly initialized locals albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-15 14:34 +0000
                Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-15 15:03 +0000
                Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-15 11:10 -0500
                Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-16 12:19 +0000
                Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-17 03:56 -0500
                Re: uninitialized and implicitly initialized locals "Elizabeth D. Rather" <erather@forth.com> - 2014-10-17 07:48 -1000
                Re: uninitialized and implicitly initialized locals hughaguilar96@yahoo.com - 2014-10-17 19:26 -0700
                Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-18 12:55 +0000
                Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-18 13:21 -0500
                Re: uninitialized and implicitly initialized locals "Elizabeth D. Rather" <erather@forth.com> - 2014-10-18 08:44 -1000
                Re: uninitialized and implicitly initialized locals albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-19 09:53 +0000
                Re: uninitialized and implicitly initialized locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-20 12:48 +0000
                Re: uninitialized and implicitly initialized locals "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-20 16:24 -0400
                Re: uninitialized and implicitly initialized locals "Elizabeth D. Rather" <erather@forth.com> - 2014-10-20 10:30 -1000
                Re: uninitialized and implicitly initialized locals hughaguilar96@yahoo.com - 2014-10-20 16:23 -0700
                Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 04:16 -0500
                Re: uninitialized and implicitly initialized locals mhx@iae.nl (Marcel Hendrix) - 2014-10-26 11:32 +0200
                Re: uninitialized and implicitly initialized locals stephenXXX@mpeforth.com (Stephen Pelc) - 2014-10-26 14:27 +0000
                Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 13:56 -0500
                Re: uninitialized and implicitly initialized locals mhx@iae.nl (Marcel Hendrix) - 2014-10-26 20:32 +0200
                Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 16:18 -0500
                Re: uninitialized and implicitly initialized locals hughaguilar96@yahoo.com - 2014-10-26 15:05 -0700
                Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 17:53 -0500
                Re: uninitialized and implicitly initialized locals hughaguilar96@yahoo.com - 2014-10-26 16:30 -0700
                Re: uninitialized and implicitly initialized locals "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-27 01:45 -0400
                Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-27 12:21 -0500
                Re: uninitialized and implicitly initialized locals Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-26 17:57 -0500
                Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-06 20:55 +0100
                Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-06 16:05 -0700
                Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-09 07:36 +0100
                Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! stephenXXX@mpeforth.com (Stephen Pelc) - 2014-10-10 01:52 +0000
                Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! hughaguilar96@yahoo.com - 2014-10-09 19:56 -0700
                Re: Pelc's effort to sabotage cross-compiler writing has a work-around now! "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-17 23:11 -0400
            Re: Why smudge? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-05 11:05 +0100
              Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-05 19:48 -0700
                Re: Why smudge? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-06 07:53 +0100
                Re: Why smudge? "Elizabeth D. Rather" <erather@forth.com> - 2014-10-05 21:29 -1000
              Re: Why smudge? hughaguilar96@yahoo.com - 2014-10-09 15:16 -0700
              Re: Why smudge? "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-16 01:03 -0400

csiph-web