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 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9  Next page →

#1567

Charles G Montgomery <cgm@physics.utoledo.edu> writes:
>>> I don't think I understand this.  You mean offset alternating rows of
>>> nodes, so that each node would have two horizontal neighors (left and
>>> right) but 4 vertical (2 each at top and bottom)?  Interesting.
> The hexagonal lattice, in which each unit cell is a hexagon, is threefold-
> coordinated:  each point has three equidistant nearest neighbors.

I think what I described is topologically equivalent but maybe I'm
overlooking something.

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

#1572

On Apr 27, 2:36 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> Charles G Montgomery <c...@physics.utoledo.edu> writes:
>
> >>> I don't think I understand this.  You mean offset alternating rows of
> >>> nodes, so that each node would have two horizontal neighors (left and
> >>> right) but 4 vertical (2 each at top and bottom)?  Interesting.
> > The hexagonal lattice, in which each unit cell is a hexagon, is threefold-
> > coordinated:  each point has three equidistant nearest neighbors.
>
> I think what I described is topologically equivalent but maybe I'm
> overlooking something.

The rows do not have to be offset if you have diagonal corner
connections.

123456...
ABCDEF...
123456...
ABCDEF...

"B" is connected to A and C and 2 above and below
"B" is also connected to 1 above and below

"2" is connected to 1 and 2 and B above and below
"2" is also connected to C above and below

A six cell ring with a common cross-switch is, eg:
2nd row B to 3rd row 1 to 4th row B to
4th row C to 3rd row 3 to 2nd row C to 2nd row B,
3rd row "2" is the internal cross-switch

A through diagonal connection is a pair of connections that add up to
a knights move, eg,

1st 3 to 2nd C to 3rd 2 to 4th B, etc.

This is of course a degenerate case of the all straight and diagonal
connected, the hexagonal cells in a triangular lattice is purely a way
to envision it.

With connector addressing, it is a 3 bit connector address and two
special cases (say 000 and 111), with selected connectors it is a 6bit
selector. The two can of course be combined, eg, if there are two 6bit
stores for selectors and they are addressed as connectors 000 and 111,
with 001 to 110 used to address individual connectors.

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

#1615

In article <6178e4a6-8631-47f7-a90e-02de59cf3505@v10g2000yqn.googlegroups.com>,
BruceMcF  <agila61@netscape.net> wrote:
>On Apr 27, 2:36=A0am, Paul Rubin <no.em...@nospam.invalid> wrote:
>> Charles G Montgomery <c...@physics.utoledo.edu> writes:
>>
>> >>> I don't think I understand this. =A0You mean offset alternating rows =
>of
>> >>> nodes, so that each node would have two horizontal neighors (left and
>> >>> right) but 4 vertical (2 each at top and bottom)? =A0Interesting.
>> > The hexagonal lattice, in which each unit cell is a hexagon, is threefo=
>ld-
>> > coordinated: =A0each point has three equidistant nearest neighbors.
>>
>> I think what I described is topologically equivalent but maybe I'm
>> overlooking something.
>
>The rows do not have to be offset if you have diagonal corner
>connections.
>
>123456...
>ABCDEF...
>123456...
>ABCDEF...
>
>"B" is connected to A and C and 2 above and below
>"B" is also connected to 1 above and below
>
>"2" is connected to 1 and 2 and B above and below
>"2" is also connected to C above and below
>
>A six cell ring with a common cross-switch is, eg:
>2nd row B to 3rd row 1 to 4th row B to
>4th row C to 3rd row 3 to 2nd row C to 2nd row B,
>3rd row "2" is the internal cross-switch
>
>A through diagonal connection is a pair of connections that add up to
>a knights move, eg,
>
>1st 3 to 2nd C to 3rd 2 to 4th B, etc.
>
>This is of course a degenerate case of the all straight and diagonal
>connected, the hexagonal cells in a triangular lattice is purely a way
>to envision it.
>
>With connector addressing, it is a 3 bit connector address and two
>special cases (say 000 and 111), with selected connectors it is a 6bit
>selector. The two can of course be combined, eg, if there are two 6bit
>stores for selectors and they are addressed as connectors 000 and 111,
>with 001 to 110 used to address individual connectors.

They have no true advantage in the sense that circuits are possible
that were not possible before.
Note that in a 3D lattice you can always go from point A to point B,
irrespective of the connections that already have been realised in
the mesh.

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#1667

On Apr 28, 7:53 am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> They have no true advantage in the sense that circuits are possible
> that were not possible before.

No, their advantages are other than making circuits possible that were
not possible before. That follows directly from the fact that they are
a degenerate form of a more complete 2D lattice.

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

#1575

On 27/04/11 07:36, Paul Rubin wrote:
> Charles G Montgomery<cgm@physics.utoledo.edu>  writes:
>>>> I don't think I understand this.  You mean offset alternating rows of
>>>> nodes, so that each node would have two horizontal neighors (left and
>>>> right) but 4 vertical (2 each at top and bottom)?  Interesting.
>> The hexagonal lattice, in which each unit cell is a hexagon, is threefold-
>> coordinated:  each point has three equidistant nearest neighbors.
>
> I think what I described is topologically equivalent but maybe I'm
> overlooking something.

