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

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

made it to page 4 of gforth tutorial

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

Contents

  made it to page 4 of gforth tutorial gavino <gavcomedy@gmail.com> - 2011-04-17 00:34 -0700
    Re: made it to page 4 of gforth tutorial "The Beez'" <hansoft@bigfoot.com> - 2011-04-17 02:29 -0700
    Re: made it to page 4 of gforth tutorial alberto pasquale <alberto@hal-pc.org> - 2011-04-18 12:55 -0700
      Re: made it to page 4 of gforth tutorial "The Beez'" <hansoft@bigfoot.com> - 2011-04-18 14:45 -0700
        Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-19 09:06 +0000
      Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-18 20:30 -0700
      Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-18 20:33 -0700
      Re: made it to page 4 of gforth tutorial David Kuehling <dvdkhlng@gmx.de> - 2011-04-19 13:04 +0200
        Re: made it to page 4 of gforth tutorial mhx@iae.nl (Marcel Hendrix) - 2011-04-19 22:09 +0200
          Re: made it to page 4 of gforth tutorial "The Beez'" <hansoft@bigfoot.com> - 2011-04-19 23:40 -0700
            Re: made it to page 4 of gforth tutorial mhx@iae.nl (Marcel Hendrix) - 2011-04-20 21:27 +0200
              Re: made it to page 4 of gforth tutorial alberto pasquale <alberto@hal-pc.org> - 2011-04-20 14:56 -0700
                Re: made it to page 4 of gforth tutorial stephenXXX@mpeforth.com (Stephen Pelc) - 2011-04-20 22:42 +0000
                Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-20 22:26 -0700
                Re: made it to page 4 of gforth tutorial mhx@iae.nl (Marcel Hendrix) - 2011-04-21 20:51 +0200
                Re: made it to page 4 of gforth tutorial Marc Olschok <nobody@nowhere.invalid> - 2011-04-26 16:40 +0000
                  Re: made it to page 4 of gforth tutorial Bernd Paysan <bernd.paysan@gmx.de> - 2011-04-26 22:23 +0200
                    Re: made it to page 4 of gforth tutorial Alex McDonald <blog@rivadpm.com> - 2011-04-26 13:34 -0700
                  Re: made it to page 4 of gforth tutorial anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-27 14:48 +0000
              Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-21 04:07 -0500
                Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-21 07:38 -0700
                  Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-21 08:10 -0700
                    Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-22 12:35 +0000
                      Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-22 08:51 -0700
                        Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-23 10:17 +0000
                      Re: made it to page 4 of gforth tutorial gavino <gavcomedy@gmail.com> - 2011-04-23 18:05 -0700
                  Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-21 11:16 -0500
                    Re: made it to page 4 of gforth tutorial anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-23 11:26 +0000
                      Re: made it to page 4 of gforth tutorial gavino <gavcomedy@gmail.com> - 2011-04-23 18:07 -0700
                      Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-24 00:10 -0700
                Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-21 11:38 -0700
                  Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-21 15:13 -0500
                    Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-21 14:07 -0700
                      Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-21 15:05 -0700
                        Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-21 15:24 -0700
                          Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-22 12:48 +0000
                            Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-22 10:51 -0700
                        Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-21 17:41 -0700
                      Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-21 18:16 -0700
                        Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-21 18:58 -0700
                          Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-21 19:49 -0700
                            Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-22 00:02 -0700
                              Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-22 06:59 -0700
                                Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-23 01:20 -0700
                          Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-21 21:11 -0700
                            Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-22 00:16 -0700
                              Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-22 10:12 -0700
                              Re: made it to page 4 of gforth tutorial Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-04-23 07:38 +0100
                                Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-25 00:05 -0700
                                  Re: made it to page 4 of gforth tutorial Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-04-25 13:34 +0100
                                    Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-25 08:50 -0700
                                    Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-25 23:11 -0700
                            Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-22 00:18 -0700
                              Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-22 10:19 -0700
                                Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-25 10:43 -0700
                                  Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-25 13:17 -0700
                                    Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-25 16:32 -0700
                                      Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-25 18:21 -0700
                                        Re: made it to page 4 of gforth tutorial Charles G Montgomery <cgm@physics.utoledo.edu> - 2011-04-26 19:36 -0400
                                          Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-26 21:05 -0700
                                          Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-26 23:36 -0700
                                            Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-27 08:57 -0700
                                              Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-28 11:53 +0000
                                                Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-29 22:21 -0700
                                            Re: made it to page 4 of gforth tutorial Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-04-27 17:41 +0100
                                              Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-27 09:53 -0700
                                    Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-26 11:39 +0000
                                  Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-25 23:22 -0700
                                    Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-26 17:51 -0700
                              Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-23 10:33 +0000
                                Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-25 00:48 -0700
                                  Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-29 22:24 -0700
                            Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-22 09:44 -0700
                              Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-22 11:36 -0700
                                Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-22 17:08 -0700
                                  Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-23 18:11 -0700
                              Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-23 00:49 -0700
                                Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-23 03:55 -0500
                                  Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-23 14:47 -0700
                                Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-23 11:12 -0700
                                  Re: made it to page 4 of gforth tutorial Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-04-30 16:33 +0100
                                    Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-05-01 23:03 -0700
                                      Re: made it to page 4 of gforth tutorial Bernd Paysan <bernd.paysan@gmx.de> - 2011-05-02 22:15 +0200
                                        Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-05-02 19:15 -0700
                                      Re: made it to page 4 of gforth tutorial Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-05-04 08:14 +0100
                                        Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-05-04 00:51 -0700
                                          Re: made it to page 4 of gforth tutorial Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-05-04 22:03 +0100
                                  Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-30 03:15 -0500
                                    Re: made it to page 4 of gforth tutorial Elizabeth D Rather <erather@forth.com> - 2011-05-01 19:04 -1000
                                  Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-27 22:58 -0700
                                    Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-28 03:37 -0500
                                      Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-28 08:54 -0700
                                        Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-28 12:12 -0500
                                          Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-28 21:34 -0700
                                            Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-29 02:27 -0500
                                              Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-29 15:09 -0700
                                            Re: made it to page 4 of gforth tutorial Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-05-02 21:47 -0700
                                        Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-28 10:49 -0700
                                          Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-28 21:57 -0700
                                            Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-05-03 13:28 -0700
                                      Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-28 11:01 -0700
                                Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-23 14:02 -0700
                                  Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-25 07:08 -0700
                                    Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-26 10:47 -0700
                                      Re: made it to page 4 of gforth tutorial Alex McDonald <blog@rivadpm.com> - 2011-04-26 10:58 -0700
                                      Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-27 22:39 -0700
                                        Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-28 10:43 -0700
                                        Re: made it to page 4 of gforth tutorial David Thompson <dave.thompson2@verizon.net> - 2011-05-05 04:39 -0400
                                          Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-05-05 04:10 -0500
                            Re: made it to page 4 of gforth tutorial stephenXXX@mpeforth.com (Stephen Pelc) - 2011-04-23 09:53 +0000
                              Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-23 14:59 -0700
                                Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-23 16:10 -0700
                                Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-05-01 23:47 -0700
                                  Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-05-03 14:23 -0700
                                    Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-05-04 01:48 -0700
                                      Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-05-04 05:23 -0500
                                      Re: made it to page 4 of gforth tutorial John Passaniti <jpassaniti@ashly.com> - 2011-05-04 11:17 -0700
                                        Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-05-04 12:03 -0700
                              Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-23 23:59 -0700
                                Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-05-01 23:48 -0700
                      Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-22 03:22 -0500
                        Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-22 10:28 -0700
                          Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-22 12:37 -0500
                            Re: made it to page 4 of gforth tutorial David Kuehling <dvdkhlng@gmx.de> - 2011-04-22 20:07 +0200
                              Re: made it to page 4 of gforth tutorial anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-22 18:55 +0000
                                Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-23 23:25 -0700
                                  Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-24 03:27 -0500
                                    Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-24 20:20 -0700
                                      Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-25 03:24 -0500
                                      Re: made it to page 4 of gforth tutorial Elizabeth D Rather <erather@forth.com> - 2011-04-25 11:55 -1000
                                        Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-25 23:45 -0700
                                          Re: made it to page 4 of gforth tutorial Elizabeth D Rather <erather@forth.com> - 2011-04-25 21:49 -1000
                                            Re: made it to page 4 of gforth tutorial Alex McDonald <blog@rivadpm.com> - 2011-04-26 02:39 -0700
                                          Re: made it to page 4 of gforth tutorial Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-04-26 03:19 -0700
                                  Re: made it to page 4 of gforth tutorial anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-26 10:01 +0000
                              Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-23 03:43 -0500
                                Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-23 23:53 -0700
                                  Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-24 20:27 -0700
                                    Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-25 03:35 -0500
                                      Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-26 00:20 -0700
                                        Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-26 04:02 -0500
                                          Re: made it to page 4 of gforth tutorial Bernd Paysan <bernd.paysan@gmx.de> - 2011-04-26 22:40 +0200
                                    Re: made it to page 4 of gforth tutorial Alex McDonald <blog@rivadpm.com> - 2011-04-25 14:16 -0700
                                      Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-25 23:25 -0700
                                        Re: made it to page 4 of gforth tutorial Alex McDonald <blog@rivadpm.com> - 2011-04-26 02:47 -0700
                                    Re: made it to page 4 of gforth tutorial anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-26 10:22 +0000
                                      Re: made it to page 4 of gforth tutorial Alex McDonald <blog@rivadpm.com> - 2011-04-26 10:45 -0700
                                      Re: made it to page 4 of gforth tutorial mhx@iae.nl (Marcel Hendrix) - 2011-04-26 22:19 +0200
                                        Re: made it to page 4 of gforth tutorial mhx@iae.nl (Marcel Hendrix) - 2011-04-27 21:05 +0200
                            Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-22 11:44 -0700
                          Re: made it to page 4 of gforth tutorial Elizabeth D Rather <erather@forth.com> - 2011-04-22 11:46 -1000
                            Re: made it to page 4 of gforth tutorial Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-04-23 08:02 +0100
                            Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-23 23:46 -0700
                            Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-24 01:32 -0700
                              Re: made it to page 4 of gforth tutorial Elizabeth D Rather <erather@forth.com> - 2011-04-24 08:36 -1000
                                Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-24 19:43 -0700
                                Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-24 21:07 -0700
                                Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-25 11:04 +0000
                                  Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-25 23:02 -0700
            Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-20 18:17 -0700
          Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-21 15:19 -0700
            Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-21 15:27 -0700
    Re: made it to page 4 of gforth tutorial gavino <gavcomedy@gmail.com> - 2011-04-21 16:54 -0700
      Re: made it to page 4 of gforth tutorial gavino <gavcomedy@gmail.com> - 2011-04-21 17:09 -0700
      Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-21 17:57 -0700
      Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-21 18:33 -0700

Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9  Next page →

