Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #1242 > unrolled thread
| Started by | gavino <gavcomedy@gmail.com> |
|---|---|
| First post | 2011-04-17 00:34 -0700 |
| Last post | 2011-04-21 18:33 -0700 |
| Articles | 20 on this page of 166 — 22 participants |
Back to article view | Back to comp.lang.forth
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 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2011-04-21 19:49 -0700 |
| Message-ID | <3b7c9f95-1cde-45e1-adf7-dcc42ab933de@d27g2000vbz.googlegroups.com> |
| In reply to | #1392 |
On Apr 21, 9:58 pm, Paul Rubin <no.em...@nospam.invalid> wrote: > BruceMcF <agil...@netscape.net> writes: > > Yeah, but which of the solutions proposed would fail to fit 8 data > > stack levels? > The idea is that the code is called from other code that is already > using stack space. Why? I mean, if its that small a hardware stack, why precisely would you be in the habit of calling things with a known stack depth requirement with a bunch of stuff already on the stack?
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-04-22 00:02 -0700 |
| Message-ID | <7xd3ke4vlf.fsf@ruckus.brouhaha.com> |
| In reply to | #1393 |
BruceMcF <agila61@netscape.net> writes: > Why? I mean, if its that small a hardware stack, why precisely would > you be in the habit of calling things with a known stack depth > requirement with a bunch of stuff already on the stack? Obviously you have to keep track of how much stuff is on the stack, in situation. If N-3 of your available slots are in use, you can call a word that uses 3 slots but not one that use 4 slots. Or you might have to lock out interrupts or something.
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2011-04-22 06:59 -0700 |
| Message-ID | <e812999f-dcf7-45c5-b303-3b69a648dd61@f15g2000pro.googlegroups.com> |
| In reply to | #1403 |
On Apr 22, 3:02 am, Paul Rubin <no.em...@nospam.invalid> wrote: > BruceMcF <agil...@netscape.net> writes: > > Why? I mean, if its that small a hardware stack, why precisely would > > you be in the habit of calling things with a known stack depth > > requirement with a bunch of stuff already on the stack? > Obviously you have to keep track of how much stuff is on the stack, in > situation. If N-3 of your available slots are in use, you can call a > word that uses 3 slots but not one that use 4 slots. I was asking about the part before your "if" ~ why when programming for a processor like that, you'd normally program the processor that is handling that kind of mathematical step so that it has an arbitrary amount of data on its stack going into a step. > Or you might > have to lock out interrupts or something. The flip side of the small stack is the multiprocessors ~ if you can dedicate a processor to handling what would be an interrupt in a conventional processor, you don't need to share the same stack between mathematical processing and interrupt processing. And outside that very specialized context, even a 32 deep data stack and 16 deep return stack renders the question largely moot.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-04-23 01:20 -0700 |
| Message-ID | <7x4o5pidka.fsf@ruckus.brouhaha.com> |
| In reply to | #1412 |
BruceMcF <agila61@netscape.net> writes: > I was asking about the part before your "if" ~ why when programming > for a processor like that, you'd normally program the processor that > is handling that kind of mathematical step so that it has an arbitrary > amount of data on its stack going into a step.... > And outside that very specialized context, even a 32 deep data stack > and 16 deep return stack renders the question largely moot. I guess I just don't see what you're getting at. I think of Forth as being something like assembly programming, something one does either from necessity or for enjoyment; either way, trying to bum bits and bytes seems like an inextricable part of the activity. Lots of machines have 16 registers but if I can write a code sequence that uses 4 registers or one of equivalent length and complexity that only uses 3 registers, it just seems like a no-brainer to save a register so some other part of the program can use it. Certainly any self-respecting compiler should use the 3 register sequence if it didn't impose some other cost. So it just didn't feel like I'd done something worthy of this much examination.
[toc] | [prev] | [next] | [standalone]
| From | foxchip <fox@ultratechnology.com> |
|---|---|
| Date | 2011-04-21 21:11 -0700 |
| Message-ID | <cdb3f5e1-b4d7-41ca-b86e-723196c8e6c0@m23g2000prl.googlegroups.com> |
| In reply to | #1392 |
On Apr 21, 5:58 pm, Paul Rubin <no.em...@nospam.invalid> wrote: > I mentioned the GA chip only as an example of a Forth platform that has > very limited stack depth. Chuck's first VLSI Forth chip, MuP21, had only six cells in the data stack and four in the return stack. Chuck said that his was quite sufficient for well factored Forth code. It was one of the things that people without practice at writing well factored Forth code had a problem with. F21 originally was to have 32 and 28 cells respectively when the draft ANS document required that much to be complaint. But the requirement was dropped from the standard. Eventually F21 got 18 and 17 respectively and the same core was also used on i21. Chuck felt it was a bit much but I insisted as F21 had smart video, analog, and network coprocessors to reduce the CPU computation load and these coprocessors could generate interrupts for the cpu. Since the stack bit-width was wider than the memory bit-width the processes of swapping stacks in or out of memory was more involved that one would prefer. i21 had smart video and serial coprocessors that could generate cpu interrupts. I had to correct Chuck a year or two ago when he made a public comment that no processor he had ever designed used interrupts. He recalled that he didn't enjoy designing the circuits to support interrupts from two or three coprocessors on chip. If in a multiprocessor node did not use a video coprocessor for video it could instead be used for external interrupts. Chuck had forgotten those details from the nineties and I expect many readers in c.l.f were also confused as certain people posted so much misinformation about those chips telling others things like how they had no interrupt circuits. To make things simpler the next generation of chips used circuits much faster than is possible with interrupts since they require no memory cycles at all to handle external events more quickly than can be done with interrupts. And the designs and the coding were simplified by not having multiple coprocessors on the chip that each required a unique design and unique instruction set. The idea was to use software on Forth processors to do what had been done in the past with dedicated coprocessors. 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. Since no address decoding was involved as is with RAM or ROM the number of stack registers did not effect speed but it did effect real-estate use, size, chip cost, and power use. Chuck's Sh-Boom had hardware supported stack spill/fill to or from main memory when the stack depth was greater than the number of stack registers on chip. Dr. Koopman's early research said that with eight stack registers spill/fill in traditional Forth would be needed in about 1% of the code. We found that since MISC hardware/software, which required stack spill/fill to be done by software to simplify the hardware, made more conservative use of the stack and in a few man years of coding there was only one example of stack spill/fill to/from MuP21's six cell deep stack. In a fifteen or so man years of f21/i21 coding where some of the hardware stack had dedicated full time use in the OS and GUI and some for dedicated use by coprocessor interrupts there were no examples of stack spill/fill ever being needed. Dr. Monvelishsky made the comment that he felt it was more fun to code for MuP21 than for F21/i21 because one had to write tighter code with more conservative stack use given it only had six data stack cells. > The code I posted wasn't claimed to be GA code. I think > Elizabeth has posted that most Forth programs (including > complex apps on larger machines) don't use more than around > 30 stack levels. She also said that if they link to a non-Forth host OS or to C libraries that the stack use could be quite substantial. > By that standard, it seemed better to use 3 instead of 4 in the > exercise if that doesn't result in bloating up the code some other way. Using that same logic Marcel's and my examples used one cell instead of three or four. I used a total of 4 cells of code which avoided the code bloat of some other examples. I was following two factoring rules: do not do at runtime that which can be done at compile time and conserve stack space using no more than is needed. Best Wishes
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-04-22 00:16 -0700 |
| Message-ID | <7x8vv24uyy.fsf@ruckus.brouhaha.com> |
| In reply to | #1398 |
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. Chuck said > that his was quite sufficient for well factored Forth code. > It was one of the things that people without practice > at writing well factored Forth code had a problem with. Yes I think it helps that the cpu nodes are so small, the programs can only be a few hundred words long, so it's possible to concoct them to limit their calling depth like that. For a bigger program (say OKAD on a PC) I'd expect you have to care about modularity more, and use deeper factoring and calls. But you'd know more about this than me. > 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. It sounds like the smaller PICs that have just 2 levels, normally programmed in assembler. > 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. Are you saying stack push and pop is made by actually moving all 8 words around in parallel? It does say in the data book (p. 7) that it's done by adjusting a pointer, which would indicate some kind of address decoding. Or some simpler but bigger MUX than ram uses? I don't know much about how this stuff is implemented. I was surprised to see that the ram access time is around 5 ns. I guess 600+ mhz is just astoundingly fast for 0.18u though, so having to wait a few ticks for the ram is not surprising. > Dr. Koopman's early research said that with eight stack registers > spill/fill in traditional Forth would be needed in about 1% of the code. I've been wanting to read his book. > Dr. Monvelishsky made the comment that he felt it was more > fun to code for MuP21 than for F21/i21 because one had to > write tighter code with more conservative stack use given > it only had six data stack cells. I can believe that. With a chip that small it's possible to keep the whole program in one's head and know what's in each slot the whole time.
[toc] | [prev] | [next] | [standalone]
| From | foxchip <fox@ultratechnology.com> |
|---|---|
| Date | 2011-04-22 10:12 -0700 |
| Message-ID | <0bfd4816-17fd-4372-89a6-98f3ac37ae84@z7g2000prh.googlegroups.com> |
| In reply to | #1404 |
On Apr 21, 11:16 pm, Paul Rubin <no.em...@nospam.invalid> wrote: > Yes I think it helps that the cpu nodes are so small, the programs can > only be a few hundred words long, so it's possible to concoct them to > limit their calling depth like that. The largest programs I did on the MuP21 were only 16 kilowords. One began life as a 16MB window program and when ported to polyForth dropped to 1.2MB then when ported to MuP21 used only 16 kilowords. ANS P21Forth on the MuP21 used the single Forth CPU and the video coprocessor and external parallel and serial ports made from a few CMOS chips doing address decoding and latching. > For a bigger program (say OKAD on > a PC) I'd expect you have to care about modularity more, and use deeper > factoring and calls. But you'd know more about this than me. One of the most interesting specs for MuP21 was that it be able to host the program that created it, OKAD. This was possible because OKAD had originally been factored to be able to run on something like an MuP21. P21 was done in a 1.2u process. F21 was a larger chip. Still with only one Forth CPU but more memory busses, more addressing modes, more instructions, more efficient circuits and four coprocessors and other I/O hardware on chip. The network processor was my design implemented by Chuck to do active message routing in a most efficient way to allow it to be used as a node in workstation farm for parallel processing applications. F21 was done in 0.8u and 0.65u technologies. I had a little more more memory than MuP21 and was several times faster. The coprocessors were far more complex than P21 and it had things like interrupts. But its design required more memory than MuP21 so you needed two $1 F21 to be able to host OKAD. > > 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. > > It sounds like the smaller PICs that have just 2 levels, normally > programmed in assembler. And the transputer had three levels so you could not really do native code Forth directly on chips with only two or three stack cells. MuP21 was probably the minimum for that. > > 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. > > Are you saying stack push and pop is made by actually moving all 8 words > around in parallel? No. I wrote simlators for all of Chuck's early MuP20 and real and proposed MuP21 designs as well as proposed and real F21 and i21 designs. My first simulators actually moved all 6 or 18 stack cells around and I used about 4KB of code for a compiler and simulator. Later I saw how Chuck implemented the stacks in hardware and I was quite surprised at how efficient it was and how it didn't need any register decoding and only moved things between the top of the stack (T) the second position (S) and one of the cells in the circular stack array. When Chuck wrote his first cross compiler for the first real MuP21 I was also surprised that instead of using a few KB like I had in his way of coding it took him 300Bytes. That's when I began to question how much Forth I had really learned in my first twelve years of programming in Forth. I had learned from FIG-Forth and people who didn't program much like the way Chuck did things at all. > It does say in the data book (p. 7) that it's done > by adjusting a pointer, which would indicate some kind of address > decoding. Well of course the actual ciruits are proprietary. The term pointer is used in the most generic way. I always used the term "selector" since the stacks are not random access memory, and don't have what most people call "pointers" and don't do anything resembling address decoding. > ? Or some simpler but bigger MUX than ram uses? No. Nothing big and not a MUX. > I don't know > much about how this stuff is implemented. I was surprised to see that > the ram access time is around 5 ns. I guess 600+ mhz is just > astoundingly fast for 0.18u though, so having to wait a few ticks for > the ram is not surprising. Sure. The idea is MISC is that stack instructions can run many times faster than memory without the need for expensive pipelining and memory cache because multiple instructions get packed into a word. So you can fetch then decode and execute opcodes in parallel and execute up to four stack opcodes per memory operation. That's how c18 gets over 600+ Forth mips out of instructions coming from much slower RAM. Memory read/write instructions are as slow as memory. > > Dr. Koopman's early research said that with eight stack registers > > spill/fill in traditional Forth would be needed in about 1% of the code. > > I've been wanting to read his book. It has been online for many years. It is an excellent book. However it leaves off when I came into things and does not explain Sh-Boom, MuP20, MuP21, F21, i21, v21, p8, p32, x25, c18, SEAforth24, SEAforth40, GA40, GA32, GA4, or GA144. > > Dr. Monvelishsky made the comment that he felt it was more > > fun to code for MuP21 than for F21/i21 because one had to > > write tighter code with more conservative stack use given > > it only had six data stack cells. > > I can believe that. With a chip that small it's possible to > keep the whole program in one's head and know what's in each > slot the whole time. Sure but I found that porting programs that took megabytes on a PC were too complex to keep all the details in my head at once. I explored a lot of design changes and coding styles by using software simulators. Best Wishes
[toc] | [prev] | [next] | [standalone]
| From | Jan Coombs <jan_2011-02@murray-microft.co.uk> |
|---|---|
| Date | 2011-04-23 07:38 +0100 |
| Message-ID | <qdydnYCgNYpF7i_QnZ2dnUVZ8jOdnZ2d@brightview.co.uk> |
| In reply to | #1404 |
>> Dr. Koopman's early research said that with eight stack registers >> spill/fill in traditional Forth would be needed in about 1% of the code. > > I've been wanting to read his book. You might borrow my copy, or: http://www.ece.cmu.edu/~koopman/stack_computers/ Jan Coombs
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-04-25 00:05 -0700 |
| Message-ID | <7xtydmzu7w.fsf@ruckus.brouhaha.com> |
| In reply to | #1444 |
Jan Coombs <jan_2011-02@murray-microft.co.uk> writes: >>> Dr. Koopman's early research ... >> I've been wanting to read his book. > You might borrow my copy, or: > http://www.ece.cmu.edu/~koopman/stack_computers/ Thanks. I do know about the online version and that's what I was figuring on reading. I spent a little while looking at it last night and it wasn't quite what I expected, but it was still interesting. For some reason I thought he had a chapter on how to compile register code to a stack machine. Maybe it is there and I didn't look in the right place.
[toc] | [prev] | [next] | [standalone]
| From | Jan Coombs <jan_2011-02@murray-microft.co.uk> |
|---|---|
| Date | 2011-04-25 13:34 +0100 |
| Message-ID | <1oCdnaR_sfyj9yjQnZ2dnUVZ8lWdnZ2d@brightview.co.uk> |
| In reply to | #1498 |
On 25/04/11 08:05, Paul Rubin wrote: > Jan Coombs<jan_2011-02@murray-microft.co.uk> writes: >>>> Dr. Koopman's early research ... >>> I've been wanting to read his book. >> You might borrow my copy, or: >> http://www.ece.cmu.edu/~koopman/stack_computers/ > > Thanks. I do know about the online version and that's what I was > figuring on reading. I spent a little while looking at it last night > and it wasn't quite what I expected, but it was still interesting. For > some reason I thought he had a chapter on how to compile register code > to a stack machine. Maybe it is there and I didn't look in the right > place. I have also read this, could not find a local copy, so searched Phil's pages; you can download the paper here: http://www.ece.cmu.edu/~koopman/stack_compiler/stack_co.pdf Which is linked under 1994 on this page: http://www.ece.cmu.edu/~koopman/pubs.html A number of interesting older files I've just downloaded from this page all come in at 192kB, but I can't find anything to open them with under ubuntu. BTW, I've been translating the J1 Novix style core from Verilog into MyHDL, which is a sort of fast prototyping interactive hardware development tool. I'm at the just working stage, and can export the design as Verilog or VHDL. Could you drop me an email if you'd like to mentor or help. Jan Coombs --
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-04-25 08:50 -0700 |
| Message-ID | <7xtydmuy8b.fsf@ruckus.brouhaha.com> |
| In reply to | #1510 |
Jan Coombs <jan_2011-02@murray-microft.co.uk> writes: > I have also read this, could not find a local copy, so searched Phil's > pages; you can download the paper here: > > http://www.ece.cmu.edu/~koopman/stack_compiler/stack_co.pdf Oh cool, yes, that's the one I remember, thanks. It is a little more ad-hoc than I hoped, and it uses words like ROT which access the 3rd stack level. > Which is linked under 1994 on this page: > http://www.ece.cmu.edu/~koopman/pubs.html Very good stuff there. > A number of interesting older files I've just downloaded from this > page all come in at 192kB, but I can't find anything to open them with > under ubuntu. xpdf seem to work for me. > BTW, I've been translating the J1 Novix style core from Verilog into > MyHDL, which is a sort of fast prototyping interactive hardware > development tool. I'm at the just working stage, and can export the > design as Verilog or VHDL. Could you drop me an email if you'd like to > mentor or help. Heh, I wish. I have an interest in this stuff (hardware languages) but almost no knowledge. I'd just be in the way.
[toc] | [prev] | [next] | [standalone]
| From | foxchip <fox@ultratechnology.com> |
|---|---|
| Date | 2011-04-25 23:11 -0700 |
| Message-ID | <3a0e1471-563a-4d68-a7b9-683c1b425172@k40g2000pro.googlegroups.com> |
| In reply to | #1510 |
On Apr 25, 4:34 am, Jan Coombs <jan_2011...@murray-microft.co.uk> wrote: > BTW, I've been translating the J1 Novix style core from Verilog > into MyHDL, which is a sort of fast prototyping interactive > hardware development tool. I'm at the just working stage, and can > export the design as Verilog or VHDL. One of my favorite Novix stories was something I overhead while walking down a hall at Forth conference. Someone was saying to a group of people that they should ignore the work of Chuck Moore because all of his new chips were obsolete before they were manufactured. On the other hand he now that the Novix and RTX patents were more than seventeen years old that he could make and sell his own copy of these antique designs and that these designs were not obsolete. I was also told that at a EuroForth conference he had told people that they should ignore Chuck's work because he was just simulating chips and that they were not physical. He and the group were then told, "that is nonsense! I bought and have had physical versions of those chips for years and written lots of software for them!" Of course when lies are repeated often enough they become myth and the myth becomes accepted as truth. Best Wishes
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-04-22 00:18 -0700 |
| Message-ID | <7x4o5q4uuh.fsf@ruckus.brouhaha.com> |
| In reply to | #1398 |
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.
[toc] | [prev] | [next] | [standalone]
| From | foxchip <fox@ultratechnology.com> |
|---|---|
| Date | 2011-04-22 10:19 -0700 |
| Message-ID | <ac18cc57-b6ea-4170-9f21-9d75ddb0f0cb@x37g2000prb.googlegroups.com> |
| In reply to | #1405 |
On Apr 21, 11:18 pm, Paul Rubin <no.em...@nospam.invalid> wrote: > foxchip <f...@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. The C team thought that was needed can came up with a design with eight neighbor communication. However instead of using less than 0.1% of the chip real estate it ended up making the chip twice as large for their 8 neighbor design and the whole chip became many times larger for their other communication scheme. This was something Chuck and I wanted to avoid. I had learned when I was in the parallel processing connection that the communication mechanism on big processors was usually the most complicated and expensive thing, sometimes costing millions of dollars to make. 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. But it was designed to compete with the 7mbps designs that were popular on PC workstation farms at the time. A dozen years later the Occam like shared communication ports could provide 1.8gbps with only a handful of transistors. Best Wishes
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-04-25 10:43 -0700 |
| Message-ID | <7xd3ka9qh1.fsf@ruckus.brouhaha.com> |
| In reply to | #1420 |
foxchip <fox@ultratechnology.com> writes: > The C team thought that was needed can came up with a design with > eight neighbor communication. However instead of using less than 0.1% > of the chip real estate it ended up making the chip twice as large > for their 8 neighbor design and the whole chip became many times > larger for their other communication scheme. Wait, the 4 ports per node use just 0.1% of the chip, but making 8 ports per node doubles the size? They must have changed a lot of other stuff too. > This was something Chuck and I wanted to avoid. I had learned when > I was in the parallel processing connection that the communication > mechanism on big processors was usually the most complicated and > expensive thing, sometimes costing millions of dollars to make. But the alternative is communication bottlenecks! 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2011-04-25 13:17 -0700 |
| Message-ID | <8fd294c2-3c28-4213-bf95-094b1d2f9706@n10g2000yqf.googlegroups.com> |
| In reply to | #1521 |
On Apr 25, 1:43 pm, 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? They must have changed a lot > of other stuff too. Does a cube need non-local connection in the layout? Another mapping onto a regular square lattice with additional communication channels is a hexagonal field, which can be obtained by the four nodes of a square lattice plus two diagonal nodes (AFAIR the diagonal nodes required alternate in a regular pattern).
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-04-25 16:32 -0700 |
| Message-ID | <7x4o5lq541.fsf@ruckus.brouhaha.com> |
| In reply to | #1523 |
BruceMcF <agila61@netscape.net> writes: > On Apr 25, 1:43 pm, 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? They must have changed a lot >> of other stuff too. > > Does a cube need non-local connection in the layout? My suggestion was simply adding diagonal connections to each node, like the way a king moves on a chessboard, so each node would be connected to its 8 local neighbors. Cube would need non-local connection and maybe more wires and vias, but that was a later suggestion. I think it might be worth giving up some cpu nodes for this extra connectivity for some applications. > the four nodes of a square lattice plus two diagonal nodes (AFAIR the > diagonal nodes required alternate in a regular pattern). 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.
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2011-04-25 18:21 -0700 |
| Message-ID | <b43702d2-fc8f-4ef0-a0d9-5b795490115d@b9g2000yqd.googlegroups.com> |
| In reply to | #1527 |
On Apr 25, 7:32 pm, Paul Rubin <no.em...@nospam.invalid> wrote: > BruceMcF <agil...@netscape.net> writes: > > On Apr 25, 1:43 pm, 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? They must have changed a lot > >> of other stuff too. > > > Does a cube need non-local connection in the layout? > > My suggestion was simply adding diagonal connections to each node, like > the way a king moves on a chessboard, so each node would be connected to > its 8 local neighbors. Cube would need non-local connection and maybe > more wires and vias, but that was a later suggestion. I think it might > be worth giving up some cpu nodes for this extra connectivity for some > applications. > > > the four nodes of a square lattice plus two diagonal nodes (AFAIR the > > diagonal nodes required alternate in a regular pattern). > > 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. AFAIR, different pairs of diagonal connections. Hexagonal lattices are sometimes used for spatial cell modelling, to avoid taxicab geometry biases, but its been quite a while since I saw the layout, so my recall of the specifics is shaky.
[toc] | [prev] | [next] | [standalone]
| From | Charles G Montgomery <cgm@physics.utoledo.edu> |
|---|---|
| Date | 2011-04-26 19:36 -0400 |
| Message-ID | <ip7kta$ljt$1@pyrite.mv.net> |
| In reply to | #1529 |
BruceMcF agila61@netscape.net wrote: > On Apr 25, 7:32 pm, Paul Rubin <no.em...@nospam.invalid> wrote: >> BruceMcF <agil...@netscape.net> writes: >> (...) >> My suggestion was simply adding diagonal connections to each node, like >> the way a king moves on a chessboard, so each node would be connected >> to its 8 local neighbors. Cube would need non-local connection and >> maybe more wires and vias, but that was a later suggestion. I think it >> might be worth giving up some cpu nodes for this extra connectivity for >> some applications. >> >> > the four nodes of a square lattice plus two diagonal nodes (AFAIR the >> > diagonal nodes required alternate in a regular pattern). >> >> 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. > > AFAIR, different pairs of diagonal connections. Hexagonal lattices are > sometimes used for spatial cell modelling, to avoid taxicab geometry > biases, but its been quite a while since I saw the layout, so my > recall of the specifics is shaky. The hexagonal lattice, in which each unit cell is a hexagon, is threefold- coordinated: each point has three equidistant nearest neighbors. But its lattice dual, the triangular lattice, is sixfold-coordinated. Most introductory texts on solid-state physics should have better pictures than I can manage with ascii-art. regards to all cgm
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2011-04-26 21:05 -0700 |
| Message-ID | <9fb739e6-2585-401d-9848-d6aa0b613a66@f18g2000yqd.googlegroups.com> |
| In reply to | #1563 |
On Apr 26, 7:36 pm, Charles G Montgomery <c...@physics.utoledo.edu> wrote: > BruceMcF agil...@netscape.net wrote: > > On Apr 25, 7:32 pm, Paul Rubin <no.em...@nospam.invalid> wrote: > >> BruceMcF <agil...@netscape.net> writes: > >> (...) > >> My suggestion was simply adding diagonal connections to each node, like > >> the way a king moves on a chessboard, so each node would be connected > >> to its 8 local neighbors. Cube would need non-local connection and > >> maybe more wires and vias, but that was a later suggestion. I think it > >> might be worth giving up some cpu nodes for this extra connectivity for > >> some applications. > > >> > the four nodes of a square lattice plus two diagonal nodes (AFAIR the > >> > diagonal nodes required alternate in a regular pattern). > > >> 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. > > > AFAIR, different pairs of diagonal connections. Hexagonal lattices are > > sometimes used for spatial cell modelling, to avoid taxicab geometry > > biases, but its been quite a while since I saw the layout, so my > > recall of the specifics is shaky. > > The hexagonal lattice, in which each unit cell is a hexagon, is threefold- > coordinated: each point has three equidistant nearest neighbors. But its > lattice dual, the triangular lattice, is sixfold-coordinated. Most > introductory texts on solid-state physics should have better pictures than > I can manage with ascii-art. > > regards to all cgm Yes, I was thinking of a processor cell as a hexagon connected to each neighbor, which as a lattice is a triangular lattice. Effectively, to map it onto a square array, each odd column of cells are connected to their upper diagonal neighbors as well as their vertical and horizontal neighbors, and each even column of cells are connected to their lower diagonal neighbors.
[toc] | [prev] | [next] | [standalone]
Page 3 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