Perhaps a brick wall pattern would be easier to visualise, with 
interfaces across every straight boundary - total 6.

This might also be a more practical layout for the roughly 2x1 
shape of the processor cores.

Jan Coombs.
-- 

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

#1576

On Apr 27, 12:41 pm, Jan Coombs <jan_2011...@murray-microft.co.uk>
wrote:
> Perhaps a brick wall pattern would be easier to visualise, with
> interfaces across every straight boundary - total 6.

> This might also be a more practical layout for the roughly 2x1
> shape of the processor cores.

Yes, this is equivalent to hexagonal cells in a triangular lattice.

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

#1548

In article <8fd294c2-3c28-4213-bf95-094b1d2f9706@n10g2000yqf.googlegroups.com>,
BruceMcF  <agila61@netscape.net> wrote:
>On Apr 25, 1:43=A0pm, Paul Rubin <no.em...@nospam.invalid> wrote:
>
>> Wait, the 4 ports per node use just 0.1% of the chip, but making
>> 8 ports per node doubles the size? =A0They must have changed a lot
>> of other stuff too.
>
>Does a cube need non-local connection in the layout?

A cube does not. So an 8 node 6 connection could be easily
made one chip, then have three dimensional interconnections.

A 3D lattice instead of 2D would require non-local connections,
but it would solve some non-trivial routing problems.
If it is non-local in hardware, it would have been non-local
in software.

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#1533

On Apr 25, 9:43 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> Wait, the 4 ports per node use just 0.1% of the chip, but making
> 8 ports per node doubles the size?  

Each port requires a couple dozen transistors out of 20,000 for
the alu, stacks, RAM and ROM on a core.  When the team who did
the eight port version went from four to eight ports they
needed an additional 20,000 transistors for those ports.

> They must have changed a lot of other stuff too.

They did. But those changes increased the transistor count by
a factor of another four times on top of that.  When Chuck heard
about it he walked out of the room.  The head of marketing asked
have you made a multi-core chip the size of a Pentium?

They said it was close.

> But the alternative is communication bottlenecks!  

It sounds like you are still trying to understand the most
basic things about the chip.

> I'm still trying to see how the GA144 avoids that.

> > The network router on F21 added less than a penny of silicon and
> > about two cents worth of pins but was limited to about 40mbps.
>
> I'm not talking about adding pins, just more on-chip communications
> ports between nodes.  

Ok. That was F21.  On the multi-core chips the issue was that
Chuck's four port designed needed a couple of dozen transisters
per port to get the speed it got while the eight port design
needed about 2500 transistors per port x8 per node.

> Maybe I'm not using the right terms.  Traditional
> supercomputers use a hypercube interconnect but I can see why a 2-D
> array is easier to build on a chip.  A hypercube GA (say with 64
> nodes) would of course be awesome.

Indeed.  One could interconnect multiple clusters to get more than
two dimensional arrays of clusters.  One could use parallel
connections
as well with a lot more pins.  Or one could use more high speed serdes
in the designs for that purpose.

Best Wishes

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

#1564

foxchip <fox@ultratechnology.com> writes:
> Each port requires a couple dozen transistors out of 20,000 for
> the alu, stacks, RAM and ROM on a core.  When the team who did
> the eight port version went from four to eight ports they
> needed an additional 20,000 transistors for those ports.

OK, well it sounds like those guys had different ideas.  But also that
the GA designers could add the extra ports at much lower cost in chip
area.  Or if it really only takes a few dozen transistors, maybe there
could even be "chess knight" connections (requiring routing around or
through neighboring nodes, but still keeping distances fairly short), so
each interior node could reach 16 other nodes.

>> But the alternative is communication bottlenecks!  
> It sounds like you are still trying to understand the most
> basic things about the chip.

That's possible.  But, for example, the obvious way to implement the AES
block cipher involves around 768 bytes of ram (basically three 256-byte
arrays).  So fine, one node's ram turns into 128 bytes with some
bit-twiddling, so use 6 nodes for ram plus 1 or 2 for processing.  But
then routing the data around these nodes starts presenting problems of
its own.  AES might be doable in 5 nodes (replacing some table lookups
with parallel computation) without too much speed hit, but it would take
some simulation to find out.  That's just one example though, that I
happened to be thinking about.

I hope GA will publish some more materials soon, explaining the
concurrency mechanisms.  Actually it occurs to me that I can already
look at the Seaforth docs for that, so maybe I'll do that tonight.

>> A hypercube GA (say with 64 nodes) would of course be awesome.
> Indeed.  One could interconnect multiple clusters to get more than two
> dimensional arrays of clusters.  One could use parallel connections as
> well with a lot more pins.  Or one could use more high speed serdes in
> the designs for that purpose.

I mean hypercube connectivity on the chip, the same type of ultra-fast
ports that are on the GA nodes now, but reaching further away.  There
might be a slight speed penalty from driving signals over a longer
distance, and the wiring might burn some chip area, but it may be worth
sacrificing a few nodes for it.  So instead of GA144 it might be GA128.

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