#1407

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>  17 dup dup * over * dup . * . 4913 83521  ok
>> Is there a shortage of stack slots?  Why not
> 
> Well, I thought Forth was often associated with memory-starved embedded
> cpu's.  The GA processors have 10 data stack levels and 9 return stack
> levels if I understand it right, but maybe it's actually just 8 levels
> each.  Of course they also haves no multiplier and no OVER...

Oh, I see.  I have no personal experience of such systems, and it's
not something that users of Standard Forth tend to worry much about.

Andrew.

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

#1421

On Apr 22, 12:22 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Paul Rubin <no.em...@nospam.invalid> wrote:
>
> Oh, I see.  I have no personal experience of such systems, and it's
> not something that users of Standard Forth tend to worry much about.

I suppose I should have added that no machineForth programs or code
on F21 or i21 needed more hardware stack space than was available
including direct to hardware optimized native code (mostly) standard
ANS implementations.

However iTV management wanted portable ANS code for the browser and
email and the network protocols. It was done in ANS which required
conventional stacks in external memory, and the stack pointers
needed by certain ANS words.  The ANS code did use about thirty
stack cells in its apps.  It also tended to be at least ten times
larger and a hundred times slower than machineForth code.  But
management wanted a simple threaded ANS implementation rather
than an optimizing native code compiler with the stacks in
memory using stack pointers as required by ANS design.

Even though the threaded ANS code was very slow and large compared
to machineForth code the system still booted and went online in
a couple of seconds and loaded web pages as fast as a PC with
a similar cheap modem and phone line.  The OS and GUI, except
for network protocols, were much faster than popular PC software
and the network code was plenty fast for the modem.  If we had
used an ethernet connection we would have wanted to recode the
network protocols in machineForth to be able to keep up with it.

Best Wishes

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

#1423

foxchip <fox@ultratechnology.com> wrote:
> 
> However iTV management wanted portable ANS code for the browser and
> email and the network protocols. It was done in ANS which required
> conventional stacks in external memory, and the stack pointers
> needed by certain ANS words.  The ANS code did use about thirty
> stack cells in its apps.  It also tended to be at least ten times
> larger and a hundred times slower than machineForth code.  But
> management wanted a simple threaded ANS implementation rather than
> an optimizing native code compiler with the stacks in memory using
> stack pointers as required by ANS design.

