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 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-04-26 04:02 -0500 |
| Message-ID | <N-WdnX9WwvuiFyvQnZ2dnUVZ8gidnZ2d@supernews.com> |
| In reply to | #1536 |
foxchip <fox@ultratechnology.com> wrote: > On Apr 25, 12:35 am, Andrew Haley <andre...@littlepinkcloud.invalid> > wrote: >> So if it has a huge penalty, don't use it. This is a red herring. > > One avoids huge penalties like one avoids a stinking dead herring. > >> The only question is whether PICK requires a stack pointer, which it >> doesn't. > > No. Yes. The post of mine to which you were replying was only about whether PICK requires a stack pointer. Everything else is irrelevant to my posting. >> > It also has serious bugs. >> > (details of one example edited out) > >> On such severely resource-constrained systems you're going to >> trouble with PICK, of course. > > That problem exists on all systems that don't have infinite stacks. No, it does not. As long as you have enough stack space, you're fine. There is no need for infinity. >> Why does the working of PICK require DUP etc. not to use the return >> stack? > > For the reason I had given above that. The non-standard definition > of PICK you gave requires that the return stack be bigger than > the data stack and you can't count on that. No, it does not: it requires the return stack to be bigger than the argument to PICK. More than twice as big, in fact. >> So don't invoke PICK when the stack is nearly full. Better, don't >> invoke PICK at all. > > Right. Generally speaking it is good to learn that C stacks and > Forth stacks don't have to work the same way. Forth is suppose to > be an alternative to C, not a subset of it. > > Do you also need DEPTH to know when the stack is nearly full > to know when PICK will fail? No, of course not, any more than you call DEPTH every time to find out if DUP is going to fail. >> How would a stack pointer somewhere make any difference to being able >> to dump a stack into memory? > > Is there a "portable" way to know how many items you need to > dump from the stack into memory? If you don't have DEPTH or a stack pointer you are going to need to know how big your stacks are. If your stack is a circular buffer N cells in size then you need to know what N is. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2011-04-26 22:40 +0200 |
| Message-ID | <v6nj88-qdl.ln1@vimes.paysan.nom> |
| In reply to | #1539 |
Andrew Haley wrote: > If you don't have DEPTH or a stack pointer you are going to need to > know how big your stacks are. If your stack is a circular buffer N > cells in size then you need to know what N is. Indeed, if you have an 8 elements circular buffer, you can write the 8 possible PICKS as : 0pick dup ; \ we have it in the instruction set! : 1pick over ; \ me too! : 2pick drop drop >r drop drop drop drop drop r> ; : 3pick drop drop drop >r drop drop drop drop r> ; : 4pick drop drop drop drop >r drop drop drop r> ; : 5pick drop drop drop drop drop >r drop drop r> ; : 6pick drop drop drop drop drop drop >r drop r> ; : 7pick drop drop drop drop drop drop drop ; : pick jmps 0pick 1pick 2pick 3pick 4pick 5pick 6pick 7pick This is about 10 times slower than dup and over. When your circular buffer is underneeth T and S (as registers), you need to do a bit more, but the principle is still the same. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-04-25 14:16 -0700 |
| Message-ID | <2a5b4f1b-d33e-42ce-95d2-c15c7256c9ed@j25g2000vbr.googlegroups.com> |
| In reply to | #1496 |
On Apr 25, 4:27 am, foxchip <f...@ultratechnology.com> wrote: > I have seen this before. It has some very serious problems. > > : pick ?dup if swap >r 1- recurse r> swap else dup then ; > > In the context I had showed being able to do this all might > first require slowing all stack access in Forth by a hundred > times. Calling five words recursively might make PICK a few > hundred thousands times slower again than other stack > operations. It is a huge penalty whether one thinks PICK > is a good word or not. > > It also has serious bugs. > > On the processors I have worked on for a decade there are only > ten data stack cells and only nine cells on the return stack. > Also many ANS Forth compliant systems have fewer cells on their > return stack than on their data stack. > > 0 PICK is DUP and 1 PICK is OVER. So on a ten deep data stack > one would only need to PICK at stack cells 2-9. > > The standard only says, "An ambiguous condition exists if there are > less than u+2 items on the stack before PICK is executed." It does > not warn of stack overflow but with u items on the stack you cannot > pick item u or it will cause a data stack overflow error or > data stack overwrite. It is simply impossible. > > With a 10 deep data stack and 9 deep return stack; > > 9 PICK \ maybe use a return stack cell for the return from PICK > > on the first pass the ?DUP would cause data stack > cell 9 to be corrupted and case failure as > that was the one you wanted to pick. > > Other systems might fail with a stack overflow exception. > > That's not the only way it can fail. > > N PICK \ where N is larger than cells on the return stack. > > Use one return stack cell for PICK.>R in the loop uses one stack cell and is repeated > > counting down the counter. > > N...,9,8,7,6,5,4,3,2,1,0 > > Resulting in failure before it gets to zero. > It thus has an environmental dependency > that the return stack be bigger than the data stack. > > Without this explicit environmental dependency > statement it is not portable working code > as many compliant systems indeed have smaller > return stacks than data stacks. It also requires > that ?DUP SWAP etc. will not need to use the > return stack to return unless the return stack > is bigger still. > > An early ANS draft required a minimum of 32 data > stack cells and 28 return stack cells. That > requirement went away but showed the thinking > that a return stack smaller than the data stack > was ok. Many ANS compliant implementations still > have fewer cells in their return stack than in > their data stack. > > Besides just declaring various environmental > dependencies and accepting that it won't work > on many ANS Forth systems the only other halfway > practical option is to dump N words from the > data stack to memory, then index into this > dump, then load it back onto the data stack > with a copy of the Nth item on the top and > it would also be a requirement that the code > that does this must not add anything more than > one cell to the data stack in the code that does > that when the stack is nearly full when the > PICK is invoked. > > And dumping the whole stack to memory > without using the stack could be very > very ugly or simply impossible without > a stack pointer somewhere and/or a stack > in memory. > > I always said, "It is impolite to PICK > your nose or your stack in public." > > It is primitive and repulsive code. > It is also considered impolite in many > cultures to expectorate, micturate, fart, > or evacuate your waste in public. > > Best Wishes Unless you're a horse. But then a horse can't pick it's nose. It can probably spot a straw man a mile off though.
[toc] | [prev] | [next] | [standalone]
| From | foxchip <fox@ultratechnology.com> |
|---|---|
| Date | 2011-04-25 23:25 -0700 |
| Message-ID | <f1429c18-1cf5-45d8-aeb6-4773416664d2@f15g2000pro.googlegroups.com> |
| In reply to | #1524 |
On Apr 25, 1:16 pm, Alex McDonald <b...@rivadpm.com> wrote: > Unless you're a horse. Of course of course. > But then a horse can't pick it's nose. It can > probably spot a straw man a mile off though. I still say it is not considered polite for humans. Horses excepted. Best Wishes
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-04-26 02:47 -0700 |
| Message-ID | <42e8a48a-0304-4ba0-baf3-cc3b34291161@l18g2000yql.googlegroups.com> |
| In reply to | #1534 |
On Apr 26, 7:25 am, foxchip <f...@ultratechnology.com> wrote: > On Apr 25, 1:16 pm, Alex McDonald <b...@rivadpm.com> wrote: > > > Unless you're a horse. > > Of course of course. > > > But then a horse can't pick it's nose. It can > > probably spot a straw man a mile off though. > > I still say it is not considered polite for humans. Horses excepted. > > Best Wishes Human or horse, I still say you've built a straw man out of this PICK discussion.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-04-26 10:22 +0000 |
| Message-ID | <2011Apr26.122251@mips.complang.tuwien.ac.at> |
| In reply to | #1496 |
foxchip <fox@ultratechnology.com> writes:
>I have seen this before. It has some very serious problems.
>
>: pick ?dup if swap >r 1- recurse r> swap else dup then ;
>
>In the context I had showed being able to do this all might
>first require slowing all stack access in Forth by a hundred
>times. Calling five words recursively might make PICK a few
>hundred thousands times slower again than other stack
>operations.
Ok, I tested this with the following program on gforth-fast on a Core
2 Duo:
2 constant n
: bench ( ... -- ... u )
0 300000000 0 ?do n pick + loop ;
4 3 2 1 bench . drop drop drop drop
The resulting cycles per iteration of the loop:
n=2 n=3 n=4
9 9 9 Gforth's PICK
66 89 110 recursive PICK
So on this implementation we see about one magnitude of difference for
the uses of PICK that occur in practice. Even assuming that a
different implementation might be more efficient with its own PICK,
only be doing 3 PICK in less than 1/1000th of a cycle (i.e., less than
0.33333 ps) could the implementation be 100000 times faster than the
recursive one.
Ok, with a big-enough N we can make the recursive PICK arbitrarily
slow, but such big Ns don't occur in practice.
Just for fun I ran the same benchmarks with VFX Forth:
n=2 n=3 n=4
5 5 5 Gforth's PICK
27 36 44 recursive PICK
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2010: http://www.euroforth.org/ef10/
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-04-26 10:45 -0700 |
| Message-ID | <c888da93-7467-4061-9521-00a0bbde2443@v31g2000vbs.googlegroups.com> |
| In reply to | #1549 |
On Apr 26, 11:22 am, an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > foxchip <f...@ultratechnology.com> writes: > >I have seen this before. It has some very serious problems. > > >: pick ?dup if swap >r 1- recurse r> swap else dup then ; > > >In the context I had showed being able to do this all might > >first require slowing all stack access in Forth by a hundred > >times. Calling five words recursively might make PICK a few > >hundred thousands times slower again than other stack > >operations. > > Ok, I tested this with the following program on gforth-fast on a Core > 2 Duo: > > 2 constant n > > : bench ( ... -- ... u ) > 0 300000000 0begin_of_the_skype_highlighting 0 300000000 0 end_of_the_skype_highlighting?do n pick + loop ; > > 4 3 2 1 bench . drop drop drop drop > > The resulting cycles per iteration of the loop: > > n=2 n=3 n=4 > 9 9 9 Gforth's PICK > 66 89 110 recursive PICK > > So on this implementation we see about one magnitude of difference for > the uses of PICK that occur in practice. Even assuming that a > different implementation might be more efficient with its own PICK, > only be doing 3 PICK in less than 1/1000th of a cycle (i.e., less than > 0.33333 ps) could the implementation be 100000 times faster than the > recursive one. Ah, reality impinging on speculation. Painful for some, but educational for others. > > Ok, with a big-enough N we can make the recursive PICK arbitrarily > slow, but such big Ns don't occur in practice. > > Just for fun I ran the same benchmarks with VFX Forth: > > n=2 n=3 n=4 > 5 5 5 Gforth's PICK > 27 36 44 recursive PICK > > - anton > -- > M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html > comp.lang.forth FAQs:http://www.complang.tuwien.ac.at/forth/faq/toc.html > New standard:http://www.forth200x.org/forth200x.html > EuroForth 2010:http://www.euroforth.org/ef10/
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2011-04-26 22:19 +0200 |
| Message-ID | <15161309998436@frunobulax.edu> |
| In reply to | #1549 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes Re: made it to page 4 of gforth tutorial
[..]
> Ok, I tested this with the following program on gforth-fast on a Core 2 Duo:
> 2 constant n
> : bench ( ... -- ... u )
> 0 300000000 0 ?do n pick + loop ;
> 4 3 2 1 bench . drop drop drop drop
> The resulting cycles per iteration of the loop:
> n=2 n=3 n=4
> 9 9 9 Gforth's PICK
> 66 89 110 recursive PICK
[..]
Here's another check.
( Intel Core i7 920, 2.67 GHz [quad] )
( iForth version 4.0.675, generated 18:53:06, January 15, 2011.)
( x86_64 binary, native floating-point, extended precision.)
iForth's PICK
n=2 600000000 0.635 seconds elapsed.
n=3 900000000 0.620 seconds elapsed.
n=4 1200000000 0.616 seconds elapsed.
Parallel PICK
n = 2, 3, 4
600000000 1200000000 900000000
0.660 seconds elapsed.
Redefining pick
Recursive PICK
n=2 600000000 3.133 seconds elapsed.
n=3 900000000 3.997 seconds elapsed.
n=4 1200000000 9.034 seconds elapsed. ok
The Parallel PICK is defined as follows:
: PARBENCH ( -- )
CR ." Parallel PICK"
CR ." n = 2, 3, 4" CR TIMER-RESET
PAR
STARTP 4 3 2 1 bench2 . 4drop ENDP
STARTP 4 3 2 1 bench3 . 4drop ENDP
STARTP 4 3 2 1 bench4 . 4drop ENDP
ENDPAR
CR .ELAPSED ;
Of course the bench2,3,4 words use the native PICK.
-marcel
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2011-04-27 21:05 +0200 |
| Message-ID | <60981408998436@frunobulax.edu> |
| In reply to | #1559 |
mhx@iae.nl (Marcel Hendrix) wrote Re: made it to page 4 of gforth tutorial
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes Re: made it to page 4 of gforth tutorial
[..]
>> Ok, I tested this with the following program on gforth-fast on a Core 2 Duo:
>> 2 constant n
>> : bench ( ... -- ... u )
>> 0 300000000 0 ?do n pick + loop ;
>> 4 3 2 1 bench . drop drop drop drop
>> The resulting cycles per iteration of the loop:
>> n=2 n=3 n=4
>> 9 9 9 Gforth's PICK
>> 66 89 110 recursive PICK
[..]
> Here's another check.
Sorry, Anton stated the results in clock ticks, while I used seconds.
Here is the corrected output:
( Intel Core i7 920, 2.67 GHz [quad] )
( iForth version 4.0.675, generated 18:53:06, January 15, 2011.)
( x86_64 binary, native floating-point, extended precision.)
iForth's PICK
n=2 600000000 6 ticks/call
n=3 900000000 5 ticks/call
n=4 1200000000 5 ticks/call
Parallel PICK
n = 2, 3, 4
900000000 1200000000 600000000
6 ticks/call
Recursive PICK
n=2 600000000 28 ticks/call
n=3 900000000 36 ticks/call
n=4 1200000000 101 ticks/call ok
This almost matches the results for VFX:
> Just for fun I ran the same benchmarks with VFX Forth:
> n=2 n=3 n=4
> 5 5 5 Gforth's PICK
> 27 36 44 recursive PICK
I initially thought VFX had a trick up its sleeve for n=4, but apparently
it's a hardware 32/64 related issue, because here are the 32bit results:
( Intel Core i7 920, 2.67 GHz [quad] )
( iForth version 4.0.400, generated 22:37:16, December 31, 2010. )
( x86_32 binary, native floating-point, extended precision. )
iForth's PICK
n=2 600000000 6 ticks/call
n=3 900000000 5 ticks/call
n=4 1200000000 5 ticks/call
Parallel PICK
n = 2, 3, 4
900000000 1200000000 600000000
6 ticks/call
Recursive PICK
n=2 600000000 27 ticks/call
n=3 900000000 36 ticks/call
n=4 1200000000 46 ticks/call ok
Now iForth and VFX have exactly the same performance.
-marcel
[toc] | [prev] | [next] | [standalone]
| From | foxchip <fox@ultratechnology.com> |
|---|---|
| Date | 2011-04-22 11:44 -0700 |
| Message-ID | <baedf0c7-3bb9-454c-ae97-4e073ade64ce@22g2000prx.googlegroups.com> |
| In reply to | #1423 |
On Apr 22, 9:37 am, Andrew Haley <andre...@littlepinkcloud.invalid> wrote: > What aspect of ANS actually requires stack pointers, though? The only > word I can think of is DEPTH, but I don't think it's very much used in > standard programs. There's certainly nothing in Standard Forth that > requires stacks to be in addressable memory. We have had this discussion many times. DEPTH is indeed where one has to have stack pointers to addressable memory for any practical implementation. Many people usually jump in and say that they need DEPTH to implement .S and some use DEPTH quite a lot and say they could not live without it. It remains a crutch for many crippled programmers. Then there are the abomination words like PICK and ROLL that in order to not be even worse abominations need stack pointers. People often inject into the discussion that they need them to create their stack frames like they do in C. I noticed that there were a number of threads in c.l.f this year alone where people had to have access to the stack pointers to stacks in RAM and that the general agreement was that these various thing were either extremely difficult or just impossible with standard code. This is because the standard requires stack pointers for DEPTH but provides no portable way to deal with them as real programs have to do. Best Wishes
[toc] | [prev] | [next] | [standalone]
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2011-04-22 11:46 -1000 |
| Message-ID | <nuednfSAzYGgaizQnZ2dnUVZ_judnZ2d@supernews.com> |
| In reply to | #1421 |
On 4/22/11 7:28 AM, foxchip wrote: ... > However iTV management wanted portable ANS code for the browser and > email and the network protocols. It was done in ANS which required > conventional stacks in external memory, and the stack pointers > needed by certain ANS words. The ANS code did use about thirty > stack cells in its apps. It also tended to be at least ten times > larger and a hundred times slower than machineForth code. But > management wanted a simple threaded ANS implementation rather > than an optimizing native code compiler with the stacks in > memory using stack pointers as required by ANS design. I'm sorry, but I disagree with the assertion that ANS Forth requires "conventional stacks in external memory" and stack pointers. As others have noted, there are ways to code DEPTH without stack pointers, and I have seen numerous implementations with stacks in on-chip memory. Moreover, PICK and ROLL are CORE EXT words, and hence entirely optional. In the past you've written about iTV's in-house coding standards, which apparently included requiring "a simple threaded ANS implementation" and further encouraged literal translation of C programs to Forth, which can easily explain the excessive size and slow performance you describe. Well-written Forth, particularly with an optimizing compiler, may still be slower than machineForth, but certainly not "a hundred times slower". Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Jan Coombs <jan_2011-02@murray-microft.co.uk> |
|---|---|
| Date | 2011-04-23 08:02 +0100 |
| Message-ID | <0dqdnVurG_cY5C_QnZ2dnUVZ8tOdnZ2d@brightview.co.uk> |
| In reply to | #1440 |
On 22/04/11 22:46, Elizabeth D Rather wrote: > On 4/22/11 7:28 AM, foxchip wrote: > .... >> . . . > I'm sorry, but I disagree with the assertion that ANS Forth > requires "conventional stacks in external memory" and stack > pointers. As others have noted, there are ways to code DEPTH > without stack pointers, and I have seen numerous implementations > with stacks in on-chip memory. Moreover, PICK and ROLL are CORE EXT > words, and hence entirely optional. Agreed, this little recent Novix style example has an instruction that returns the stack pointers: http://www.excamera.com/sphinx/fpga-j1.html Jan Coombs.
[toc] | [prev] | [next] | [standalone]
| From | foxchip <fox@ultratechnology.com> |
|---|---|
| Date | 2011-04-23 23:46 -0700 |
| Message-ID | <c8162640-6720-4417-bbb1-e935c2942a10@r35g2000prj.googlegroups.com> |
| In reply to | #1440 |
On Apr 22, 1:46 pm, Elizabeth D Rather <erat...@forth.com> wrote: > On 4/22/11 7:28 AM, foxchip wrote: > I'm sorry, but I disagree with the assertion that ANS Forth requires > "conventional stacks in external memory" and stack pointers. As others > have noted, there are ways to code DEPTH without stack pointers, In theory yes people can do crazy things in theory. > and I have seen numerous implementations with stacks in on-chip memory. Which no doubt use stack pointers and probably rely on words not in the standard, like SP0 or SP@, to manipulate the pointers. > Moreover, PICK and ROLL are CORE EXT words, and hence entirely optional. One of the things I noticed last year was that there are systems that say they have ANS Core words. I assumed that meant that they had an ANS compliant core but learned it might mean as little as that they have the words "DUP" and "DROP" which are ANS Core words. A standard system that says it offers more than the core, such as offering optional ANS extensions is required to actually offer those ANS extensions aren't they? > In the past you've written about iTV's in-house coding standards, which > apparently included requiring "a simple threaded ANS implementation" and > further encouraged literal translation of C programs to Forth, Yes. Half of that was management wanting "value added" and "portable code" as you like to say. The other half was your FIG President promoting Forth as a scripting language and pasting things in from the Forth Scientific Library. Since no one complained about performance or the wasteful use of 100KB of memory given that we had 4MB it was good enough for the intended use. A few people got upset when I show that one could make much of that code ten times faster in five minutes or a hundred times faster in an hour of work. But it was nothing like the reaction to those explanations being given in c.l.f where certain people went nuts about it for years. I always liked to say that if nothing else it did eventually result in the most dreadful and offensive code in the FSL being replaced with better code. > which can > easily explain the excessive size and slow performance you describe. Exactly! Horrible badly written FSL code got pasted into an ANS threaded code level in an embedded application where it never belonged. As director of software development I was able to get the code improved. It was one of the things Chuck talked about when he talked about how he saw people doing Forth software. The way he politely put it in presentations to SVFIG was that, "They didn't always get it right." He was very happy with the software engineers who would say each week things like, "I added six new functions to the OS or GUI module and removed 5% more of the 2K of code in the process. He was not terribly impressed when people would say things like how they had added 25K more ANS code to their module and were now unable to debug it at all. > Well-written Forth, particularly with an optimizing compiler, may still > be slower than machineForth, but certainly not "a hundred times slower". I had suggested that they use a Forth Inc. native code compiler written to generate machineForth or at least use one of the ANS Forth to machineForth native code compilers that I had already written for them. I would paraphrase what Chuck had said, "Managment didn't always get it right." But I was not one of the founders of iTV and the President and Vice President put in a lot of effort to try to prove Chuck wrong. We saw that same thing at IntellaSys except that iTV only spent ten million trying to prove Chuck wrong and IntellaSys threw an awful lot more money down the tubes trying to do it with a large team of very highly paid and budgeted engineers given the same requirements as the Forth team and told to prove that Chuck was wrong. In the end they just proved that Chuck had been correct in his original estimates and notions of hardware and software design. > Cheers, > Elizabeth Best Wishes
[toc] | [prev] | [next] | [standalone]
| From | foxchip <fox@ultratechnology.com> |
|---|---|
| Date | 2011-04-24 01:32 -0700 |
| Message-ID | <19f767e1-ec92-447a-904c-14acb91f7756@j35g2000prb.googlegroups.com> |
| In reply to | #1440 |
On Apr 22, 1:46 pm, Elizabeth D Rather <erat...@forth.com> wrote: > Well-written Forth, particularly with an optimizing compiler, may still > be slower than machineForth, but certainly not "a hundred times slower". Sigh. (again) You are as wrong as you always were with that denial. I know these facts sent people screaming in denial for years. I know I have shown you the numbers before, over and over again, but I will give you the logic and numbers again and see if you can defend your statement. iTV rejected the idea of using a Forth Inc. optimizing native code ANS compiler because they felt the quote they got for the cost was way out of line. But they also rejected using the F21O native code compiler with minimal modification to raise the size of the stacks to what the portable ANS Forth code in the FSL required. At that time as you may recall you called that FSL code a "shining example" of good Forth. Take a word like DUP. On F21, fifteen years ago, stack operations were 2ns inside of a fetched word. But the sustained speed of fetching a word with 4 opcodes divided by 4 equated to execution times for DUP of 2.5ns from ROM, 4.25ns from SRAM, 10ns from on-page DRAM, 32ns from off-page DRAM, or 60ns from off-chip external ROM or FLASH that iTV used in their Internet appliances because of the time of fetching a word with opcodes in it from memory. The ANS code in the FSL would not work with only a dozen stack cells positions (and without stack pointers there was no practical way to do DEPTH). The important notion there is that to get the stacks big enough to work with the ANS Code library was to move the stacks into DRAM. i21 Internet appliance designs had no on-chip ROM and only had external DRAM. Because the video coprocessor and serial coprocessor were doing off-page DRAM fetches regularly half the CPU memory accesses to DRAM were ~140ns and the other half were ~40ns. Optimized inlined native code for DUP with stacks in memory required loading a word of opcodes, reading memory with the stack pointer (cached in hardware rather than loaded from DRAM each time) or reading a cached on-chip stack register, changing the pointer, and doing a memory write. That required one or two more memory reads since you could do all that in one word or code. So even with a good optimizing native code compiler it still required four or five memory accesses which would take 360ns to 500ns. 360ns is indeed more than a hundred times slower than 2.5ns. 500ns is indeed more than a hundred times slower than 4.25ns. The statement a hundred times slower is actually a little conservative but pretty close. You can simply declare again that this wasn't true and that it was "certainly not a hundred times slower." I have heard that denial before but I have always just shown you the numbers and asked to see what code, what numbers, and what math you are using in defense of your oft repeated yet false claim. It just looks like the same knee-jerk reaction that lots of people had to this and many other details of that old technology. The numbers for c18 on Green Array Chips designs are a little bit different and they would depend on the type of external memory used and the speed of the external memory driver. But then the whole argument is rather moot anyway in that environment because you won't have a stack in external memory for each of 144 processors and get them to work sequentially anywhere as fast as only a hundred times slower than the 144 on-chip stack pairs operating in parallel. Butthat is not what you were denying anyway. Best Wishes
[toc] | [prev] | [next] | [standalone]
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2011-04-24 08:36 -1000 |
| Message-ID | <zuSdnZVXv9s-8CnQnZ2dnUVZ_gidnZ2d@supernews.com> |
| In reply to | #1488 |
On 4/23/11 10:32 PM, foxchip wrote: > On Apr 22, 1:46 pm, Elizabeth D Rather<erat...@forth.com> wrote: >> Well-written Forth, particularly with an optimizing compiler, may still >> be slower than machineForth, but certainly not "a hundred times slower". > > Sigh. (again) You are as wrong as you always were with that denial. > > I know these facts sent people screaming in denial for years. > I know I have shown you the numbers before, over and over again, > but I will give you the logic and numbers again and see if you > can defend your statement. > > iTV rejected the idea of using a Forth Inc. optimizing native code > ANS compiler because they felt the quote they got for the cost was > way out of line. But they also rejected using the F21O native code > compiler with minimal modification to raise the size of the stacks > to what the portable ANS Forth code in the FSL required. At that > time as you may recall you called that FSL code a "shining > example" of good Forth. FSL is a "shining example" of the kind of library project that the Forth community could/should mount. That said, there's a lot of pretty poor code in it (or was, the last time I looked, which was quite a few years ago). I do not recall having said anything admiring about the actual code. In any case, iTV's decisions are its own, and can hardly be blamed on ANS Forth. > Take a word like DUP. On F21, fifteen years ago, stack operations > were 2ns inside of a fetched word. But the sustained speed of > fetching a word with 4 opcodes divided by 4 equated to execution > times for DUP of 2.5ns from ROM, 4.25ns from SRAM, 10ns from > on-page DRAM, 32ns from off-page DRAM, or 60ns from off-chip > external ROM or FLASH that iTV used in their Internet appliances > because of the time of fetching a word with opcodes in it from > memory. > > The ANS code in the FSL would not work with only a dozen stack > cells positions (and without stack pointers there was no practical > way to do DEPTH). The important notion there is that to get the > stacks big enough to work with the ANS Code library was to move > the stacks into DRAM. Sounds like the problem is with the FSL code itself, not its conformance to ANS Forth. Without looking at the code to see what took so much stack space, I couldn't do more than guess, but can imagine some possibile causes, such as trying to maintain floats on an integrated stack instead of a separate stack, in which case a possible solution might have been to put floats in DRAM and leave the other stacks on board. ... > 360ns is indeed more than a hundred times slower than > 2.5ns. 500ns is indeed more than a hundred times slower > than 4.25ns. The statement a hundred times slower is > actually a little conservative but pretty close. > > You can simply declare again that this wasn't true and > that it was "certainly not a hundred times slower." Ok, putting stacks in DRAM is 100 times slower than having them on-chip. That's not the same thing as saying that ANS Forth is necessarily 100 times slower than native code. You've identified problems with FSL code and iTV decisions; put the responsibility for slow code where it belongs. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | foxchip <fox@ultratechnology.com> |
|---|---|
| Date | 2011-04-24 19:43 -0700 |
| Message-ID | <bc73f495-63df-4eb2-8d59-20fa271b0360@a21g2000prj.googlegroups.com> |
| In reply to | #1490 |
On Apr 24, 10:36 am, Elizabeth D Rather <erat...@forth.com> wrote: We have had this argument many times. I got so tired of giving you the facts over and over and your coming back saying it was "certainly" untrue and then changing the subject that I posted a web page a decade ago reviewing in detail some of the actual offensive code from the FSL as you appeared to forget the details year after year. I thought it might be educational for other people promoting this code but denying that they knew any of the details. > Sounds like the problem is with the FSL code itself, not its > conformance to ANS Forth. Without looking at the code to > see what took so much stack space, I couldn't do more than > guess, but can imagine some possibile causes, such as trying > to maintain floats on an integrated stack instead of a > separate stack, in which case a possible solution > might have been to put floats in DRAM and leave the > other stacks on board. I know you have a selective memory problem but I doubt if the smoke screen about how the problem might have been related to some ridiculous made-up guesses when we I have reviewed the facts and actual code examples so many times in c.l.f and posted web pages about it. So let's review again. The subject of code to access fields in structures often comes up in c.l.f and the usual response from supporters of using C-style structures in Forth is that in theory, in theory mind you, all that is actually needed is base-plus-offset calculation and that all that is needed to make it reasonable efficient in support of C-style is a base-plus-offset form of memory addressing in the hardware. But the real code in the FSL to this was some of the worst ANS Forth code I had ever seen. It made gavino's Forth code look very good yet it was being promoted by quite a few c.l.f posters especially you. People like to say that all that is needed for C-style structures in Forth is a base-plus-offset addressing mode but that was not the issue here or problem with the code. To aid your failing memory and refusal to read actual accounts of what was wrong with the code you were promoting let me review it again. C-sytle structure field access in the FSL was not just a base-plus-offset calculation. It was several lines of code that ended with two print statements for diagnostic purposes. The actual library code was easily 100x bigger than just a base-plus-offset calculation. It wasn't a floating point issue. It wasn't single or mixed floating point stack issue. Those were absurd guesses unless you think you need floating point math to do Internet protocols. When the code got pasted in to an embedded application the several lines of structure field access code below all the network protocol code did have the two print statements at the end removed. This made it only about another 10x on top of the 100x issue for this environment. But that was all that had been done. In a staff meeting and code review soon after, and again several times in c.l.f, and later on a web page about C-style structures in Forth, I reviewed the actual code. When the two print statements were removed they were replaced by 2DROP as if an optimizing compiler was going to turn the rest of the ugly remaining code into good code. Since the two arguments were eventually removed by a 2DROP at the end the arguments were still carried throughout the entire definition in a wonderful example of stack-juggling. In addition to the extra weight of an unneeded 2DROP there were OVERs, DUPs, and 2DUPs, throughout the word to carry the garbage to the end of the definition. So in our staff meeting and code review, in c.l.f, and on a web page I questioned why all that unnecessary stack-juggling had not been removed from the code in the first place. It was code I would have thought would be an easy exercise for a second-day Forth programmer to fix. It only took a couple of minutes to make it five times faster or so by removing the garbage. It made me wonder which optimizing native code Forth compilers remove all the stack-juggling code over several lines of previously compiled code when they encounter that sort of poor quality Forth source code. In the code review I showed that in many cases all that had really been needed was to use one five-bit opcode in machineForth with no size or speed penalty instead of another instead of pasting from a library and getting the 100x x 10x or 1000x example was the sort of thing that Chuck politely said was an example of "not getting it right." > > You can simply declare again that this wasn't true and > > that it was "certainly not a hundred times slower." It is silly of you to assert that it would not be true in a completely different content that the one at hand. > Ok, putting stacks in DRAM is 100 times slower than having > them on-chip. That's not the same thing as saying that ANS > Forth is necessarily 100 times slower than native code. It "certainly" was as true in the context of the statements that were made. You can try to change the subject to how the statements made would not be true in a completely different imaginary context than the one given but that is just avoiding trying to defend your original statement. > You've identified problems with FSL code and iTV decisions; > put the responsibility for slow code where it belongs. Both iTV and I should take responsibility for a number of things and "not getting them right." We had this argument just a few months ago and you response was that it was so long ago you had hoped people would have forgotten all about it like you had. I recommended that they use a Forth Inc. optimizing native code compiler, not because we didn't have a dozen different people in house, including Chuck Moore who could write one. I made that recommendation because I was in agreement with them that there would be perceived "value added" if they could point to ANS compliance for people who were worried about portability and show that Forth Inc. offered a product tuned for the job. I know what cost they told me they had been quoted. I know that you have denied that that was the cost that you quoted. So I don't know if their decision not to go that way was as bad as their decision to also not use an already written and demonstrated native code optimizing compiler converting ANS to machineForth that was free. I and iTV should admit that it was our mistake to use a "professional Forth compiler" that we purchased from Forth Inc. for the project. I freely admit that I made an error that I learned from on that one. I had believed what you told us, that it was professional quality, that it had professional documentation, and that it would have professional support. I eventually learned that these were simply untrue marketing claims. The $4000 per copy that we spent on that tool was a big waste but little did we know that it would be about the buggiest Forth any of us had ever seen. We did not know that the huge boxes were because of silly useless machine generated documentation that only detailed such things as what DUP does and what its stack diagram looks like. There was no documentation about how any of the important Windows interface code worked or didn't work in so many cases. But the worst problem was that your marketing claim of it including "professional support" actually meant it included zero support. As you no doubt recall since we have this argument every couple of years was that you said that MPE needed to provide the support because they wrote it. MPE said Forth Inc. needed to provide support because they sold it. We said that "someone" needed to provide support because we bought it based your claims of "professional support." You have acknowledged these facts in the past also. Your comment was that, "It was a most unfortunate situation for everyone." That wasn't exactly the way I saw it since we were the ones who got burned and Forth Inc. were the ones to walk away with over $40,000.00 of our money and then abandon us. It was an important lesson in my career. The last time this subject came up last year your response was people should forget it because it was long in the past. We got sold a pig in a poke and you hoped we would forget about it and not tell anyone I guess. You may say that it was iTV's fault that we believed your claims and ended up being sold a pig-in-a-poke instead of professional quality code, professional quality documentation, and any support at all let alone professional quality support. That's one way to see it I guess. I do admit it was a mistake to have believed your claims at that time. Later we found that we could avoid the five minute compiles using your "professional quality" product and could do the same thing without all the bugs and bug work arounds using gforth and get fifteen second compiles, twenty times faster compiles, with free software. More than ten years later we were surprised again at IntellaSys that the VentureForth compiler and simulator for SEAforth chips ran faster under gforth-fast than under SwiftForth. What still puzzles me is that you don't seem to like the story of our mistakes of believing you, purchasing Forth products for $4000 per desk, and getting zero support but for some reason you bring up the subject every year or two. You can't deny the actual facts but you say you forget them and hope other people did too. Yet every couple of years you bring the whole thing up again with comments such that the performance numbers in that context were "certainly" not true. Then we go over again how you think it was iTV's mistake to have believed your claims which proved so untrue and such an expensive error for our company. You have never been willing to admit that the worst parts of the problem was actually your responsibility. And I always end up agreeing with you that both I and iTV managment made a terrible mistake back then by thinking your marketing claims about what you were selling were true. I just don't get why you want to bring up the $4000 per copy for buggy, undocumented, and completely unsupported "professional Forth" mistake we made back then by believing your claims. > Cheers, > Elizabeth Best Wishes
[toc] | [prev] | [next] | [standalone]
| From | foxchip <fox@ultratechnology.com> |
|---|---|
| Date | 2011-04-24 21:07 -0700 |
| Message-ID | <676a140d-4d30-4d84-9566-5d819056c653@u38g2000prd.googlegroups.com> |
| In reply to | #1490 |
On Apr 24, 10:36 am, Elizabeth D Rather <erat...@forth.com> wrote: > FSL is a "shining example" of the kind of library project that the Forth > community could/should mount. Could/should perhaps. Back to the real world. My original comment was that all things that shine do not smell good and that this was a good example of something that stank badly. When I was a kid there was a phrase saying that some things "shined like shit on shineola." But I don't think most people today know what shineola was but they probably still get a sense of what that statement meant. > That said, there's a lot of pretty poor code in it > (or was, the last time I looked, which was quite a few years > ago). I do not recall having said anything admiring about the > actual code. The code I commented on in the nineties was replaced long ago by something far more reasonable. But I have not looked at most of the code and I saw mostly floating point stuff anyway. We didn't use any floating point, just the C-style structures and enumerations. > In any case, iTV's decisions are its own, and can hardly be blamed on > ANS Forth. The context was giving some blame to the FSL code, some to the President of FIG, some to me, some to iTV management, and lots to you for tools, standards, and very bad advice. Best Wishes
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2011-04-25 11:04 +0000 |
| Message-ID | <lk7g2u.kzt@spenarnc.xs4all.nl> |
| In reply to | #1490 |
In article <zuSdnZVXv9s-8CnQnZ2dnUVZ_gidnZ2d@supernews.com>, Elizabeth D Rather <erather@forth.com> wrote: >On 4/23/11 10:32 PM, foxchip wrote: <SNIP> >> >> The ANS code in the FSL would not work with only a dozen stack >> cells positions (and without stack pointers there was no practical >> way to do DEPTH). The important notion there is that to get the >> stacks big enough to work with the ANS Code library was to move >> the stacks into DRAM. > >Sounds like the problem is with the FSL code itself, not its conformance >to ANS Forth. Without looking at the code to see what took so much >stack space, I couldn't do more than guess, but can imagine some >possibile causes, such as trying to maintain floats on an integrated >stack instead of a separate stack, in which case a possible solution >might have been to put floats in DRAM and leave the other stacks on board. We should not so easily accept that as a problem, merely because Jeff Fox claims it is. A lot of FSL is scientific code that makes no sense to run on a resource starved system. If someone decides to use hundreds of stack positions because they are available anyway and make the code better, good for them. Examples: I have recursive solutions for Euler problems that don't run on Python, but do run on Forth because of the large stack. An other example is an implementation of WORD that reverse the order of words are printed, by temporarily putting them on the stack. <SNIP> > >Cheers, >Elizabeth 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]
| From | foxchip <fox@ultratechnology.com> |
|---|---|
| Date | 2011-04-25 23:02 -0700 |
| Message-ID | <4b3b25d1-dcc1-40db-ae03-4cc51b42106f@v11g2000prb.googlegroups.com> |
| In reply to | #1506 |
On Apr 25, 3:04 am, Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote: > We should not so easily accept that as a problem, merely > because Jeff Fox claims it is. A lot of FSL is scientific code > that makes no sense to run on a resource starved system. > If someone decides to use hundreds of stack positions because > they are available anyway and make the code better, good for them. Sure it takes all types. Forth is a public domain term. People who say their goal is to write a bigger Forth than anyone else ever has are free to call what they do Forth. People who just solve the same problems over and over, problems that may have been solved hundreds of years ago by others, are free to call what they do Forth. People who paste someone else's C code into their buggy C programs so they can fetch, store, and dump to debug their C programs are free to say that that is all there is to Forth. It takes all kinds. Best Wishes
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2011-04-20 18:17 -0700 |
| Message-ID | <824e2c4d-d1c5-44cd-b178-7e1b51a04104@dr5g2000vbb.googlegroups.com> |
| In reply to | #1341 |
On Apr 20, 2:40 am, "The Beez'" <hans...@bigfoot.com> wrote: > On 19 apr, 22:09, m...@iae.nl (Marcel Hendrix) wrote:> David Kuehling <dvdkh...@gmx.de> writes Re: made it to page 4 of gforth tutorial > > Apart from any specific Forth implementation, I like Alberts solution > best, since it uses the return-stack as a sort of "local variable". On a two-stack stack machine, that has the benefit of no stack juggling. Or if >>R, aka DUP>R is a primitive operation on that machine, then : solution ( n -- n^3 n^4 ) >>R R@ * R@ * DUP R> * ; 17 solution . .
[toc] | [prev] | [next] | [standalone]
Page 8 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