#1454

In article <7x4o5q4uuh.fsf@ruckus.brouhaha.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>foxchip <fox@ultratechnology.com> writes:
>> Chuck's first VLSI Forth chip, MuP21, had only six cells in
>> the data stack and four in the return stack...
>
>Jeff, I'm wondering something kind of unrelated.  The GA processors are
>connected vertically and horizontally, so each interior node has 4
>connected neighbors.  Did you guys give any thought to adding diagonal
>connections, so each node would have 8 neighbors?  That would allow
>(e.g.) using more neighbors as ram, while still being able to route
>other data around them.

To elaborate on that. In designing the 8 chain version of the
parpi (parallel prime counting program) I came to realize that
a two dimensional layout is restrictive for some applications.
You cannot communicate with a node that is inside a ring of
processors without crossing the ring.

That would be problematic for maybe less than 1% of the
applications, but that could be the high profile ones.
A version of the GA chips with a cube configuration (n,w,s,e
up and down) would make a difference for those.
So a 6x6x6 or 4x4x4 configuration instead of 8x18.
For processor connections hypercube configurations are a favorite.
There is a quantum step between 2 and 3 dimensions.

Groetjes Albert


--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#1499

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
> A version of the GA chips with a cube configuration (n,w,s,e
> up and down) would make a difference for those.
> So a 6x6x6 or 4x4x4 configuration instead of 8x18.
> For processor connections hypercube configurations are a favorite.
> There is a quantum step between 2 and 3 dimensions.

Yes, the obvious problem is you'd probably need more layers in the chip
for that.  I'd have expected adding diagonal port to be easier.

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

#1666

On Apr 25, 3:48 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> Yes, the obvious problem is you'd probably need more layers in the chip
> for that.  I'd have expected adding diagonal port to be easier.

Especially adding a "diagonal" port that is a second port along the
long side of the processor cell.

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

#1418

On Apr 22, 12:11 am, foxchip <f...@ultratechnology.com> wrote:
> The programmers who preferred C insisted that a lot
> more stack registers would be needed on c18.  The
> Forth programmers showed how many were actually
> needed. Since the stacks use about as much
> real-estate as on-chip RAM and ROM combined Chuck
> didn't want to make more than were actually needed.

The programmers who "preferred C" (if they actually exist and are not
just used as an argumentative device) are likely programmers who only
understand C in the context of running on big hardware with big
operating systems.  And in that context, sure, C can use a lot of
stack if functions have lots of locals.  Toss in some recursion, and
you've got hundreds to thousands of bytes of stack being necessary.

But it's not true for C in an embedded context.  Many C compilers that
I've used over the years don't use a single byte of stack for either
locals or arguments.  Those C compilers only use stack for return
addresses.  Arguments are passed in registers whenever possible; if
there are more arguments than registers, they spill into statically
allocated RAM.  Locals likewise are placed not on a stack, but in
statically allocated RAM.  The linker then builds a call graph of the
program, determines which functions can never be "live" at the same
time, and allocates the smallest number of bytes needed.

On really restricted architectures, this strategy guarantees that the
C programmer never uses more stack than the maximum call depth.  It
obviously prevents the ability to create recursive calls to a function
(except for tail recursion which can always be replaced with
iteration).  But that's not a big loss for most embedded work, and if
recursion is really necessary, the programmer can explicitly manage
their own stack.

So if you asked *this* programmer with *embedded* C experience what
the maximum stack depth for Chuck's chips needed to be, I would have
said that they only needed to be as deep as the maximum call depth.  A
depth of 16 would be oodles more than what anyone ever needed.  A
depth of 8 would probably easily handle 90% of the code most people
would write.  If one needed interrupts, you would want a bit more, but
even there, you only need to store a return address and any context
you can't store in RAM.

The biggest problem that I see in discussions like this comes from two
groups of people.  The first are generic C programmers who aren't
aware that embedded C programming is in a lot of ways wildly different
from C programming on larger systems.  Techniques like "compiled
stack" that statically allocate RAM instead of using precious stack
are common, as is having to build everything yourself since you have
no operating system to rely on.  This completely blows the minds of
many generic C programmers.

The second group of people who are equally clueless are the Forth
programmers who like mixing apples and oranges and treating C as they
know it on bigger hardware.  It leads to people like yourself, Jeff,
who constantly rant about C but do so by citing things that are only
true in the non-embedded C world (or embedded but on big
architectures).  Most of the time when you issue a rant or essay on C,
you'll cite things like huge stack frames, operating systems, file
systems, and gobs of code with massive layers of code reaching down
from application to libraries to operating system to BIOS.  Great
stuff for a rant-- and often true in the context of non-embedded
systems.  But it doesn't reflect the reality of much *embedded* C
work.  There, it's a fictional dragon that you fearlessly slay.  I've
never quite figured out if the reason you do this is ignorance or
dishonesty.  I generally assume the best in people so I'll say it's
ignorance since that same ignorance is shown by lots of other people--
C programmers included.

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