What aspect of ANS actually requires stack pointers, though?  The only
word I can think of is DEPTH, but I don't think it's very much used in
standard programs.  There's certainly nothing in Standard Forth that
requires stacks to be in addressable memory.

Andrew.

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

#1428

> Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:

>> foxchip <fox@ultratechnology.com> wrote:
>>> 
> However iTV management wanted portable ANS code for the browser and
>> email and the network protocols. It was done in ANS which required
>> conventional stacks in external memory, and the stack pointers needed
>> by certain ANS words.  The ANS code did use about thirty stack cells
>> in its apps.  It also tended to be at least ten times larger and a
>> hundred times slower than machineForth code.  But management wanted a
>> simple threaded ANS implementation rather than an optimizing native
>> code compiler with the stacks in memory using stack pointers as
>> required by ANS design.

> What aspect of ANS actually requires stack pointers, though?  The only
> word I can think of is DEPTH, but I don't think it's very much used in
> standard programs.  There's certainly nothing in Standard Forth that
> requires stacks to be in addressable memory.

What about PICK and ROLL?

David

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

#1433

David Kuehling <dvdkhlng@gmx.de> writes:
>
>> Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>
>>> foxchip <fox@ultratechnology.com> wrote:
>>> with the stacks in memory using stack pointers as
>>> required by ANS design.
>
>> What aspect of ANS actually requires stack pointers, though?  The only
>> word I can think of is DEPTH

Nope, does not require stacks in memory, it just requires a kind of
stack depth counter.  The stack depth counter used in Chuck Moore's
chips for keeping track of the TOS would do, if there was a way for
the program to read it (AFAIK there is not).

AFAIK hardware manufacturers were involved in Forth-94.  They made
sure that any feature that really would require stacks in main memory
(such as SP@) would not go in.

>What about PICK and ROLL?

Can be implemented without using @, so no need for a stack in main
memory.  There were postings showing the code in the past.  These
words don't come out very fast then, but who cares?

- 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 2010: http://www.euroforth.org/ef10/

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

#1479

On Apr 22, 10:55 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> Nope, does not require stacks in memory, it just requires a kind of
> stack depth counter.

Sure, in theory.  I was talking about real and practical systems.
Sure one could slow things down by ten thousand times instead of
just a hundred times but I don't know of anyone ever thinking
it was a practical thing to do.

> The stack depth counter used in Chuck Moore's
> chips for keeping track of the TOS would do, if there was a way for
> the program to read it (AFAIK there is not).

Unfortunately there is no such thing. T is a dedicated register.
S is a dedicated register and there are circuits to connect S to
one of the registers in the circular array.  There is no counter,
no pointer, and now way to know which register is below S except
on power up.

I wonder how many dozens or hundreds of times this has been
explained in the last twenty years ....

> AFAIK hardware manufacturers were involved in Forth-94.  They made
> sure that any feature that really would require stacks in main memory
> (such as SP@) would not go in.

That was exactly my point.  We recently saw several example of
programs
in c.l.f that needed SP0 and SP@ to manipulate the ANS stack pointer
but those words, needed in real programs, were left out of the
standard.  It does help hide the requirement (for anything even 1%
practial) from being obvious in ANS.

> >What about PICK and ROLL?
>
> Can be implemented without using @, so no need for a stack in main
> memory.  There were postings showing the code in the past.  These
> words don't come out very fast then, but who cares?

In fact the standard says that stacks may not be in the same
memory space that works with @ and that standard programs can't
count on @ working where the stacks are located.  One assumes
this was a compromise for systems with segmented memory or that
had all the complications of memory managment hardware and
that also required all the complications of the stack overflow
and stack underflow exception errors related to stack pointers.
Whether words that are abominations and should be avoided could
also be made absurdly more inefficient is something that has been
discussed in c.l.f many times.

I wasn't talking about theory.  I was talking about practice
and about practice that wasn't about designs to show how awful
Forth implementations can be if that is the goal of the designer.

Best Wishes


> - 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 2010:http://www.euroforth.org/ef10/

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

#1487

foxchip <fox@ultratechnology.com> wrote:
> 
> In fact the standard says that stacks may not be in the same memory
> space that works with @ and that standard programs can't count on @
> working where the stacks are located.  One assumes this was a
> compromise for systems with segmented memory or that had all the
> complications of memory managment hardware and that also required
> all the complications of the stack overflow and stack underflow
> exception errors related to stack pointers.

It was for chips like Novix.

Andrew.

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

#1495

On Apr 24, 12:27 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> > In fact the standard says that stacks may not be in the same memory
> > space that works with @ and that standard programs can't count on @
> > working where the stacks are located.  One assumes this was a
> > compromise for systems with segmented memory or that had all the
> > complications of memory management hardware and that also required
> > all the complications of the stack overflow and stack underflow
> > exception errors related to stack pointers.
>
> It was for chips like Novix.

Like Novix? ;-) The Harris RTX was only thing even close to Novix.

The issue would appear to apply much more to Intel chips back
when people put stacks in a different memory segment than main
memory to get beyond the 64KB segment issue. It was also a way
to deal with exception hardware issues on Intel chips that
didn't exist on Novix.  Novix just used a separate memory
space and separate memory buses for its stacks in order
to be able to manipulate the data stack, the return stack,
and main memory in parallel at the same time.

Novix did have stack pointers in its stack memory spaces
and manipulating them was quite convenient for multitasking
code.  It took me a few years to understand why making
stacks much faster than when they used a stack pointer in
random access memory was more important than having a
stack pointer for the code crutch DEPTH.

Intel x86 chips were more common and were a bigger concern for
more people than Forth chips were as you well know.

There was no concern for Novix compatibility at first.  After
Chuck sold his rights to Novix patents to other people and
Forth Inc. then ported a compiler there was some concern for
Novix.  My take is that there was also concern that the
standard needed to carefully exclude every Forth chip or
software design Chuck did after Novix.

I was not on the committee but I was told by some committee
members that this bothered them a lot but that were afraid
to go against Elizabeth and others on the issue of explicitly
fencing out all of Chuck's work after 1985 and before ANS began.
They were concerned as was Chuck that each and every suggestion
that he made to the committee were summarily rejected out-of-hand
(as Chuck put it) and were never seriously considered at all.
And it is an issue I have never seen anyone discuss in public
in the last twenty-five years.  But several committee members
have complained to me about it.

I also consider it dishonest when people explain that
rejection and Chuck's statement that he realized that the
"standard was not for him" really just meant he had never
had any interest in involvement in contributing to a Forth
Standard rather than that he was simply fenced out and
didn't like it.

