Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #27495 > unrolled thread
| Started by | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| First post | 2013-12-28 23:39 -0800 |
| Last post | 2014-01-03 14:52 +0000 |
| Articles | 20 on this page of 330 — 25 participants |
Back to article view | Back to comp.lang.forth
PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2013-12-28 23:39 -0800
Re: PICK changed from 1-based to 0-based? Elizabeth D Rather <erather@forth.com> - 2013-12-28 21:52 -1000
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2013-12-29 11:28 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2013-12-29 23:12 +1100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-29 07:45 -0600
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2013-12-29 18:33 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-29 16:57 -0600
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2013-12-30 00:25 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-01 13:29 +1100
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-01 14:18 +0000
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2014-01-01 15:46 +0100
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2014-01-01 15:26 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-03 13:22 +1100
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2014-01-03 11:54 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-06 10:57 +1100
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-03 14:07 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-06 12:42 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 14:22 +0000
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-03 09:06 -0800
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 11:10 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-04 11:49 +0000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-05 13:14 +1100
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-04 16:35 -1000
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-05 11:35 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-05 06:15 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-05 15:11 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-05 10:07 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-05 21:14 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-06 04:44 -0600
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-06 12:42 +1100
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-06 21:51 +0100
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-06 22:41 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-07 03:29 +0100
Re: PICK changed from 1-based to 0-based? Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2014-01-07 11:48 +0100
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-07 12:58 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-07 15:13 +0100
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-07 10:22 -0800
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-08 02:20 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-07 14:13 +0000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-09 23:19 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-10 17:19 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-10 09:02 -1000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-13 13:28 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-14 09:05 +0000
Re: PICK changed from 1-based to 0-based? mhx@iae.nl - 2014-01-14 04:05 -0800
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-14 12:36 +0000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-15 11:37 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-13 17:07 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-11 01:40 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-13 11:21 +1100
Re: PICK changed from 1-based to 0-based? Coos Haak <chforth@hccnet.nl> - 2014-01-13 01:50 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-13 12:05 +1100
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-13 03:19 +0100
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-13 03:36 +0100
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-12 19:22 -0800
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-11 17:09 +1100
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-02 17:06 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-02 08:13 -1000
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-02 18:59 +0000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 12:54 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 07:19 -0600
Re: PICK changed from 1-based to 0-based? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-29 22:32 -0500
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 16:46 +0000
Re: PICK changed from 1-based to 0-based? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-30 18:37 -0500
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2013-12-31 11:53 +0100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 17:21 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 12:03 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 18:09 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 12:43 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-02 16:52 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-02 08:32 -1000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-05 13:26 +1100
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-04 16:55 -1000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-07 12:45 +1100
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-06 22:15 -1000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-15 08:39 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-05 12:53 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-02 13:45 -0600
Re: PICK changed from 1-based to 0-based? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-02 20:17 -0500
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 04:03 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 13:43 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 11:53 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-01 23:57 +0100
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-01 13:19 -1000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-02 19:48 +0100
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-02 19:13 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-02 15:44 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-02 23:56 +0100
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-02 15:43 -0800
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-02 15:34 -1000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 04:14 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-03 17:49 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 12:03 -0600
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-03 10:31 -0800
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-03 19:19 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-03 09:56 -1000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-04 04:18 -0600
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-04 12:39 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-03 21:43 +0100
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-03 13:45 -0800
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-03 23:10 +0100
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-03 15:41 -0800
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-10 22:05 -0800
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-04 04:21 -0600
Re: PICK changed from 1-based to 0-based? oh2aun@gmail.com - 2014-01-10 06:46 -0800
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-07 13:33 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-07 08:44 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-08 14:52 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-08 08:41 -1000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 08:14 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-07 18:41 +0100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-08 15:09 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-08 20:00 +0100
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-08 12:45 -1000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-09 00:16 +0100
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-10 22:34 -0800
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-10 22:41 -0800
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-10 23:12 -0800
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-10 23:04 -0800
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-10 22:08 -1000
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-09 02:16 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 04:18 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 11:19 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 09:04 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-10 17:27 +0000
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-10 11:37 -0800
Re: PICK changed from 1-based to 0-based? oh2aun@gmail.com - 2014-01-10 12:47 -0800
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-10 13:37 -0800
Re: PICK changed from 1-based to 0-based? oh2aun@gmail.com - 2014-01-10 14:24 -0800
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-13 16:53 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-09 14:50 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 09:08 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-09 18:33 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 12:32 -0600
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-09 20:49 +0000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 09:10 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-09 14:37 +0100
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-07 08:48 -1000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-08 15:24 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-08 08:50 -1000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 08:28 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-08 16:21 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 09:39 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 04:28 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 11:27 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-09 14:42 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 09:41 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-09 18:44 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 12:35 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-10 00:20 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-10 05:22 -0600
Re: PICK changed from 1-based to 0-based? m.a.m.hendrix@tue.nl - 2014-01-10 03:48 -0800
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-10 09:31 -0600
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-09 09:40 -0600
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-10 21:54 -0800
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-11 03:41 -0600
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-11 13:33 +0000
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-11 11:44 -0800
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-11 10:40 -1000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-11 04:11 -0600
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-11 13:31 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-11 07:52 -0600
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-11 19:35 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-12 02:57 -0600
chipFORTH [Was: PICK changed from 1-based to 0-based?] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-12 03:12 -0600
Re: chipFORTH Paul Rubin <no.email@nospam.invalid> - 2014-01-12 08:43 -0800
Re: chipFORTH Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-12 10:40 -0600
Re: chipFORTH albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-12 18:00 +0000
Re: chipFORTH Alex McDonald <blog@rivadpm.com> - 2014-01-12 11:18 -0800
Re: chipFORTH anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-13 16:03 +0000
Re: chipFORTH "Alex McDonald" <blog@rivadpm.com> - 2014-01-13 17:21 +0000
Re: chipFORTH stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-13 19:10 +0000
Re: chipFORTH [Was: PICK changed from 1-based to 0-based?] "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-13 02:28 -0500
Re: chipFORTH [Was: PICK changed from 1-based to 0-based?] Elizabeth D Rather <erather@forth.com> - 2014-01-12 21:39 -1000
Re: chipFORTH [Was: PICK changed from 1-based to 0-based?] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-13 03:16 -0600
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-12 11:38 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-12 07:46 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-13 15:46 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-13 10:45 -0600
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-13 19:05 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-13 20:53 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-14 03:41 -0600
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-14 13:07 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-14 17:53 +0100
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-14 17:35 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-14 08:23 -1000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-14 13:19 -0600
Re: PICK changed from 1-based to 0-based? oh2aun@gmail.com - 2014-01-14 12:31 -0800
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-14 21:37 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-14 16:12 -0600
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-14 12:18 -1000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-15 04:19 +0100
DOES> and flash (was: PICK changed from 1-based to 0-based?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-15 17:52 +0000
Re: DOES> and flash (was: PICK changed from 1-based to 0-based?) stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-15 21:56 +0000
Re: DOES> and flash (was: PICK changed from 1-based to 0-based?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-16 09:30 +0000
Re: DOES> and flash Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-01-17 12:44 +0100
Re: DOES> and flash oh2aun@gmail.com - 2014-01-17 08:05 -0800
Re: DOES> and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-17 16:43 +0000
Re: DOES> and flash Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-17 20:37 +0100
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-18 04:40 -0600
Re: DOES> and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-18 11:56 +0000
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-18 10:54 -0600
Re: DOES> and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-18 17:36 +0000
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-18 12:17 -0600
Re: DOES> and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-18 18:23 +0000
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-18 14:00 -0600
Re: DOES> and flash Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-18 20:24 +0100
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-18 14:05 -0600
Re: DOES> and flash Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-18 23:12 +0100
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-19 03:38 -0600
Re: DOES> and flash Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-19 14:03 +0100
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-19 09:17 -0600
Re: DOES> and flash albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-19 15:31 +0000
Re: DOES> and flash Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-19 19:48 +0100
Re: DOES> and flash Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-18 18:11 +0100
Re: DOES> and flash Coos Haak <chforth@hccnet.nl> - 2014-01-19 01:12 +0100
Re: DOES> and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-19 21:53 +0000
Re: DOES> and flash Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-01-20 11:32 +0100
Re: DOES> and flash (was: PICK changed from 1-based to 0-based?) Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-16 02:02 +0100
Re: DOES> and flash Lars Brinkhoff <lars.spam@nocrew.org> - 2014-01-16 07:19 +0100
Re: DOES> and flash Paul Rubin <no.email@nospam.invalid> - 2014-01-16 00:22 -0800
Re: DOES> and flash Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-16 15:38 +0100
Re: DOES> and flash Lars Brinkhoff <lars.spam@nocrew.org> - 2014-01-20 09:45 +0100
Re: DOES> and flash (was: PICK changed from 1-based to 0-based?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-16 09:33 +0000
Re: DOES> and flash (was: PICK changed from 1-based to 0-based?) Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-16 16:09 +0100
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-17 03:28 -0600
Re: DOES> and flash albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-17 11:39 +0000
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-17 08:16 -0600
Re: DOES> and flash "Alex McDonald" <blog@rivadpm.com> - 2014-01-17 16:06 +0000
Re: DOES> and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-18 17:21 +0000
Re: DOES> and flash stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-19 12:32 +0000
Re: DOES> and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-19 09:19 -0600
Re: DOES> and flash stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-19 18:20 +0000
Re: DOES> and flash Paul Rubin <no.email@nospam.invalid> - 2014-01-20 01:25 -0800
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-14 08:31 +0000
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-14 01:33 -0800
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-14 10:05 +0000
CREATE...DOES> on program-in-flash systems anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-14 11:58 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-11 08:43 -1000
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-11 19:37 +0000
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-11 11:28 -0800
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-11 12:24 -0800
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-03 18:19 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-03 22:03 +0100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 13:28 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-03 15:09 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-02 03:41 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-02 18:09 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 04:16 -0600
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-02 22:58 +0100
Re: PICK changed from 1-based to 0-based? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-29 22:34 -0500
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2013-12-29 19:30 -1000
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2013-12-29 22:49 -0800
Re: PICK changed from 1-based to 0-based? AKK <akk@nospam.org> - 2013-12-30 08:48 +0100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 16:24 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 11:18 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 17:32 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 12:05 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-02 11:02 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-02 05:48 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 11:00 +0000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2013-12-31 21:42 +1100
Re: PICK changed from 1-based to 0-based? Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-12-30 09:14 +0100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 03:35 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 16:06 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 10:41 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-30 17:50 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 12:21 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-02 11:21 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-02 07:08 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 11:13 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 07:36 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 15:23 +0000
Re: PICK changed from 1-based to 0-based? Tristan Plumb <firth@trstn.net> - 2014-01-03 16:02 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-03 08:54 -1000
Re: PICK changed from 1-based to 0-based? Tristan Plumb <firth@trstn.net> - 2014-01-03 19:59 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-03 10:12 -1000
Re: PICK changed from 1-based to 0-based? Tristan Plumb <st@trstn.net> - 2014-01-03 20:17 +0000
Re: PICK changed from 1-based to 0-based? Tristan Plumb <firth@trstn.net> - 2014-01-03 20:29 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-03 11:48 -1000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-04 12:00 +0000
Re: PICK changed from 1-based to 0-based? Tristan Plumb <firth@trstn.net> - 2014-01-04 13:12 +0000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-04 08:22 -0600
Re: PICK changed from 1-based to 0-based? visualforth@rocketmail.com - 2014-01-10 21:37 -0800
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-02 16:58 +0100
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-02 16:41 +0000
Re: PICK changed from 1-based to 0-based? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-02 16:54 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-02 23:22 +0100
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-02 23:20 +0100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 11:56 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2013-12-30 08:14 -1000
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-30 12:54 -0600
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2013-12-31 23:15 +1100
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-12-31 07:05 -0600
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2013-12-31 09:26 -1000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-01 13:27 +1100
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2013-12-31 18:21 -1000
Re: PICK changed from 1-based to 0-based? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-01 12:12 +0000
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-03 15:59 +1100
Re: PICK changed from 1-based to 0-based? mhx@iae.nl - 2014-01-03 00:19 -0800
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-05 13:25 +1100
Re: PICK changed from 1-based to 0-based? mhx@iae.nl - 2014-01-04 19:03 -0800
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-06 14:08 +1100
Re: PICK changed from 1-based to 0-based? m.a.m.hendrix@tue.nl - 2014-01-06 01:47 -0800
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-07 12:43 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-08 13:29 +0000
Re: PICK changed from 1-based to 0-based? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-08 16:30 +0100
Re: PICK changed from 1-based to 0-based? "Ed" <invalid@invalid.com> - 2014-01-11 23:12 +1100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 14:30 +0000
Re: PICK changed from 1-based to 0-based? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-01-04 13:57 -0800
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-04 12:17 -1000
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-04 15:08 -0800
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-05 04:57 -0600
Re: PICK changed from 1-based to 0-based? Paul Rubin <no.email@nospam.invalid> - 2014-01-05 09:14 -0800
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-05 12:20 -0600
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-08 13:05 +0000
Re: PICK changed from 1-based to 0-based? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-08 08:55 -1000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-09 08:49 +0000
Re: PICK changed from 1-based to 0-based? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-19 11:24 -0500
Re: PICK changed from 1-based to 0-based? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-01-04 16:06 -0800
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-07 13:47 +0000
Re: PICK changed from 1-based to 0-based? Tristan Plumb <firth@trstn.net> - 2013-12-30 18:29 +0000
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-02 09:34 +0000
Re: PICK changed from 1-based to 0-based? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-02 20:06 -0500
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2014-01-03 11:34 +0100
Re: PICK changed from 1-based to 0-based? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-03 08:04 -0500
Re: PICK changed from 1-based to 0-based? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-03 07:38 -0600
Re: PICK changed from 1-based to 0-based? Hans Bezemer <the.beez.speaks@gmail.com> - 2014-01-03 15:57 +0100
Re: PICK changed from 1-based to 0-based? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-03 14:17 +0000
Re: PICK changed from 1-based to 0-based? Tristan Plumb <firth@trstn.net> - 2014-01-03 14:52 +0000
Page 5 of 17 — ← Prev page 1 … 3 4 [5] 6 7 … 17 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-03 13:43 +0000 |
| Message-ID | <2014Jan3.144354@mips.complang.tuwien.ac.at> |
| In reply to | #27603 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>> In contrast, the changes from Forth-79 to Forth-83 broke existing
>>>> code. Code that used, e.g., C@ NOT that worked on Forth-79 did not
>>>> work on any Forth-83 compliant system, and no Forth-83 compliant
>>>> system can be written to make such Forth-79 compliant code work.
>>>
>>>Sure, but as I have already explained, Forth code at the time was so
>>>vendor-specific that it was going to have to be changed anyway, and
>>>people didn't much port code between Forths, so it didn't really
>>>matter.
>>
>> If they did not port code, why have a standard?
>
>Because it was thought that portability, both of programmers and
>programs, might be useful.
So it did matter.
>> When you introduce a standard (for the whole language, or for one
>> particular feature set, like locals in Forth-94), you always have
>> the situation that the code is vendor-specific. And a lot of people
>> don't port their code between language implementations most of the
>> time, so for them standardization does not matter most of the time.
>> It's only when they want to or have to change implementations that
>> they notice.
>
>If their vendor doesn't make incompatrible changes to their Forth,
>they'll be fine, but in the end, if the standard succeeds, everyone
>will move to it, and everyone will have to make changes to their code.
Sure, but a well-designed standard like Forth-94 makes it possible to
have a smooth transition, whereas in a botched standard like Forth-83
the transition was so disruptive that a significant number of systems
and programs did not make it and stuck with Forth-79.
>>>Not really, no. There's no real evidence that it did any damage.
>>
>> Knowing you, whatever evidence I present, you will always claim it's
>> not real, so I won't invest any time in this futile exercise.
>
>Oh dear, this is my punishment for failing to agree with you. I'm not
>at all sure that it's even possible to show such a thing, let alone
>real evidence.
So my expectations are right. And that's not a punishment, it's just
experience with the way you argue.
>You'd have to run history again. I do not believe
>that anyone cared enough about Forth-79 for it really to matter.
A number of people cared enough about Forth-79 to stick with it, so it
did matter.
>>>"Obviously?" IIRC Forth-83 was widely used, although there remained a
>>>vocal minority who didn't accept it. There still is for every Forth
>>>standard.
>>
>> There was a vocal minority who did not accept Forth-94 and stuck with
>> Forth-83? Who?
>
>No-one AFAIAA. However, there is a vocal minority who didn't accept
>ANS.
Sure, there are people who don't like any standard.
But the Forth-79 implementors and users are not among those. And yet
a number of them chose to stick with Forth-79 instead of transitioning
to Forth-83, producing the Forth-79 holdouts that Elizabeth Rather
mentioned. In contrast, the smoother transition that Forth-94 offered
did not produce any Forth-83 holdouts.
>> Going forward, vendors had incompatible dialects for locals by the
>> time the Forth-94 comittee was at work. Following your argument, they
>> would have been allowed to change all parts of the language
>> incompatibly.
>
>No, because post-ANS, everything changed. There was now a standard
>worth having, and was worth keeping compatibility with. It was not so
>in 1983.
Forth-79 was a standard worth keeping compatibility with, certainly
for PICK, ROLL, and the comparison words.
- 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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-03 11:53 -0600 |
| Message-ID | <2NGdnVV_d8quZFvPnZ2dnUVZ_sSdnZ2d@supernews.com> |
| In reply to | #27636 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Not really, no. There's no real evidence that it did any damage. >>> >>> Knowing you, whatever evidence I present, you will always claim it's >>> not real, so I won't invest any time in this futile exercise. >> >>Oh dear, this is my punishment for failing to agree with you. I'm not >>at all sure that it's even possible to show such a thing, let alone >>real evidence. > > So my expectations are right. Not really, no. It seems to me that you are saying that you might have evidence for something that, IMO, it may not be possible for anyone to have evidence for. In addition, you say you are going to withold such evidence because I would claim it's not real. I think that some skepticism is justfied. We have our opinions; they differ. That is all. >>> Going forward, vendors had incompatible dialects for locals by the >>> time the Forth-94 comittee was at work. Following your argument, they >>> would have been allowed to change all parts of the language >>> incompatibly. >> >>No, because post-ANS, everything changed. There was now a standard >>worth having, and was worth keeping compatibility with. It was not so >>in 1983. > > Forth-79 was a standard worth keeping compatibility with, certainly > for PICK, ROLL, and the comparison words. The situation with Forth-79 holdouts after Forth-83 was not ideal. I accept that. However, I don't believe it did any great lasting damage and that it did lead to the first standard worthy of the name, ANS Forth. Would it have been possible to get there by some other, less painful route? Given the personalities involved, maybe, maybe not. In hindsight, the ANS path to standardization was exactly what was needed. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-01-01 23:57 +0100 |
| Message-ID | <la26g8$iev$1@online.de> |
| In reply to | #27540 |
Andrew Haley wrote:
> Surely we've been over this many times before. The 83-standard
> DO..LOOP is hard to describe and hard to understand, and has hideously
> bad behaviour with 0 0 DO. It was only accepted because at the time
> it was easily implemented with a neat trick involving the overflow
> flag, and it worked equally well for signed and unsigned loops. That
> neat trick often doesn't help make things faster if a loop uses I
> once, and if it uses I more than once it's actually a disadvantage.
> The DO..LOOP used by Forth, Inc was much cleaner, and there were two
> versions, one for signed and one for unsigned loops. It didn't have
> the pathological behaviour of the 83-standard loop.
Several things in the '83 standard apparently were "trick"-driven. E.g.
replacing <BUILDS with CREATE: previously, it was considered too difficult
to implement DOES> with a code-doers header, which is why <BUILDS is there.
Now the trick which was suggested during the Forth-83 discussions is not
possible everywhere, so the two-cells header returned rather quickly. To be
compatible with all Forths from '83 on, you then either need a wasted spare
second cell in the header (Gforth) or you need to implement that trick (many
others), even if it is difficult to do.
Or, as some people did it, just go back to <BUILDS and be incompatible.
'83 made some particular ("new") choices for implementation, which aren't
trick-related but useful. Using floored division is such an example; though
actually dividing by a negative number rarely happens - floored by unsigned
would IMHO have been the better choice.
The -1 true flag also is quite useful. I remember Andy Glew writing that he
proposed such a setcc instruction at Intel, and in SSE it finally got in.
It is more useful than the 1 true flag.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-01-01 13:19 -1000 |
| Message-ID | <UvqdnUtPsdECP1nPnZ2dnUVZ_jCdnZ2d@supernews.com> |
| In reply to | #27580 |
On 1/1/14 12:57 PM, Bernd Paysan wrote: ... > Several things in the '83 standard apparently were "trick"-driven. E.g. > replacing <BUILDS with CREATE: previously, it was considered too difficult > to implement DOES> with a code-doers header, which is why <BUILDS is there. > > Now the trick which was suggested during the Forth-83 discussions is not > possible everywhere, so the two-cells header returned rather quickly. To be > compatible with all Forths from '83 on, you then either need a wasted spare > second cell in the header (Gforth) or you need to implement that trick (many > others), even if it is difficult to do. ... What's the difference between a "trick" and a technique? And when is it impossible? We haven't found it to be so, on an incredibly wide number of platforms. 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-01-02 19:48 +0100 |
| Message-ID | <la4c9j$2hk$1@online.de> |
| In reply to | #27581 |
Elizabeth D. Rather wrote: > What's the difference between a "trick" and a technique? And when is it > impossible? We haven't found it to be so, on an incredibly wide number > of platforms. The DOES> implementation requires to have a jump into code at the start of the DOES> half of the code. This means that this part must be executable code; while the rest of the stuff there is traditionally threaded code, which is actually data for the processor. This is not possible on processors which have a very strict separation of code and data (which otherwise are 100% fine for indirect threaded code, as code and data are otherwise completely separable). And this is also not possible if you want to have a 100% portable implementation which just can't create that assembler jump. Furthermore, there's a third problem: You can't do that jump if the code and data is too far away, e.g. on amd64, jumps can only cross 32 bits, and data is typically very far away, see this example: hex ok ' noop . 7F3E194DB0D8 ok ' noop @ . 405048 ok You simply can't jump from the data (image) into the code on amd64, so the Forth-83 trick is only achievable if you force the data image to be close to the code (which is sometimes possible, sometimes not, depending on operating system). Of course, there's the option of going native code... but requiring a particular implementation style is no good. Therefore, we actually use the fig-Forth <BUILDS header structure, and waste a cell per header that isn't a <BUILDS header. This workaround is only wasting memory. The other problem with the CREATE DOES> approach is programming into flash: The usual rule is that you can write every flash cell *once*. So if you do <BUILDS you get a header that waits for one DOES> to patch it up. This is fine, as <BUILDS without DOES> doesn't need to be meaningful. CREATE without DOES> however needs to be meaningful, so patching up the code field of CREATE is necessary, but (on this class of systems) impossible. In summary: This was a not-so-well thought through idea, one word less just because it works 90% of the time. A critical language feature must work everywhere, without having to resort to ugly workarounds. IMHO using CREATE for <BUILDS is a spec bug. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-01-02 19:13 +0000 |
| Message-ID | <52c5ba5c$0$25071$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #27599 |
In article <la4c9j$2hk$1@online.de>, Bernd Paysan <bernd.paysan@gmx.de> wrote: >Elizabeth D. Rather wrote: >> What's the difference between a "trick" and a technique? And when is it >> impossible? We haven't found it to be so, on an incredibly wide number >> of platforms. > >The DOES> implementation requires to have a jump into code at the start of >the DOES> half of the code. This means that this part must be executable That is one view of it. Looking at the standard unburdened with implementation worries, we see that CREATE builds an object with data and one method, so it is a data structure with as the first field a pointer that has a default value that can be overwritten. So it is a kind of methods table with one element. I can't see why there is a problem there, in this world of methods tables that can inherited and polymorphed an what not. >-- >Bernd Paysan >"If you want it done right, you have to do it yourself" >http://bernd-paysan.de/ > -- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-02 15:44 -0600 |
| Message-ID | <BLudnVNaAN08QFjPnZ2dnUVZ_oidnZ2d@supernews.com> |
| In reply to | #27599 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Of course, there's the option of going native code... Yes. > The other problem with the CREATE DOES> approach is programming into > flash: The usual rule is that you can write every flash cell *once*. Err, surely you buffer when generating code for flash, don't you? Is this an interactive system where you can only write each flash cell once or it will catch fire? > In summary: This was a not-so-well thought through idea, one word > less just because it works 90% of the time. Surely that's just what you want. In the case of the x86_64 large model with separated code and data spaces and the Harvard architecture, I don't think it's such a big deal. Two ways spring to mind: Implementing DOES> by generating a small stub in the near code segement, and pointing the code field at it. Alternatively, the two cell approach can be used, but there's only a need for the second cell if DOES> is actually used. If code and data are separate there's no need for that second cell to be emitted until DOES> is called. OK, you might need a spare cell because you're trying to write Forth in C -- in which case an extra cell is the least of your problems. But there's no need in general for <BUILDS, and certainly no reason to burden the majority of systems with it. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-01-02 23:56 +0100 |
| Message-ID | <la4qqo$qkl$1@online.de> |
| In reply to | #27605 |
Andrew Haley wrote: > Bernd Paysan <bernd.paysan@gmx.de> wrote: >> Of course, there's the option of going native code... > > Yes. > >> The other problem with the CREATE DOES> approach is programming into >> flash: The usual rule is that you can write every flash cell *once*. > > Err, surely you buffer when generating code for flash, don't you? Is > this an interactive system where you can only write each flash cell > once or it will catch fire? No, buffering is not feasible on a system with just a few hundred bytes of RAM available. You can either erase a flash sector (all FFFF) or you can write a flash cell once (flipping 1 bits to 0). You may be able to flip even more bits from 1 to 0 by writing another time, but then it is not guaranteed that all 1 bits really stay 1, or stay 1 for as long as they would if only written once. : make-2constant does> 2@ ; Create foo 3 , foo , make-2constant is completely legit, so you really have to modify an already working CREATE header. How to modify with a write-once memory? The solution I found for Gforth R8C is to put the dovar doer on an address which has nearly all bits 1, so it is possible to write them a second time to change it to dodoes. And the R8C says you actually can write a flash cell twice without losing too much (that's meant for byte-writes; the flash is actually organized in words, but Renesas thought it would be good to allow people to write one byte after the other). >> In summary: This was a not-so-well thought through idea, one word >> less just because it works 90% of the time. > > Surely that's just what you want. > > In the case of the x86_64 large model with separated code and data > spaces and the Harvard architecture, I don't think it's such a big > deal. Two ways spring to mind: > > Implementing DOES> by generating a small stub in the near code > segement, and pointing the code field at it. > > Alternatively, the two cell approach can be used, but there's only a > need for the second cell if DOES> is actually used. If code and data > are separate there's no need for that second cell to be emitted until > DOES> is called. Huh? The problem is that this cell needs to be *allocated*, for every single word (relaxation could be to allocate only for every child of CREATE, but that includes VARIABLE). You need to allocate the second cell and you don't know yet if DOES> is called. > OK, you might need a spare cell because you're trying to write Forth > in C -- in which case an extra cell is the least of your problems. > But there's no need in general for <BUILDS, and certainly no reason to > burden the majority of systems with it. Defining : <BUILDS CREATE ; is a very small burden for a system, but jumping through hoops to get CREATE DOES> implemented on systems that have problems is a much bigger burden. In essence, what you do is to require a particular implementation strategy. This is something we don't do, and we agreed not to do. There are real world systems out there that have difficulties or at least considerably negative tradeoffs to implement CREATE DOES> and some implementers considered it too difficult to do and went back to <BUILDS quite recently. Of course, flash memory properties weren't even on the radar 30 years ago, and I think they'll fade away when ReRAM is a mass-produced reliable adder to many silicon processes. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-01-02 15:43 -0800 |
| Message-ID | <7xr48qymog.fsf@ruckus.brouhaha.com> |
| In reply to | #27609 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > No, buffering is not feasible on a system with just a few hundred bytes of > RAM available. Is it enough to just buffer a single address in ram at the time of CREATE, which you'd write to flash if the next definition is seen before DOES> or else modified before flashing if DOES> is seen? Also, for 64-bit systems, why is this even an issue? Those systems usually have gigabytes of ram. A few thousand extra cells allocated to colon words won't be noticed.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-01-02 15:34 -1000 |
| Message-ID | <Rp-dnbc9zcADjlvPnZ2dnUVZ_oydnZ2d@supernews.com> |
| In reply to | #27609 |
On 1/2/14 12:56 PM, Bernd Paysan wrote: > Andrew Haley wrote: > >> Bernd Paysan <bernd.paysan@gmx.de> wrote: >>> Of course, there's the option of going native code... >> >> Yes. >> >>> The other problem with the CREATE DOES> approach is programming into >>> flash: The usual rule is that you can write every flash cell *once*. >> >> Err, surely you buffer when generating code for flash, don't you? Is >> this an interactive system where you can only write each flash cell >> once or it will catch fire? > > No, buffering is not feasible on a system with just a few hundred bytes of > RAM available. You can either erase a flash sector (all FFFF) or you can > write a flash cell once (flipping 1 bits to 0). You may be able to flip > even more bits from 1 to 0 by writing another time, but then it is not > guaranteed that all 1 bits really stay 1, or stay 1 for as long as they > would if only written once. > > : make-2constant does> 2@ ; > Create foo 3 , foo , make-2constant > > is completely legit, so you really have to modify an already working CREATE > header. How to modify with a write-once memory? The solution I found for > Gforth R8C is to put the dovar doer on an address which has nearly all bits > 1, so it is possible to write them a second time to change it to dodoes. > And the R8C says you actually can write a flash cell twice without losing > too much (that's meant for byte-writes; the flash is actually organized in > words, but Renesas thought it would be good to allow people to write one > byte after the other). This is why cross-compilers are so popular for embedded systems. ... >> OK, you might need a spare cell because you're trying to write Forth >> in C -- in which case an extra cell is the least of your problems. >> But there's no need in general for <BUILDS, and certainly no reason to >> burden the majority of systems with it. > > Defining : <BUILDS CREATE ; is a very small burden for a system, but jumping > through hoops to get CREATE DOES> implemented on systems that have problems > is a much bigger burden. > > In essence, what you do is to require a particular implementation strategy. > This is something we don't do, and we agreed not to do. There are real > world systems out there that have difficulties or at least considerably > negative tradeoffs to implement CREATE DOES> and some implementers > considered it too difficult to do and went back to <BUILDS quite recently. > Of course, flash memory properties weren't even on the radar 30 years ago, > and I think they'll fade away when ReRAM is a mass-produced reliable adder > to many silicon processes. Somehow, the Forth community has managed with CREATE for 20 years. Since definition layouts are not mandated (or even described generally) those who have to have 2 cells to make CREATE work can, and the rest of us are quite happy with one. 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-03 04:14 -0600 |
| Message-ID | <YIGdnfdJDPTjEFvPnZ2dnUVZ_oWdnZ2d@supernews.com> |
| In reply to | #27609 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: > >> Bernd Paysan <bernd.paysan@gmx.de> wrote: >>> Of course, there's the option of going native code... >> >> Yes. >> >>> The other problem with the CREATE DOES> approach is programming into >>> flash: The usual rule is that you can write every flash cell *once*. >> >> Err, surely you buffer when generating code for flash, don't you? Is >> this an interactive system where you can only write each flash cell >> once or it will catch fire? > > No, buffering is not feasible on a system with just a few hundred bytes of > RAM available. You can either erase a flash sector (all FFFF) or you can > write a flash cell once (flipping 1 bits to 0). You may be able to flip > even more bits from 1 to 0 by writing another time, but then it is not > guaranteed that all 1 bits really stay 1, or stay 1 for as long as they > would if only written once. So you cross-compile into a buffer, surely. That's perfectly usual on such a small system, for all sorts of reasons. >>> In summary: This was a not-so-well thought through idea, one word >>> less just because it works 90% of the time. >> >> Surely that's just what you want. >> >> In the case of the x86_64 large model with separated code and data >> spaces and the Harvard architecture, I don't think it's such a big >> deal. Two ways spring to mind: >> >> Implementing DOES> by generating a small stub in the near code >> segement, and pointing the code field at it. >> >> Alternatively, the two cell approach can be used, but there's only a >> need for the second cell if DOES> is actually used. If code and data >> are separate there's no need for that second cell to be emitted until >> DOES> is called. > > Huh? The problem is that this cell needs to be *allocated*, for every > single word (relaxation could be to allocate only for every child of CREATE, > but that includes VARIABLE). You need to allocate the second cell and you > don't know yet if DOES> is called. You are allocating in two spaces, one code and one data. You need two pointers from code space, one pointing into to the code after DOES> and one to the data. One a pure Harvard architecture you're going to need two pointers for CREATE too, I would have thought. >> OK, you might need a spare cell because you're trying to write Forth >> in C -- in which case an extra cell is the least of your problems. >> But there's no need in general for <BUILDS, and certainly no reason to >> burden the majority of systems with it. > > Defining : <BUILDS CREATE ; is a very small burden for a system, but > jumping through hoops to get CREATE DOES> implemented on systems > that have problems is a much bigger burden. But it's only a burden *to them*. Let the people with the odd systems shoulder that burden; it's not a great burden, and is a direct consequence of the weird architecture. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-01-03 17:49 +0100 |
| Message-ID | <la6png$v0u$1@online.de> |
| In reply to | #27621 |
Andrew Haley wrote: >> Defining : <BUILDS CREATE ; is a very small burden for a system, but >> jumping through hoops to get CREATE DOES> implemented on systems >> that have problems is a much bigger burden. > > But it's only a burden *to them*. Let the people with the odd systems > shoulder that burden; it's not a great burden, and is a direct > consequence of the weird architecture. I'll remember your argument and will shoot down any complaints from something that is specific to the systems you are concerned about ;-). The standard cares about much weirder systems like one's complement, nibble addressed systems or such (and IMHO we shouldn't do that, because nobody programs for them). Small controllers with flash for the program memory are *the default* in the embedded world - it's *not* a weird architecture, it is the state of the art - until ReRAM is ready. You exclude something very popular for Forth systems from the standard, or at least make it quite difficult? Really? Come on, folks. People here (Elizabeth) suggested to use cross compiling on chips that can't implement CREATE, even though they are fine to use interactively without cross compiler when you have <BUILDS. WTF? They have enough flash to host a system. Obviously there are other people out there who have seen those problems, too, and they decided to go cross compiler or umbilical system for those problematic chips, because they just couldn't implement a standard Forth on them. This means the standard is broken. The complaint about 64 bit systems for sure is that it is mostly inconvenient. It wastes a bit cache space, but only a few percent. The complaint about embedded microcontrollers with flash is that you can't do it and have to go to <BUILDS. The burden for larger systems to have an alias of <BUILDS to CREATE is ridiculously small, the burden of small systems to implement CREATE properly is much larger. So far, the question whether small system implementers want to follow the standard is usually answered with a "no, because you can't do it". Some of the small chips have weird Harward architectures which can't fit well into a standard model. Others just have troubles implementing CREATE DOES>, and maybe want a slimmed down CORE, which is possible, because you are allowed to ship parts of CORE just as source to load. Why exclude those systems? -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-03 12:03 -0600 |
| Message-ID | <gN2dnTjkOcj4ZlvPnZ2dnUVZ_u-dnZ2d@supernews.com> |
| In reply to | #27645 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: >>> Defining : <BUILDS CREATE ; is a very small burden for a system, but >>> jumping through hoops to get CREATE DOES> implemented on systems >>> that have problems is a much bigger burden. >> >> But it's only a burden *to them*. Let the people with the odd systems >> shoulder that burden; it's not a great burden, and is a direct >> consequence of the weird architecture. > > I'll remember your argument and will shoot down any complaints from > something that is specific to the systems you are concerned about ;-). Heh. Touche! Point taken. :-) > The standard cares about much weirder systems like one's complement, > nibble addressed systems or such (and IMHO we shouldn't do that, > because nobody programs for them). Small controllers with flash for > the program memory are *the default* in the embedded world - it's > *not* a weird architecture, it is the state of the art - until ReRAM > is ready. You exclude something very popular for Forth systems from > the standard, or at least make it quite difficult? Really? Absolutely not. It only applies to such systems when they are used in an odd way. > The complaint about 64 bit systems for sure is that it is mostly > inconvenient. It wastes a bit cache space, but only a few percent. > The complaint about embedded microcontrollers with flash is that you > can't do it and have to go to <BUILDS. No, only if you are doing something exceedingly odd: interactively programming a system, with no cross compiler, with the dictionary in flash. Sure, you can do that, but I can't think of any reason that anyone would do it. I'm not saying that you're wrong to want to do that, but I am saying that edge case is not worth standardizing <BUILDS for. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-01-03 10:31 -0800 |
| Message-ID | <7x8uuwsyr0.fsf@ruckus.brouhaha.com> |
| In reply to | #27648 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> No, only if you are doing something exceedingly odd: interactively
> programming a system, with no cross compiler, with the dictionary in
> flash. Sure, you can do that, but I can't think of any reason that
> anyone would do it.
Is that not normal? It's what 4e4th, Flashforth, Camelforth, and maybe
others do, I thought.
"By default, CamelForth/430 will compile source code directly into
the MSP430's Flash memory. This happens automatically any time the
Instruction Dictionary Pointer (IDP) is set to a location within
Flash ROM." ( http://www.camelforth.com/page.php?8 )
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-01-03 19:19 +0000 |
| Message-ID | <52c70d4c$0$25271$e4fe514c@dreader34.news.xs4all.nl> |
| In reply to | #27648 |
In article <gN2dnTjkOcj4ZlvPnZ2dnUVZ_u-dnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Bernd Paysan <bernd.paysan@gmx.de> wrote: <SNIP> > >> The complaint about 64 bit systems for sure is that it is mostly >> inconvenient. It wastes a bit cache space, but only a few percent. >> The complaint about embedded microcontrollers with flash is that you >> can't do it and have to go to <BUILDS. > >No, only if you are doing something exceedingly odd: interactively >programming a system, with no cross compiler, with the dictionary in >flash. Sure, you can do that, but I can't think of any reason that >anyone would do it. I'm not saying that you're wrong to want to do >that, but I am saying that edge case is not worth standardizing ><BUILDS for. Well... That is exactly what we're doing with noforth. Of course you want to do that! Interactive programming, dictionary available, files ready for the download, and just type COLD or press a button if it fails, to get back at your Forth. Because this is exactly the same as I work with my linux Forth's, except that I type lina64be or gforth instead of pressing a button. No cross compiler to learn! What a relief! Think about the poor electronics people who have a hard time understanding the first principles of programming. Cross compilation instead of " The LEDS are connected to port 1E. You can type commands via a serial usb. Try : HEX FF 1E C! Behold all leds go on/Verrek, da's makkelijk. " You can't think of any reason? You surely didn't think hard. And it is not necessary to have <BUILDS. See my other ports. Really a 5 euro sbc is as powerful as 70's CP/M mainframe with dual 5" floppies (90 K each). > >Andrew. 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-01-03 09:56 -1000 |
| Message-ID | <R-udnTZSvbhsiFrPnZ2dnUVZ_qudnZ2d@supernews.com> |
| In reply to | #27652 |
On 1/3/14 9:19 AM, Albert van der Horst wrote: > In article <gN2dnTjkOcj4ZlvPnZ2dnUVZ_u-dnZ2d@supernews.com>, > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >> Bernd Paysan <bernd.paysan@gmx.de> wrote: > <SNIP> >> >>> The complaint about 64 bit systems for sure is that it is mostly >>> inconvenient. It wastes a bit cache space, but only a few percent. >>> The complaint about embedded microcontrollers with flash is that you >>> can't do it and have to go to <BUILDS. >> >> No, only if you are doing something exceedingly odd: interactively >> programming a system, with no cross compiler, with the dictionary in >> flash. Sure, you can do that, but I can't think of any reason that >> anyone would do it. I'm not saying that you're wrong to want to do >> that, but I am saying that edge case is not worth standardizing >> <BUILDS for. > > Well... That is exactly what we're doing with noforth. > > Of course you want to do that! > Interactive programming, dictionary available, files ready for the > download, and just type COLD or press a button if it fails, to get > back at your Forth. > Because this is exactly the same as I work with my linux > Forth's, except that I type lina64be or gforth instead of > pressing a button. All of those conveniences are available on modern Forth cross compilers. But they do not come at a cost of the limitations or implementation difficulties such as you're putting up with. > No cross compiler to learn! What a relief! Think about the > poor electronics people who have a hard time understanding the > first principles of programming. Cross compilation instead of > " > The LEDS are connected to port 1E. > You can type commands via a serial usb. > Try : HEX FF 1E C! > Behold all leds go on/Verrek, da's makkelijk. > " Yes, it's exactly like that with SwiftX. 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-04 04:18 -0600 |
| Message-ID | <k8udnbDRVdJ2QlrPnZ2dnUVZ_sWdnZ2d@supernews.com> |
| In reply to | #27652 |
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <gN2dnTjkOcj4ZlvPnZ2dnUVZ_u-dnZ2d@supernews.com>, > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >>Bernd Paysan <bernd.paysan@gmx.de> wrote: > <SNIP> >> >>> The complaint about 64 bit systems for sure is that it is mostly >>> inconvenient. It wastes a bit cache space, but only a few percent. >>> The complaint about embedded microcontrollers with flash is that you >>> can't do it and have to go to <BUILDS. >> >>No, only if you are doing something exceedingly odd: interactively >>programming a system, with no cross compiler, with the dictionary in >>flash. Sure, you can do that, but I can't think of any reason that >>anyone would do it. I'm not saying that you're wrong to want to do >>that, but I am saying that edge case is not worth standardizing >><BUILDS for. > > Well... That is exactly what we're doing with noforth. > > Of course you want to do that! > Interactive programming, dictionary available, files ready for the > download, and just type COLD or press a button if it fails, to get > back at your Forth. > Because this is exactly the same as I work with my linux > Forth's, except that I type lina64be or gforth instead of > pressing a button. > > No cross compiler to learn! What a relief! Think about the > poor electronics people who have a hard time understanding the > first principles of programming. Cross compilation instead of > " > The LEDS are connected to port 1E. > You can type commands via a serial usb. > Try : HEX FF 1E C! > Behold all leds go on/Verrek, da's makkelijk. > " Eh? All this should just work with a decent Forth umbilical cross-compiler. You certainly don't have to sacrifice any interactivity. All of this should be well-understood by anyone working in the area. I refer you to the classic ;-) paper on the subject: Design Considerations for a Microcontroller Development System, Andrew Haley, Proc. Euroforml 1988. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-01-04 12:39 +0000 |
| Message-ID | <52c800eb$0$24952$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #27664 |
In article <k8udnbDRVdJ2QlrPnZ2dnUVZ_sWdnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: >> In article <gN2dnTjkOcj4ZlvPnZ2dnUVZ_u-dnZ2d@supernews.com>, >> Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >>>Bernd Paysan <bernd.paysan@gmx.de> wrote: >> <SNIP> >>> >>>> The complaint about 64 bit systems for sure is that it is mostly >>>> inconvenient. It wastes a bit cache space, but only a few percent. >>>> The complaint about embedded microcontrollers with flash is that you >>>> can't do it and have to go to <BUILDS. >>> >>>No, only if you are doing something exceedingly odd: interactively >>>programming a system, with no cross compiler, with the dictionary in >>>flash. Sure, you can do that, but I can't think of any reason that >>>anyone would do it. I'm not saying that you're wrong to want to do >>>that, but I am saying that edge case is not worth standardizing >>><BUILDS for. >> >> Well... That is exactly what we're doing with noforth. >> >> Of course you want to do that! >> Interactive programming, dictionary available, files ready for the >> download, and just type COLD or press a button if it fails, to get >> back at your Forth. >> Because this is exactly the same as I work with my linux >> Forth's, except that I type lina64be or gforth instead of >> pressing a button. >> >> No cross compiler to learn! What a relief! Think about the >> poor electronics people who have a hard time understanding the >> first principles of programming. Cross compilation instead of >> " >> The LEDS are connected to port 1E. >> You can type commands via a serial usb. >> Try : HEX FF 1E C! >> Behold all leds go on/Verrek, da's makkelijk. >> " > >Eh? All this should just work with a decent Forth umbilical >cross-compiler. You certainly don't have to sacrifice any >interactivity. All of this should be well-understood by anyone >working in the area. I refer you to the classic ;-) paper on the >subject: > >Design Considerations for a Microcontroller Development System, >Andrew Haley, Proc. Euroforml 1988. Of course. But you've to use a complicated tool, that you don't quite fully understand. If there is something I don't like about noforth, I rebuild it, if must be on a Raspberry pi. > >Andrew. -- 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-01-03 21:43 +0100 |
| Message-ID | <la77dg$m9v$1@online.de> |
| In reply to | #27648 |
Andrew Haley wrote: > Bernd Paysan <bernd.paysan@gmx.de> wrote: >> The complaint about 64 bit systems for sure is that it is mostly >> inconvenient. It wastes a bit cache space, but only a few percent. >> The complaint about embedded microcontrollers with flash is that you >> can't do it and have to go to <BUILDS. > > No, only if you are doing something exceedingly odd: interactively > programming a system, with no cross compiler, with the dictionary in > flash. Sure, you can do that, but I can't think of any reason that > anyone would do it. I'm not saying that you're wrong to want to do > that, but I am saying that edge case is not worth standardizing > <BUILDS for. This is not a corner case, this is the norm for programming small controllers. Their RAM is unconviniently small, but flash is dead cheap, because one flash cell is 6f² (NOR flash), whereas one SRAM cell starts somewhere around 36f² (compact ones). We had Gerald programming our name tags with a MSP430, 8k flash, 512 bytes RAM. 4k of the flash is for the Forth system (which is a typical fig-Forth style system written in assembler), the other 4k are for the program, and you can bulk-erase the entire user-written program quickly to start over again if you need to. And of course you want to program it interactively, it is Forth! It is fun to program, and these 4k were sufficient to drive an LCD dot-matrix screen, add a logo, display your name, a scrolling text explaining what our robot does, and a rocket shooting game (ok, Gerald needed to figure out how to free a few more bytes to actually do the shooting, but he will ;-). This is not the sort of constrained environment where you absolutely need a cross compiler. So this is a serious real-world use-case which can't be dismissed by handwaving. Forth is that scalable, and at least for the von-Neumann architectures, it needs only a few tweaks like adding <BUILDS again to the standard do make standard Forths on such small systems possible. So far, Anton's and my point usually was that the implementors of these small chips don't care about the standard, and produce somewhat annoying and idiosyncratic systems. But at least I talk to those guys on a regular basis, and ask them what prevents their systems to become standard. For amForth, which is also doing direct-do-flash interactive compilation, the main show- stopper is the Harward architecture. A @ from RAM is just a different word than a fetch from flash, which is the instruction space. There's not much to be done there, but there are AVR Forths out there which do emulate a unified memory space. You can still use larger AVRs with 128k flash by having your data memory in the first 64k of the flash (minus the 16k RAM), and the code in the second 64k. The cost of being standard is one compare and branch per @ and !, and it's really not worth to wrap the standard around this sort of weird architecture. However, IMHO it *is* worth to wrap it around the much nicer 16 bit CPUs in that field, like the msp430 or the R8C, where all you need to be comfortable is <BUILDS. The rest already is standard. So this is the point where I start to agree with the small system developers: This is not too expensive for the rest of the Forth world. It's not breaking existing code - programs for such small systems have several further environmental restrictions. The reference implementation is : <BUILDS ( "name" -- ) CREATE ; and as usual, you can provide this as source code. But specifying these things gives implementors of small systems a guidance which will make their system resemble each other more than they do now. We use these small systems as teaching aids, because you need some coolness factor to attract people to program in Forth. Just hooking up a small controller board via USB on your PC, and talking to it via a standard terminal is cool enough to get people hooked. Running Forth on a big desktop computer isn't particularly cool, because you have ample of interactive programming languages there. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-01-03 13:45 -0800 |
| Message-ID | <7xppo8hh9d.fsf@ruckus.brouhaha.com> |
| In reply to | #27658 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > We had Gerald programming our name tags with a MSP430, 8k flash, 512 bytes > RAM. 4k of the flash is for the Forth system (which is a typical fig-Forth > style system written in assembler), the other 4k are for the program... > And of course you want to program it interactively, it is Forth! It is fun > to program, and these 4k were sufficient to drive an LCD dot-matrix screen, Do you really want to write a 4k program interactively with no way to save or edit? I thought interactivity was mostly for debugging. Is your 4k MSP430 Forth released? 4e4th is around 8k, I think.
[toc] | [prev] | [next] | [standalone]
Page 5 of 17 — ← Prev page 1 … 3 4 [5] 6 7 … 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web