#1429

On Apr 22, 8:44 am, John Passaniti <john.passan...@gmail.com> wrote:
> The programmers who "preferred C" (if they actually exist and are not
> just used as an argumentative device)

I was not lying as you imply.  They did exist.  Many had worked
for Intel designing Pentium and were hired away from Intel at
very high costs and needed a much larger budget for their trying
to prove that Chuck was wrong than the Forth Teams budget.

In the end they were only able to prove Chuck correct as their
designs using the million dollar license tools tended to be
several times bigger, several times slower, need several times
more power, take several times longer to design, and need much
larger budgets.

> are likely programmers who only understand C in the context
> of running on big hardware with big operating systems.  

This was true for most of them.  They needed big computers
running big software with million dollar per year license
costs to do anything. There were a few who had done some
embedded processor work.

But they didn't understand the Forth design tools with
source and were often amazed that things that took them
days on a room full of high end PCs could be done in
OKAD in a few seconds.  But of course OKAD was designed
to do what was needed for the job at hand.

> And in that context, sure, C can use a lot of
> stack if functions have lots of locals.  Toss in some recursion, and
> you've got hundreds to thousands of bytes of stack being necessary.

Sure. And if you need multiple gigabyte sized programs to do
anything C probably does not appear to be wasteful at all.

> But it's not true for C in an embedded context.  

Even the programmers on what I called the C team who had
experience designing embedded processors still needed multiple
gigabyte sized programs do design and compile hardware and code
even when targeting small chips.

> Many C compilers that
> I've used over the years don't use a single byte of stack for either
> locals or arguments.  Those C compilers only use stack for return
> addresses.  Arguments are passed in registers whenever possible; if
> there are more arguments than registers, they spill into statically
> allocated RAM.  Locals likewise are placed not on a stack, but in
> statically allocated RAM.  The linker then builds a call graph of the
> program, determines which functions can never be "live" at the same
> time, and allocates the smallest number of bytes needed.

Good for you.  I wasn't writing about your work.  I was talking
about people given the same requirement list for chip designs
that Chuck was using and the tools and work that these high-paid
programmers used.

> On really restricted architectures, this strategy guarantees that the
> C programmer never uses more stack than the maximum call depth.

What OS and what C compiler did your run on $.10 processors?

I suspect you are still talking about PC software generating
target C code for small processors and not talking about the
tools needed for making high performance VLSI processors that
I was talking about.

> It
> obviously prevents the ability to create recursive calls to a function
> (except for tail recursion which can always be replaced with
> iteration).  But that's not a big loss for most embedded work, and if
> recursion is really necessary, the programmer can explicitly manage
> their own stack.
>
> So if you asked *this* programmer with *embedded* C experience what
> the maximum stack depth for Chuck's chips needed to be, I would have
> said that they only needed to be as deep as the maximum call depth.  

I was talking about a remote team larger than the Forth team in
silicon valley not you and your using PC running C to target code
for embedded chip applications.  You could have applied for one
of those high paying jobs doing the chip design if you would have
wanted and to and had felt you were qualified.  But some of these
guys were the top design experts from Intel who had learned from
Chucks having trained Intel designers.

> A
> depth of 16 would be oodles more than what anyone ever needed.  A
> depth of 8 would probably easily handle 90% of the code most people
> would write.  If one needed interrupts, you would want a bit more, but
> even there, you only need to store a return address and any context
> you can't store in RAM.

Yes, but these people could not do anything without Linux, Windows,
and million dollar per year license fee CAD software.  They could
not do that sort of thing with only 8 to 16 stack cells and no
general purpose registers below them. They needed hardware costing
tens of thousands of dollars and software with big license fees
yet without source code.

> The biggest problem that I see in discussions like this comes from two
> groups of people.  The first are generic C programmers who aren't
> aware that embedded C programming is in a lot of ways wildly different
> from C programming on larger systems.  Techniques like "compiled
> stack" that statically allocate RAM instead of using precious stack
> are common, as is having to build everything yourself since you have
> no operating system to rely on.  This completely blows the minds of
> many generic C programmers.

Sure.  My problem with your point of view is that if I mention how
much computer and how much software C programmers needed to create
their designs or their code you ignore the topic, get very defensive,
and switch to insult mode and to discussing just your own targeted
C code experience instead.

> The second group of people who are equally clueless are the Forth
> programmers who like mixing apples and oranges and treating C as they
> know it on bigger hardware.  

You mean like explaining VLSI CAD design work and programming which
seems to upset you.

> It leads to people like yourself, Jeff,
> who constantly rant about C but do so by citing things that are only
> true in the non-embedded C world (or embedded but on big
> architectures).  

I know when I discuss that people actually do run Linux, Windows,
and million dollar VLSI design tools to create embedded designs
that you refuse to let the discussions past without getting upset
and switching to personal insult mode.  "people like yourself,
with extreme inferiority complexes won't discuss many subjects
and retreat from the real world where they have crippling fear
issues to insulting people on usenet.