I don't know how big a factor the perceived need to fence out
all of Chuck's work after 1985 from the standard was in the
formation of the standard.  I just know that some committee
members said that they were disturbed by it but afraid to
say anything at the time, and that some dropped out of
the process because of it.

I doubt if the whole thing ever made many people's radar
especially considering that the way the story gets told
most often in c.l.f is that Chuck had no interest in any
Forth standard rather than him resenting being locked
out of the thing altogether, or that he is a "lone wolf"
who doesn't work with other people, or that he never
intended that anyone else use chips he designed or
software that he wrote after 1985.

Best Wishes

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

#1502

foxchip <fox@ultratechnology.com> wrote:
> On Apr 24, 12:27 am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> > In fact the standard says that stacks may not be in the same memory
>> > space that works with @ and that standard programs can't count on @
>> > working where the stacks are located.  One assumes this was a
>> > compromise for systems with segmented memory or that had all the
>> > complications of memory management hardware and that also required
>> > all the complications of the stack overflow and stack underflow
>> > exception errors related to stack pointers.
>>
>> It was for chips like Novix.
> 
> Like Novix? ;-) The Harris RTX was only thing even close to Novix.
> 
> The issue would appear to apply much more to Intel chips back when
> people put stacks in a different memory segment than main memory to
> get beyond the 64KB segment issue.

It's a consideration, perhaps.  Both possibilities exist, and both are
allowed for.

> It was also a way to deal with exception hardware issues on Intel
> chips that didn't exist on Novix. 

Exception hardware issues?

> Novix just used a separate memory space and separate memory buses
> for its stacks in order to be able to manipulate the data stack, the
> return stack, and main memory in parallel at the same time.

> Intel x86 chips were more common and were a bigger concern for more
> people than Forth chips were as you well know.

Maybe both of these were a concern.  I wasn't at the TC meetings
either, but I know Harris was represented, and there was a concern not
to exclude Forth hardware, which was at the time very interesting to
all the Forth vendors, from Standard Forth.

> There was no concern for Novix compatibility at first.  After Chuck
> sold his rights to Novix patents to other people and Forth Inc. then
> ported a compiler there was some concern for Novix.  My take is that
> there was also concern that the standard needed to carefully exclude
> every Forth chip or software design Chuck did after Novix.

I doubt this very much.  On the other hand, Chuck did make some
radical moves after Novix (which would fairly easily run a
conventional Forth) that would have been hard to accommodate in the
standard.

Andrew.

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

#1526

On 4/24/11 5:20 PM, foxchip wrote:
...
> Intel x86 chips were more common and were a bigger concern for
> more people than Forth chips were as you well know.

Of course.  It is the mission of a standard to recognize "common usage," 
which is inevitably influenced by dominant technology.

> There was no concern for Novix compatibility at first.  After
> Chuck sold his rights to Novix patents to other people and
> Forth Inc. then ported a compiler there was some concern for
> Novix.  My take is that there was also concern that the
> standard needed to carefully exclude every Forth chip or
> software design Chuck did after Novix.

I categorically deny there was any such "concern" on my part, and none 
discussed in any Standards meeting I attended (which was all of them).

> I was not on the committee but I was told by some committee
> members that this bothered them a lot but that were afraid
> to go against Elizabeth and others on the issue of explicitly
> fencing out all of Chuck's work after 1985 and before ANS began.
> They were concerned as was Chuck that each and every suggestion
> that he made to the committee were summarily rejected out-of-hand
> (as Chuck put it) and were never seriously considered at all.
> And it is an issue I have never seen anyone discuss in public
> in the last twenty-five years.  But several committee members
> have complained to me about it.

On the contrary, we made considerable efforts to include the Forth 
chips.  Harris was an active participant in the TC (even hosted one 
meeting), and it was to accomodate the needs of the Harris/Novix parts 
that the accommodation for integrating floating point and data stacks 
was put in the Standard.  Chuck was advocating FOR ... NEXT as a 
replacement for DO ... LOOP.  It would have been a violation of our 
charter as a standards body to discard DO ... LOOP (which was in 
overwhelming common usage), but we did add FOR ... NEXT in CORE EXT in 
the hope that it would be picked up by systems and users and become 
popular.  It wasn't.  After FOR ... NEXT had been in published drafts 
for nearly 4 years, we didn't find any significant number of systems 
offering it or users expecting it, so in one of the last meetings the TC 
voted unanimously to drop it.  That wasn't my proposal, either.  I would 
love to know which "several committee members" complained to you.  This 
hardly constitutes rejecting "out of hand".


> I also consider it dishonest when people explain that
> rejection and Chuck's statement that he realized that the
> "standard was not for him" really just meant he had never
> had any interest in involvement in contributing to a Forth
> Standard rather than that he was simply fenced out and
> didn't like it.

A standard is about documenting common usage.  Chuck is, and has always 
been, a creative genius, operating at the cutting edge of technology. 
These are very different goals and objectives.  Today's cutting edge may 
become tomorrow's standard, but it may not.  As a TC, it's appropriate 
to monitor and encourage innovation (such as our attempt to encourage 
adoption of FOR ... NEXT), but not to codify it before it has become 
common usage.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#1535

On Apr 25, 1:55 pm, Elizabeth D Rather <erat...@forth.com> wrote:
> > Intel x86 chips were more common and were a bigger concern for
> > more people than Forth chips were as you well know.
>
> Of course.  It is the mission of a standard to recognize "common usage,"
> which is inevitably influenced by dominant technology.

Of course.  The defintion for "common usage" is simply what you
saw most often or all of the time, ie. people using "your products."

It is simpler to say that the mission of a standard is to support
someone's product and try to make it dominant technology.

As you have said, "FORTH Inc. supported the standard and the
standard supported FORTH Inc.

> I categorically deny there was any such "concern" on my part, and none
> discussed in any Standards meeting I attended (which was all of them).

No doubt just as you denied having heard of anyone doing
optimizing native code compilers for Forth a decade before ANS
in defense of your myth that ANS Forth made optimizing native
code Forth compilers possible.  You never heard of Chuck Moore
for instance.

I once asked you if you were the only person who attended all
the meetings.  You waffled on the answer saying it was hard
for other people to pay for going to meetings all over the world
for eight years.

> On the contrary, we made considerable efforts to include the Forth
> chips.  

I said you made some effort to include the chips where Chuck no
longer had any interest.  Like the Harris RTX.