> Most of the time when you issue a rant or essay on C,
> you'll cite things like huge stack frames,

like the bugzilla bugs listed that were listed for GCC
in creating stack frames larger than 4 gigabytes?

> operating systems,

like the ones the C programmers rely on to host their
C compilers and VLSI design tools.

> file systems, and gobs of code with massive layers of
> code reaching down from application to libraries to
> operating system to BIOS.

I do talk about that when contrasting it to Forth VLSI
design tools running under Forth in a very different
way.  I know you hate anyone contrasting the C tools
that compete with the Forth tools.

> Great
> stuff for a rant-- and often true in the context of non-embedded
> systems.  But it doesn't reflect the reality of much *embedded* C
> work.  

If by "work" you don't mean the actual work and only the
end product of code for your own embedded C projects.  The
say I see it you simply won't tolerate a discussion of the
full scope of work which mostly involves OS use and tool use
and host computer use to do the work being discussed.

> There, it's a fictional dragon that you fearlessly slay.  

You imagine imaginary dragons, I don't.  I also don't
run screaming away from Forth or insects.

> I've never quite figured out if the reason you do this

It is to help people understand things like how the VLSI
designs we made were actually made, how the tools work
and how the designs themselves work.

My take is that you use usenet to pretend you are not
crippled by agoraphobia like you husband has said and
write cowardly personal insults from behind your keyboard
hiding away in your house.

> is ignorance or dishonesty.  

Yes I know. According to you Forth is actually a lie.
I am a liar, mindless parrot, and dangerous cultist.
According to you Chuck is a liar and snake-oil-salesman.
When you lose a logical argument that is where you
always go.

> I generally assume the best in people so I'll say it's
> ignorance since that same ignorance is shown by lots of
> other people--C programmers included.

I can't make any general statements about the long list
of your particular mental problems but you do have my
sympathy and hopes that someday you will get over the
agoraphobis and hate.  You can't always count on your
husband and his "amazing squashing powers" to save you
when you go screaming away from things that frighten
you.  I have seen that you have learned a little about
Forth in the last twenty years and may someday actually
be able to show people your Forth code.

But then again that might cut into your posting all
the "people like you ..." type responses that you give
to people who discuss Forth on usenet.

Best Wishes

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

#1441

On Apr 22, 2:36 pm, foxchip <f...@ultratechnology.com> wrote:
> > But it's not true for C in an embedded context.  
>
> Even the programmers on what I called the C team who had
> experience designing embedded processors still needed
> multiple gigabyte sized programs do design and compile
> hardware and code even when targeting small chips.

So?  It's both trivial and uninteresting to point out that some
companies do things in a more complicated or less efficient way than
is necessary.  Let's all just accept as a given that there are-- and
will always be-- companies that haven't figured out how to do things
better and companies that reject that there may even be a better way.
And gosh, that even includes big and profitable companies like Intel.
Wow, Jeff, that's an amazing revelation.  What's next?  The sky is
(mostly) blue?  Grass is (mostly) green?  Your stunning insight never
ceases to amaze.

It doesn't bother me in the least that a company I don't work for does
things badly.  By my precise calculation, companies like Intel waste
approximately 1.17 gazillion dollars every yayasecond in their
approach to hardware and software.  Sucks to be them!  What I care
about is the company I work for, the competition for the larger
industry I work in, and the still larger spectrum of embedded systems
we collectively target.  And in my experience-- and the experience of
loads of others-- the world you describe largely reflects the limited
reality of someone living in Silicon Valley.  And here's a shocker--
there's a larger world out there.

Now, you have vested interest in ignoring the larger world and solely
focusing on a narrow slice of Silicon Valley reality.  Because as long
as you can do that, you can make grandiose claims that are actually
sorta-kinda true.  The problem is that often what you write needs to
be followed by an asterisk leading to a footnote.  "* Statements
expressed here are substantiated by specific examples in specific
industries and specific companies and specific individuals and do not
necessarily reflect on the larger reality experienced by engineers
living outside the travel range of Jeff Fox."  If you only put forth
that kind of statement, I think I'd agree with most everything you
write.

> Good for you.  I wasn't writing about your work.  I was
> talking about people given the same requirement list for
> chip designs that Chuck was using and the tools and work
> that these high-paid programmers used.

But that's the problem, isn't it?  If you go to McDonalds and ask how
many people are vegetarian, don't be surprised if the number is zero.
If you go to engineers who work(ed) for a companies like Intel--
engineers who are likely heavily vested in a set of tools,
technologies, and design strategies-- don't be surprised when they
tell you that they'll need expensive multi-gigabyte design tools to
get things done and processors dripping with resources.

The rest of the engineering community (myself included) who doesn't
work on huge campuses with insane budgets know how to do more with
less.  Because if we couldn't, we wouldn't be in business.  There are
vast swaths of the world that are not Intel, not Freescale, not
Microsoft, not Apple.  So instead of getting design advice from people
who can afford to throw endless cash at problems, maybe you should
instead talk to people who are more practical and pragmatic.  But of
course if you did that, most of your arguments start to diminish and
the stereotypes you carefully cultivate would disappear.

> > On really restricted architectures, this strategy guarantees
> > that the C programmer never uses more stack than the maximum
> > call depth.
>
> What OS and what C compiler did your run on $.10 processors?

I didn't claim the processors were ten cents.  The processors I work
on range from tiny 8-bit microcontrollers ranging from about $0.70 to
32-bit microcontrollers that top off around $35.  And while a handful
of the higher-end systems I've worked on used either Linux, QNX, or
vxWorks, the vast majority of what I've worked on for the past 24ish
years didn't have any operating system at all.  As for C compilers, on
the higher-end systems, it's usually been GCC.  But for the vast
majority of projects, it's been compilers from companies like
Metrowerks, IAR, Keil, ImageCraft, and a few others.  The cost of
these C compilers has ranged from free to around $150 to about $1000.
Free or really cheap is the norm, because microcontroller
manufacturers want you to build their chips into products, so they
freely cut costs and give away freebies all the time.

> I suspect you are still talking about PC software generating
> target C code for small processors and not talking about the
> tools needed for making high performance VLSI processors that
> I was talking about.

What you're talking about at any point in time tends to seamlessly
slide around and is very squishy.  You have a habit of moving goal
posts around.  You were talking about asking some engineers who
"preferred C" about the maximum stack depth, and you used their
singular (and unsurprising response) to draw conclusions about C
programmers in general.  As I pointed out, if you had asked engineers
outside your comfort and experience zone, you would have gotten a very
different answer.  But you like going to McDonalds to count the
vegetarians.

> > So if you asked *this* programmer with *embedded* C experience what
> > the maximum stack depth for Chuck's chips needed to be, I would have
> > said that they only needed to be as deep as the maximum call depth.  
>
> I was talking about a remote team larger than the Forth team in
> silicon valley not you and your using PC running C to target code
> for embedded chip applications.  You could have applied for one
> of those high paying jobs doing the chip design if you would have
> wanted and to and had felt you were qualified.  But some of these
> guys were the top design experts from Intel who had learned from
> Chucks having trained Intel designers.

Top design experts at Intel... who were highly paid, so I guess that
means instead of hamburgers at McDonalds, they were ordering lamb at
Zitune?  I judge engineers by their skill, experience, and insight.
From what you've described, the engineers you talked to are locked in
a certain mindset and aren't aware that C can work perfectly fine on
systems with very small stacks.  So I guess I'm not terribly impressed
as much by their salaries as you are.  Tell me, did they have nice
shoes?

> Yes, but these people could not do anything without Linux, Windows,
> and million dollar per year license fee CAD software.  They could
> not do that sort of thing with only 8 to 16 stack cells and no
> general purpose registers below them. They needed hardware costing
> tens of thousands of dollars and software with big license fees
> yet without source code.

And again, you're talking to the wrong people.  Or you're talking to
the right people, if you merely want to perpetuate your favorite
stereotypes.  But I guess that's the thing about McDonalds-- the food
is never very good, but at least it's a known quantity.  No
surprises.  You ask for a hamburger, and that's what you get.  Asking
an engineer who "prefers

> Sure.  My problem with your point of view is that if I mention how
> much computer and how much software C programmers needed to create
> their designs or their code you ignore the topic, get very defensive,
> and switch to insult mode and to discussing just your own targeted
> C code experience instead.

Yes, especially when my apparently much broader C experience
contradicts your very narrow C experience, you bet I'll correct you.
I correct you just as much as people who make idiotic statements about
Forth programmers, usually from the same well of ignorance and
assumption that you constantly dive into.  But I must say, you've
added a new and exciting logical fallacy to your argument-- it's a
form of /argumentum ad numerum/.  Now, because highly paid engineers
in a section of the country with a ridiculous cost of living say
something, well gosh, I guess that settles it.

> You mean like explaining VLSI CAD design work and programming which
> seems to upset you.

Doesn't upset me at all.  I've been following what you have written
about Charles Moore's work over the years and have both a lot of
respect and fascination with it.  I don't think it's necessarily the
best solution to every problem, but few things in the world are best
at everything.

But we aren't talking about VLSI CAD design work.  We're
*specifically* talking about stack depths.  And I'm specifically
responding to your statement that engineers who "preferred C" can't
get by without huge stacks.  And as is of the case when I respond to
specific points you make, you then retreat to a different argument.

So let's make this very clear.  On the specific question about how
much stack engineers who "preferred C" want, you picked a population
that would naturally give you large numbers for answers.  I'm not
talking about the larger topic of VLSI CAD systems.  I'm not talking
about whatever else might be running around in your head.  On the
specific point of how much stack engineers who "preferred C" want, you
picked the wrong group of people to ask for the kind of design you
want.  And you drew incorrect and invalid conclusions from that.

> > Most of the time when you issue a rant or essay on C,
> > you'll cite things like huge stack frames,
>
> like the bugzilla bugs listed that were listed for GCC
> in creating stack frames larger than 4 gigabytes?