As Andrew put it the standard we got made it rather difficult
to include anything Chuck did after 1983 years before the
work on ANS began.

> Harris ....

Yes yes, that's what I said too.

> FOR ... NEXT as a replacement for DO ... LOOP.  

A simpler alternative suited to simpler chips.

> It would have been a violation of our charter as a
> standards body to discard DO ... LOOP (which was in
> overwhelming common usage), but we did add FOR ... NEXT in CORE EXT in
> the hope that it would be picked up by systems and users and become
> popular.  It wasn't.  After FOR ... NEXT had been in published drafts
> for nearly 4 years, we didn't find any significant number of systems
> offering it or users expecting it, so in one of the last meetings the TC
> voted unanimously to drop it.  That wasn't my proposal, either.  

It sounds like no one pushed it very hard, and since most people
could not go to meetings all over the world for eight years it
must have fallen by the wayside and been rejected easily.

> I would
> love to know which "several committee members" complained to you.  This
> hardly constitutes rejecting "out of hand".

I am sure.  Of course I did not get permission from these people
to publish their names.  Two of them did say that they were concerned
but were afraid to be put on your list and get that kind of treatment
themselves.  I don't know if the others felt that way but one did
say he thought it was an awful thing.

> A standard is about documenting common usage.  

Yes. Yes. I know. The mission of a standard is to promote the
common usage that people are doing or selling.  Vendors use
standards to market their products.  The vendors support the
standard the standard promotes *their* products as you have
said before.

Here comes one of your favorite myths right?

> Chuck is, and has always
> been, a creative genius, operating at the cutting edge of technology.
> These are very different goals and objectives.  Today's cutting edge may
> become tomorrow's standard, but it may not.  As a TC, it's appropriate
> to monitor and encourage innovation (such as our attempt to encourage
> adoption of FOR ... NEXT), but not to codify it before it has become
> common usage.

We know that the standard was full of completely new things to many
people such as CATCH THROW.  It is clear that political compromises
were made.  The whole process is about making political alliances to
promote certain products for certain companies and give them an
advantage in the marketplace over other products.

We know you have admitted before that codified things like that
so that they could become common usage even if they were new.

Best Wishes

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

#1537

On 4/25/11 8:45 PM, foxchip wrote:
> On Apr 25, 1:55 pm, Elizabeth D Rather<erat...@forth.com>  wrote:
>>> Intel x86 chips were more common and were a bigger concern for
>>> more people than Forth chips were as you well know.
>>
>> Of course.  It is the mission of a standard to recognize "common usage,"
>> which is inevitably influenced by dominant technology.
>
> Of course.  The defintion for "common usage" is simply what you
> saw most often or all of the time, ie. people using "your products."
>
> It is simpler to say that the mission of a standard is to support
> someone's product and try to make it dominant technology.
>
> As you have said, "FORTH Inc. supported the standard and the
> standard supported FORTH Inc.

The team included not only FORTH, Inc., but LMI, Creative Solutions, 
representatives of FIG, and producers of the most common public domain 
Forths. Later Mitch Bradley and Stephen Pelc joined us.  It also 
included users of all the widely distributed systems.

One of the first things we did was conduct a survey of as many Forth 
systems as we could get access to, evaluating how closely they were 
following Forth83, what the significant departures were, and what their 
implementers and users thought were the problems that needed to be 
addressed.

For the entire 8 years of the process, FORTH, Inc. had one vote out of 
12-15.

>> I categorically deny there was any such "concern" on my part, and none
>> discussed in any Standards meeting I attended (which was all of them).
>
> No doubt just as you denied having heard of anyone doing
> optimizing native code compilers for Forth a decade before ANS
> in defense of your myth that ANS Forth made optimizing native
> code Forth compilers possible.  You never heard of Chuck Moore
> for instance.

We made it possible for optimizing compilers to be standard.

> I once asked you if you were the only person who attended all
> the meetings.  You waffled on the answer saying it was hard
> for other people to pay for going to meetings all over the world
> for eight years.

I don't think Greg Bailey missed any meetings either.  Possibly also Don 
Colburn.  We didn't keep a roll.

>> On the contrary, we made considerable efforts to include the Forth
>> chips.
>
> I said you made some effort to include the chips where Chuck no
> longer had any interest.  Like the Harris RTX.
>
> As Andrew put it the standard we got made it rather difficult
> to include anything Chuck did after 1983 years before the
> work on ANS began.

We didn't actually get much information about the later work.  It would 
have been easier if he had attended meetings.  In any case, the issue 
would have been how much his work was influencing common usage.

...

>> It would have been a violation of our charter as a
>> standards body to discard DO ... LOOP (which was in
>> overwhelming common usage), but we did add FOR ... NEXT in CORE EXT in
>> the hope that it would be picked up by systems and users and become
>> popular.  It wasn't.  After FOR ... NEXT had been in published drafts
>> for nearly 4 years, we didn't find any significant number of systems
>> offering it or users expecting it, so in one of the last meetings the TC
>> voted unanimously to drop it.  That wasn't my proposal, either.
>
> It sounds like no one pushed it very hard, and since most people
> could not go to meetings all over the world for eight years it
> must have fallen by the wayside and been rejected easily.

It is up to those who advocate a technology to make sure others hear 
about it.  We probably did more to promote FOR ... NEXT by including it 
in our published drafts for 4 years than anyone else.

...
>> A standard is about documenting common usage.
>
> Yes. Yes. I know. The mission of a standard is to promote the
> common usage that people are doing or selling.  Vendors use
> standards to market their products.  The vendors support the
> standard the standard promotes *their* products as you have
> said before.

See above. The purpose of a standard is to make it easier for programs 
to be portable.  This actually has the effect of lessening the 
dependence of users on a particular system, which would work against the 
kind of grasping, greedy vendors you're imagining.  And all the 
commercial vendors combined never had more that 1/4 of the votes on the TC.

> Here comes one of your favorite myths right?

>> Chuck is, and has always
>> been, a creative genius, operating at the cutting edge of technology.
>> These are very different goals and objectives.  Today's cutting edge may
>> become tomorrow's standard, but it may not.  As a TC, it's appropriate
>> to monitor and encourage innovation (such as our attempt to encourage
>> adoption of FOR ... NEXT), but not to codify it before it has become
>> common usage.
>
> We know that the standard was full of completely new things to many
> people such as CATCH THROW.  It is clear that political compromises
> were made.  The whole process is about making political alliances to
> promote certain products for certain companies and give them an
> advantage in the marketplace over other products.
>
> We know you have admitted before that codified things like that
> so that they could become common usage even if they were new.