Sure, and that's a great example.  You take ridiculous examples of C
programmers doing extremely weird, stupid, or at the very least
marginal things, and present them as if they were common.  It would be
like taking some of the worst read-only Forth code and saying, "this
is the kind of stuff Forth programmers write."  You would certainly
object to that, but strangely, when the subject is C, you're more than
willing to accept every stupid little corner case as if it was an
impediment to 99.9% of the C programmers in the world.

> I do talk about that when contrasting it to Forth VLSI
> design tools running under Forth in a very different
> way.  I know you hate anyone contrasting the C tools
> that compete with the Forth tools.

No, I hate people who unfairly contrast C tools and don't make
distinctions between compile-time and run-time.  It's weird you do
that, since you're so fond of making distinctions about compile-time
and run-time in Forth.  You strangely think that because I develop
under Windows and Linux for targets that don't have any operating
system, that somehow the target inherits all the layers of software of
the compile-time system.  Well gosh, if that's true, then I guess
GreenArrays has the exact same problem.  Or are they not offering and
supporting a Windows-hosted cross-compiler?

> If by "work" you don't mean the actual work and only the
> end product of code for your own embedded C projects.  The
> say I see it you simply won't tolerate a discussion of the
> full scope of work which mostly involves OS use and tool use
> and host computer use to do the work being discussed.

I gladly tolerate it.  And I also tolerate the same discussion about
the GreenArrays tools being hosted on Windows.  I can't wait to hear
the clever distinctions you offer.

> > There, it's a fictional dragon that you fearlessly slay.  
>
> You imagine imaginary dragons, I don't.  I also don't
> run screaming away from Forth or insects.

Strange, but in every company I've worked for, I've injected Forth
into the development process, from tools to code that remains resident
in the final system.  So I'm not sure how that indicates a fear of
Forth.  As for insects, we all have our own personal phobias that
we're working through.  The difference between you and me is that once
I found out what you're afraid of, I wouldn't toss in back to you in
such as childish manner as you did.

> My take is that you use usenet to pretend you are not
> crippled by agoraphobia like you husband has said and
> write cowardly personal insults from behind your keyboard
> hiding away in your house.

Oooh!  This is fun!  Jeff is so interested in little old me that he's
taken now to not only checking into me, but my partner!  Wow, that's
really... creepy!  Is this kind of Internet stalker activity common
for you?  It's kind of disturbing, but you've shown yourself to be a
fountain of weird and erratic behavior over the years, documented for
everyone in Google's comp.lang.forth archives.  And just for the
record, unless Phil was being ironic, I have no fear of open spaces.
Our trip to Calgary/Banff a couple years ago was great, and roaming
around not only the mountainous areas but the wide and flat areas was
probably one of the best things we've ever done.  But that's the
problem when you try to stalk people on the Internet-- you can't
always tell when a comment was meant to be comedic or factual.

Or was that not the point?  Am I supposed to be intimidated that you
know how to type my name into Google and click on the links you find?
Sorry, but the only thing this latest display of your many character
defects has done is just confirm you're a whack-job.

> Yes I know. According to you Forth is actually a lie.
> I am a liar, mindless parrot, and dangerous cultist.
> According to you Chuck is a liar and snake-oil-salesman.
> When you lose a logical argument that is where you
> always go.

I've never written that Forth is a lie.  I've written that some of
your claims about Forth are lies, but you lie all the time, either out
of purposeful deception or because you don't know any better.  I've
never written you are a dangerous cultist.  That's your fevered mind
chewing on a metaphor that you've tried your best to whip into a froth
and failed.  You remember that, I stated that some people have built a
personality cult around Charles Moore (which is still as true as when
I first wrote it).  I never wrote it was dangerous, just stupid.
Then, apparently some crazy person somewhere scared big tough Jeff Fox
senseless.  You know, kind of like me with insects, supposedly.  Yes,
the self-described Martial Arts expert was terrified of a vague
comment from some random person on the Internet.  Absolutely
terrifying.  Maybe one day when I fully get over my entomophobia, you
can get over your morbid fear of vague comments from random people on
the Internet.

I've never said Charles Moore was a liar, but you're free to produce
the message that likely says something quite different that you'll try
to twist.

> I can't make any general statements about the long list
> of your particular mental problems but you do have my
> sympathy and hopes that someday you will get over the
> agoraphobis and hate.  You can't always count on your
> husband and his "amazing squashing powers" to save you
> when you go screaming away from things that frighten
> you.  I have seen that you have learned a little about
> Forth in the last twenty years and may someday actually
> be able to show people your Forth code.

Yes, maybe when the code I write isn't owned by others, or so damn
specific to the hardware platform that it wouldn't be useful to anyone
else, I'll gladly offer it.  And the same goes for you.  You've spent
years talking about C, yet except for the most trivial examples that
you could get from K&R, I've never actually seen you demonstrate
actual knowledge with the language.  You'd think that would be a
requirement for someone trying to make logical arguments against C,
but hey, it takes all kinds.

Best wishes.