The few truly new features (let's see, CATCH/THROW and, um, what else?) 
were answers to needs that a lot of both implementers and users 
expressed in the survey I described above.  It was proposed relatively 
early on in the process, and when it was published in drafts, quite a 
number of implementers picked it up, used it, and reported good success, 
unlike what happened with FOR ... NEXT.

CATCH/THROW was proposed (and first used) by Mitch Bradley at Sun. 
Remind me what he was selling?  The fact is, your description of the 
standards process bears no resemblance to reality.  It's really more 
like *your* favorite myth.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#1540

On Apr 26, 8:49 am, Elizabeth D Rather <erat...@forth.com> wrote:
> On 4/25/11 8:45 PM, foxchip wrote:
>
> > On Apr 25, 1:55 pm, Elizabeth D Rather<erat...@forth.com>  wrote:
> >>> Intel x86 chips were more common and were a bigger concern for
> >>> more people than Forth chips were as you well know.
>
> >> Of course.  It is the mission of a standard to recognize "common usage,"
> >> which is inevitably influenced by dominant technology.
>
> > Of course.  The defintion for "common usage" is simply what you
> > saw most often or all of the time, ie. people using "your products."
>
> > It is simpler to say that the mission of a standard is to support
> > someone's product and try to make it dominant technology.
>
> > As you have said, "FORTH Inc. supported the standard and the
> > standard supported FORTH Inc.
>
> The team included not only FORTH, Inc., but LMI, Creative Solutions,
> representatives of FIG, and producers of the most common public domain
> Forths. Later Mitch Bradley and Stephen Pelc joined us.  It also
> included users of all the widely distributed systems.
>
> One of the first things we did was conduct a survey of as many Forth
> systems as we could get access to, evaluating how closely they were
> following Forth83, what the significant departures were, and what their
> implementers and users thought were the problems that needed to be
> addressed.
>
> For the entire 8 years of the process, FORTH, Inc. had one vote out of
> 12-15.
>
> >> I categorically deny there was any such "concern" on my part, and none
> >> discussed in any Standards meeting I attended (which was all of them).
>
> > No doubt just as you denied having heard of anyone doing
> > optimizing native code compilers for Forth a decade before ANS
> > in defense of your myth that ANS Forth made optimizing native
> > code Forth compilers possible.  You never heard of Chuck Moore
> > for instance.
>
> We made it possible for optimizing compilers to be standard.
>
> > I once asked you if you were the only person who attended all
> > the meetings.  You waffled on the answer saying it was hard
> > for other people to pay for going to meetings all over the world
> > for eight years.
>
> I don't think Greg Bailey missed any meetings either.  Possibly also Don
> Colburn.  We didn't keep a roll.
>
> >> On the contrary, we made considerable efforts to include the Forth
> >> chips.
>
> > I said you made some effort to include the chips where Chuck no
> > longer had any interest.  Like the Harris RTX.
>
> > As Andrew put it the standard we got made it rather difficult
> > to include anything Chuck did after 1983 years before the
> > work on ANS began.
>
> We didn't actually get much information about the later work.  It would
> have been easier if he had attended meetings.  In any case, the issue
> would have been how much his work was influencing common usage.
>
> ...
>
> >> It would have been a violation of our charter as a
> >> standards body to discard DO ... LOOP (which was in
> >> overwhelming common usage), but we did add FOR ... NEXT in CORE EXT in
> >> the hope that it would be picked up by systems and users and become
> >> popular.  It wasn't.  After FOR ... NEXT had been in published drafts
> >> for nearly 4 years, we didn't find any significant number of systems
> >> offering it or users expecting it, so in one of the last meetings the TC
> >> voted unanimously to drop it.  That wasn't my proposal, either.
>
> > It sounds like no one pushed it very hard, and since most people
> > could not go to meetings all over the world for eight years it
> > must have fallen by the wayside and been rejected easily.
>
> It is up to those who advocate a technology to make sure others hear
> about it.  We probably did more to promote FOR ... NEXT by including it
> in our published drafts for 4 years than anyone else.
>
> ...
>
> >> A standard is about documenting common usage.
>
> > Yes. Yes. I know. The mission of a standard is to promote the
> > common usage that people are doing or selling.  Vendors use
> > standards to market their products.  The vendors support the
> > standard the standard promotes *their* products as you have
> > said before.
>
> See above. The purpose of a standard is to make it easier for programs
> to be portable.  This actually has the effect of lessening the
> dependence of users on a particular system, which would work against the
> kind of grasping, greedy vendors you're imagining.  And all the
> commercial vendors combined never had more that 1/4 of the votes on the TC.
>
>
>
>
>
>
>
>
>
> > Here comes one of your favorite myths right?
> >> Chuck is, and has always
> >> been, a creative genius, operating at the cutting edge of technology.
> >> These are very different goals and objectives.  Today's cutting edge may
> >> become tomorrow's standard, but it may not.  As a TC, it's appropriate
> >> to monitor and encourage innovation (such as our attempt to encourage
> >> adoption of FOR ... NEXT), but not to codify it before it has become
> >> common usage.
>
> > We know that the standard was full of completely new things to many
> > people such as CATCH THROW.  It is clear that political compromises
> > were made.  The whole process is about making political alliances to
> > promote certain products for certain companies and give them an
> > advantage in the marketplace over other products.
>
> > We know you have admitted before that codified things like that
> > so that they could become common usage even if they were new.
>
> The few truly new features (let's see, CATCH/THROW and, um, what else?)
> were answers to needs that a lot of both implementers and users
> expressed in the survey I described above.  It was proposed relatively
> early on in the process, and when it was published in drafts, quite a
> number of implementers picked it up, used it, and reported good success,
> unlike what happened with FOR ... NEXT.
>
> CATCH/THROW was proposed (and first used) by Mitch Bradley at Sun.
> Remind me what he was selling?  The fact is, your description of the
> standards process bears no resemblance to reality.  It's really more
> like *your* favorite myth.
>
> Cheers,
> Elizabeth
>
> --
> ==================================================
> Elizabeth D. Rather   (US & Canada)  800-55-FORTHbegin_of_the_skype_highlighting            800-55-FORTH      end_of_the_skype_highlighting
> FORTH Inc.                        +1 310.999.6784begin_of_the_skype_highlighting            +1 310.999.6784      end_of_the_skype_highlighting
> 5959 West Century Blvd. Suite 700
> Los Angeles, CA 90045http://www.forth.com
>
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================

As I represent my company on a few standards bodies (one of which is
pursuing ISO certification), I can safely say that Mr Fox's
understanding of how they work, and the reason for standards in the
first place, is seriously flawed. A typical Jeff Fox misunderstanding;
"the mission of a standard is to support someone's product and try to
make it dominant technology." Nonsense on stilts. I suspect he doesn't
understand the ideas of community consensus, or common practice, or
majority decisions, or interoperability, or product saleability or a
whole host of issues related to working both competitively and
cooperatively.

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

#1547

On Apr 26, 12:45 am, foxchip <f...@ultratechnology.com> wrote:
> > FOR ... NEXT as a replacement for DO ... LOOP.  
>
> A simpler alternative suited to simpler chips.

I provided both FOR...NEXT and DO...LOOP in MFX. FOR...NEXT was
significantly faster on the MiniForth. AFAIK, it never got used
though. We were just porting over an existing Forth program which used
DO loops. Unless the code was too slow, it didn't get rewritten.

I don't know if my FOR loop was compatible with your suggested FOR
loop. I never really do any research; I just invent things as I go. I
was working at an hourly wage at Testra, so I didn't spend any time
reading articles about Forth --- I was being paid to write code.

> > A standard is about documenting common usage.  
>
> Yes. Yes. I know. The mission of a standard is to promote the
> common usage that people are doing or selling.  Vendors use
> standards to market their products.  The vendors support the
> standard the standard promotes *their* products as you have
> said before.
>
> Here comes one of your favorite myths right?
>
> > Chuck is, and has always
> > been, a creative genius, operating at the cutting edge of technology.
> > These are very different goals and objectives.  Today's cutting edge may
> > become tomorrow's standard, but it may not.  As a TC, it's appropriate
> > to monitor and encourage innovation (such as our attempt to encourage
> > adoption of FOR ... NEXT), but not to codify it before it has become
> > common usage.

In many cases, *ideas* have been in common usage for a long time, but
the implementations have been incompatible so there was never any
"common usage." When I suggested :NAME I wasn't being a "creative
genius operating at the cutting edge of technology." In UR/Forth it is
called HEADER and in SwiftForth it is called WID-HEADER (neither of
which are written in ANS-Forth, but both of which make use of carnal
knowledge of the internal workings of the compiler). Sometimes you get
to explicitly set the word-list and sometimes you use CURRENT.
Sometimes the string is a C" kind of string and sometimes an S" kind
of string, and so forth. There is no common usage, and there never
will be until it gets standardized.

Things like this really beg to be standardized, which is what I was
trying to do with :NAME. Most Forthers are going to be confused when
they see WID-HEADER being used, and they are not going realize that it
is roughly compatible with HEADER that they have seen in UR/Forth
programs. Also, SwiftForth has a HEADER word too, but it not
compatible with HEADER in UR/Forth --- it is defined like this:

: HEADER
   BL WORD COUNT GET-CURRENT WID-HEADER ;

All of this is hugely confusing. This is the kind of problem that a
standard is supposed to solve. If Forth-200x can't include my :NAME,
then to hell with Forth-200x --- I have no use for it.

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

#1545

foxchip <fox@ultratechnology.com> writes:
>On Apr 22, 10:55=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>>=A0The stack depth counter used in Chuck Moore's
>> chips for keeping track of the TOS would do, if there was a way for
>> the program to read it (AFAIK there is not).
>
>Unfortunately there is no such thing. T is a dedicated register.
>S is a dedicated register and there are circuits to connect S to
>one of the registers in the circular array.

And when I asked about how the circular array is implemented, I was
told that it was implemented with a counter that indexes into an array
of addressable cells.

- 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 2010: http://www.euroforth.org/ef10/

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

#1451

David Kuehling <dvdkhlng@gmx.de> wrote:
> 
>> Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
> 
>> What aspect of ANS actually requires stack pointers, though?  The only
>> word I can think of is DEPTH, but I don't think it's very much used in
>> standard programs.  There's certainly nothing in Standard Forth that
>> requires stacks to be in addressable memory.
> 
> What about PICK and ROLL?

: pick   ?dup if  swap >r 1- recurse r> swap  else dup  then ;
: roll   ?dup if  swap >r 1- recurse r> swap  then ;

Andrew.

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

#1482

On Apr 23, 12:43 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> David Kuehling <dvdkh...@gmx.de> wrote:
>
> >> Andrew Haley <andre...@littlepinkcloud.invalid> wrote:
>
> >> What aspect of ANS actually requires stack pointers, though?  The only
> >> word I can think of is DEPTH, but I don't think it's very much used in
> >> standard programs.  There's certainly nothing in Standard Forth that
> >> requires stacks to be in addressable memory.

I was talking about real implemenations. The standard requires DEPTH
and the only halfway practical way to do it is by monitoring the
stack pointers.  But the standard also clearly says that dealing
with stack pointers is outside of the standard and that one cannot
count on reading stack data with @ as the stacks might be in a
separate memory space or a segment accessible only by stack use.

> > What about PICK and ROLL?
>
> : pick   ?dup if  swap >r 1- recurse r> swap  else dup  then ;
> : roll   ?dup if  swap >r 1- recurse r> swap  then ;

Sure. I agreed that doing wasteful implementations of words that
shouldn't be used is not an issue in itself to most people.

Best Wishes

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

#1496

I have seen this before. It has some very serious problems.

: pick   ?dup if  swap >r 1- recurse r> swap  else dup  then ;

In the context I had showed being able to do this all might
first require slowing all stack access in Forth by a hundred
times. Calling five words recursively might make PICK a few
hundred thousands times slower again than other stack
operations.  It is a huge penalty whether one thinks PICK
is a good word or not.

It also has serious bugs.

On the processors I have worked on for a decade there are only
ten data stack cells and only nine cells on the return stack.
Also many ANS Forth compliant systems have fewer cells on their
return stack than on their data stack.

0 PICK is DUP and 1 PICK is OVER.  So on a ten deep data stack
one would only need to PICK at stack cells 2-9.

The standard only says, "An ambiguous condition exists if there are
less than u+2 items on the stack before PICK is executed."  It does
not warn of stack overflow but with u items on the stack you cannot
pick item u or it will cause a data stack overflow error or
data stack overwrite.  It is simply impossible.

With a 10 deep data stack and 9 deep return stack;

9 PICK \ maybe use a return stack cell for the return from PICK

on the first pass the ?DUP would cause data stack
cell 9 to be corrupted and case failure as
that was the one you wanted to pick.

Other systems might fail with a stack overflow exception.

That's not the only way it can fail.

N PICK \ where N is larger than cells on the return stack.

Use one return stack cell for PICK.
>R in the loop uses one stack cell and is repeated
counting down the counter.

N...,9,8,7,6,5,4,3,2,1,0

Resulting in failure before it gets to zero.
It thus has an environmental dependency
that the return stack be bigger than the data stack.

Without this explicit environmental dependency
statement it is not portable working code
as many compliant systems indeed have smaller
return stacks than data stacks. It also requires
that ?DUP SWAP etc. will not need to use the
return stack to return unless the return stack
is bigger still.

An early ANS draft required a minimum of 32 data
stack cells and 28 return stack cells.  That
requirement went away but showed the thinking
that a return stack smaller than the data stack
was ok.  Many ANS compliant implementations still
have fewer cells in their return stack than in
their data stack.

Besides just declaring various environmental
dependencies and accepting that it won't work
on many ANS Forth systems the only other halfway
practical option is to dump N words from the
data stack to memory, then index into this
dump, then load it back onto the data stack
with a copy of the Nth item on the top and
it would also be a requirement that the code
that does this must not add anything more than
one cell to the data stack in the code that does
that when the stack is nearly full when the
PICK is invoked.

And dumping the whole stack to memory
without using the stack could be very
very ugly or simply impossible without
a stack pointer somewhere and/or a stack
in memory.

I always said, "It is impolite to PICK
your nose or your stack in public."

It is primitive and repulsive code.
It is also considered impolite in many
cultures to expectorate, micturate, fart,
or evacuate your waste in public.

Best Wishes

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

#1503

foxchip <fox@ultratechnology.com> wrote:
> I have seen this before. It has some very serious problems.
> 
> : pick   ?dup if  swap >r 1- recurse r> swap  else dup  then ;
> 
> In the context I had showed being able to do this all might
> first require slowing all stack access in Forth by a hundred
> times. Calling five words recursively might make PICK a few
> hundred thousands times slower again than other stack
> operations.  It is a huge penalty whether one thinks PICK
> is a good word or not.

So if it has a huge penalty, don't use it.  This is a red herring.
The only question is whether PICK requires a stack pointer, which it
doesn't.

> It also has serious bugs.
> 
> On the processors I have worked on for a decade there are only
> ten data stack cells and only nine cells on the return stack.

On such severely resource-constrained systems you're going to have
trouble with PICK, of course.

> Without this explicit environmental dependency statement it is not
> portable working code as many compliant systems indeed have smaller
> return stacks than data stacks. It also requires that ?DUP SWAP
> etc. will not need to use the return stack to return unless the
> return stack is bigger still.

Why does the working of PICK require DUP etc. not to use the return
stack?

> Besides just declaring various environmental dependencies and
> accepting that it won't work on many ANS Forth systems the only
> other halfway practical option is to dump N words from the data
> stack to memory, then index into this dump, then load it back onto
> the data stack with a copy of the Nth item on the top and it would
> also be a requirement that the code that does this must not add
> anything more than one cell to the data stack in the code that does
> that when the stack is nearly full when the PICK is invoked.

So don't invoke PICK when the stack is nearly full.  Better, don't
invoke PICK at all.

> And dumping the whole stack to memory without using the stack could
> be very very ugly or simply impossible without a stack pointer
> somewhere and/or a stack in memory.

How would a stack pointer somewhere make any difference to being able
to dump a stack into memory?  If someone says 9 PICK, you have to dump
10 items, popping them one at a time.  As long as you can pop an item
and put it into memory, you can do it.

Andrew.

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

#1536

On Apr 25, 12:35 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> So if it has a huge penalty, don't use it. This is a red herring.

One avoids huge penalties like one avoids a stinking dead herring.

> The only question is whether PICK requires a stack pointer, which it
> doesn't.

No. The big issue is actually using the C definition of a stack
which is an array in memory where one can embed stack-frames and
use pointers rather than using the actual definition of a LIFO
stack that says it is something only accessed at one end.  The
idea behind Forth is that a stack is a stack not a C stack frame.
The big issue is that Forth style is different than C style.

It is a much bigger issue than the huge penalty of embracing
a stinking dead fish.

> > It also has serious bugs.
> > (details of one example edited out)

> On such severely resource-constrained systems you're going to
> trouble with PICK, of course.

That problem exists on all systems that don't have infinite stacks.
Please name a system with an infinite resource-unconstrained stack.

I always laugh when talk about non-existent systems with infinite
resources.  All resources are always constrained and the amount is
always relative to other constrained systems.

Maybe some systems look like they have infinite resources from
a little pink cloud but down on earth they are finite.

> Why does the working of PICK require DUP etc. not to use the return
> stack?

For the reason I had given above that. The non-standard definition
of PICK you gave requires that the return stack be bigger than
the data stack and you can't count on that.  Your definition also
uses words like DUP which may require additional return stack cells
thus requiring that the return stack be even bigger yet and lead
to failure earlier on systems where the return stack is not
bigger than the data stack.

Maybe you were thinking of infinite stacks again?

> So don't invoke PICK when the stack is nearly full.  Better, don't
> invoke PICK at all.

Right.  Generally speaking it is good to learn that C stacks and
Forth stacks don't have to work the same way.  Forth is suppose to
be an alternative to C, not a subset of it.

Do you also need DEPTH to know when the stack is nearly full
to know when PICK will fail?

Better than simply not invoking it, don't include it, don't code
it and don't do Forth as if it were C.

> How would a stack pointer somewhere make any difference to being able
> to dump a stack into memory?

Is there a "portable" way to know how many items you need to
dump from the stack into memory?

If you don't have a stack pointer because it is only needed for
cripples who can't live without DEPTH or who can't live without PICK
then the only way to use a pointer needed by PICK is to put a copy
of the stack in main memory where a normal pointer can pick at it.

> If someone says 9 PICK, you have to dump 10 items, popping them
> one at a time.  As long as you can pop an item and put it into
> memory, you can do it.

One can do ugly awful things with huge penalties if that is
their idea of good coding.  What I said was that it could get
very ugly.

On P21, i21, F21 and other chips I used in one exmaple
the stacks and memory were not the same bit-width.  And because
one had only auto-increment but not auto-decrement addressing
modes and because one had limited pointers one had to do quite
a lot to dump a stack to memory and put it back in registers.
It was not as awful and ugly as a dead fish or PICK but still
ugly.

Best Wishes

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

Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9  Next page →

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

csiph-web