Incidentally, I'm starting my stupid little blog again, and aside from
the usual technical stuff, there is undoubtedly going to be personal
stuff I'm likely to put there which you'll feel compelled to quote
from.  Keep watching-- as I know you will.  I realize now I can have
enormous fun by purposefully putting odd and untrue things in my blog
and seeing you reposting it.  This should be oodles of fun.

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

#1476

John Passaniti <john.passaniti@gmail.com> writes:
> Incidentally, I'm starting my stupid little blog again,

What's the url?

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

#1446

John Passaniti <john.passaniti@gmail.com> writes:
> But it's not true for C in an embedded context.  Many C compilers that
> I've used over the years ...only use stack for return
> addresses. ... It obviously prevents the ability to create recursive
> calls to a function (except for tail recursion which can always be
> replaced with iteration). 

Wait, what kind of C compiler is that?  I thought even very small
cpus these days tended to use GCC.  I'd certainly call a compiler
that did what you describe something other than a C compiler.

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

#1453

Paul Rubin <no.email@nospam.invalid> wrote:
> John Passaniti <john.passaniti@gmail.com> writes:
>> But it's not true for C in an embedded context.  Many C compilers that
>> I've used over the years ...only use stack for return
>> addresses. ... It obviously prevents the ability to create recursive
>> calls to a function (except for tail recursion which can always be
>> replaced with iteration). 
> 
> Wait, what kind of C compiler is that?  I thought even very small
> cpus these days tended to use GCC.  I'd certainly call a compiler
> that did what you describe something other than a C compiler.

You can't used gcc to generate code for an 8051 and expect decent
results.  It's perfectly legal to do what John Passaniti describes,
and it's necessary on the 8051.  (To be a fully-compliant
implementation of ISO C, though, you have to allow recursion.  AFAIK
those systems that target 8051s and claim to be standard do allow it,
albeit inefficiently, and you'll run out of memory anyway.)

Andrew.

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

#1471

On Apr 23, 4:55 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> You can't used gcc to generate code for an 8051 and expect
> decent results.  It's perfectly legal to do what John
> Passaniti describes, and it's necessary on the 8051.  
> (To be a fully-compliant implementation of ISO C, though,
> you have to allow recursion.  AFAIK those systems that
> target 8051s and claim to be standard do allow it, albeit
> inefficiently, and you'll run out of memory anyway.)

Most every C compiler for embedded systems I've ever used have a
section of the manual that clearly points out where they may deviate
from the standard and give work-arounds or compiler switches to make
the compiler work in a manner conforming to the standard.  This is
rarely ever a problem, because by deviating from the standard, better
(smaller, faster) code can be generated.  And that usually has far
more value to the programmer than conformance to the standard.  Does
that make the compiler not fully compliant under ANSI or ISO
standards?  Most embedded systems programmers using C would say "who
cares."  It's like a parent telling their child, "if you don't eat
your broccoli, you can't clean up the garage later."  Ummm, okay...
sounds good to me!

Specific to the 8051 family, most embedded C compilers for those chips
usually offer (at least) two memory models.  One memory model assumes
only on-chip resources, so the only RAM you'll have is what is
provided by the chip (and this vary in different derivatives).
Another memory model is for when you hook up external SRAM and/or ROM
to the 8051 (which was quite common and fairly easy, given the 8051
brought the address bus out to pins).  In that memory model, you could
say that when calling some functions, that they would use a software-
managed stack in the external RAM using a pragma or linker directive.
So you could have recursive functions if you wished.  But usually, the
reason one would do this had less to do with supporting recursion, but
because you wanted to maximize your use of the on-chip RAM for your
program.  That gave you higher code density and faster access.  Each
function call would be more expensive than if you used on-chip RAM,
but each function can run faster and generate less code doing it.  And
all this also means you usually had the ability to mix memory models
as you needed.

Another example of deviation from the standards would be in supporting
variable number of arguments.  Several C compilers for embedded
systems I've used will optimize parameter passing; if you pass a char,
it will be a char and not be widened to an int.  I don't know (and
don't care) if that deviates from the standard, but it implies that
the classic mechanism to support variable number of arguments to a
function either won't work or are very sensitive to the expected size
of those parameters.  But using variable number of arguments is a
fairly rare thing in general C code and nearly non-existent in
embedded C code.  And if you really need it, there are usually
compiler directives to make it work, albeit at the cost of less
efficient code.

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

#1468

On Apr 23, 3:49 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> John Passaniti <john.passan...@gmail.com> writes:
> > But it's not true for C in an embedded context.  Many C compilers that
> > I've used over the years ...only use stack for return
> > addresses. ... It obviously prevents the ability to create recursive
> > calls to a function (except for tail recursion which can always be
> > replaced with iteration).
>
> Wait, what kind of C compiler is that?  I thought even very small
> cpus these days tended to use GCC.  I'd certainly call a compiler
> that did what you describe something other than a C compiler.

SDCC would be another alternative. It can select between stacking all
data and only stacking data for recursive functions, and has a '51
option to only use the hardware stack for return addresses, using the
first 256 bytes of external memory for data.

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

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