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 10 of 17 — ← Prev page 1 … 8 9 [10] 11 12 … 17 Next page →
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-01-13 20:53 +0100 |
| Message-ID | <lb1g8c$r6o$1@online.de> |
| In reply to | #27877 |
Stephen Pelc wrote: > On Mon, 13 Jan 2014 10:45:42 -0600, Andrew Haley > <andrew29@littlepinkcloud.invalid> wrote: > >>At risk of repeating myself, I still don't think it's worth >>resurrecting <BUILDS DOES> for, especially given that CREATE DOES> can >>be made to work even on such a target with some contortions. > > This statement is in danger of being a "proof by repeated assertion". I think Andrew has the problem that <BUILDS had there been once. What if BUFFER: had there been once, and was dropped because CREATE ALLOT could do it just as good? Now we would have it back. > I have not yet managed to convince myself that I could detect all > the potential cases without having at least a spare page of Flash. > I also feel that the complexity of sticking with CREATE ... DOES> > outweighs the simplicity of adding <BUILDS. That's the main point. These system *are* resource-constrained, so you don't want expensive and complicated workarounds. And at least for the systems created by various people around Forth Gesellschaft, the educational value is also important. My experience with educating newcomers is that the easier it is, the more they will understand (obvious ;-). > If you believe that you have a full solution that avoids rewriting > Flash, then please let us know of it. Rewriting 1 bits to 0 is > acceptable, except for those processors (and they exist) that erase > Flash to zero. On those you do rewriting 0 bits to 1. The way I do it on Gforth EC R8C is that each code field is two cells wide, the second cell usually unused. The labels for DOVAR and DODOES are manually arranged in a way that you can overwrite DOVAR with DODOES. DODOES uses this second unused cell. Downsides: * Every word wastes one cell of precious memory (could be reduced to wasting only cells on CREATE) * No more than one DOES> per CREATE * Write a flash cell twice, which is actually allowed on the R8C in "data flash" (which is where the user-created program resides, as it also allows for more erase cycles than program flash) > After all, none of these Flash systems are claiming full ANS > compliance as far as I know. I think Gforth EC R8C is fully ANS compliant when you use RAM mode for multiple-DOES> on a CREATE (that's the only thing that doesn't work in flash). Certainly it's limited to CORE and some TOOLS words. -- 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-14 03:41 -0600 |
| Message-ID | <PsSdnYfhz8TXm0jPnZ2dnUVZ_gednZ2d@supernews.com> |
| In reply to | #27879 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Stephen Pelc wrote: > >> On Mon, 13 Jan 2014 10:45:42 -0600, Andrew Haley >> <andrew29@littlepinkcloud.invalid> wrote: >> >>>At risk of repeating myself, I still don't think it's worth >>>resurrecting <BUILDS DOES> for, especially given that CREATE DOES> can >>>be made to work even on such a target with some contortions. >> >> This statement is in danger of being a "proof by repeated assertion". > > I think Andrew has the problem that <BUILDS had there been once. How is this a problem? > On those you do rewriting 0 bits to 1. The way I do it on Gforth EC R8C is > that each code field is two cells wide, the second cell usually unused. The > labels for DOVAR and DODOES are manually arranged in a way that you can > overwrite DOVAR with DODOES. DODOES uses this second unused cell. > > Downsides: > > * Every word wastes one cell of precious memory (could be reduced to wasting > only cells on CREATE) Hold on a second: are you saying that you waste a cell for every word (rather than just words from CREATE) voluntarily and unnecessarily, yet you are complaining about the overhead that could be avoided by <BUILDS ? > * No more than one DOES> per CREATE > * Write a flash cell twice, which is actually allowed on the R8C in "data > flash" (which is where the user-created program resides, as it also allows > for more erase cycles than program flash) But... the alternative, <BUILDS, also wastes one cell per child of DOES> , and it also has to write a flash cell twice, does it not? There has to be a pointer to RAM from flash, and there has to be a pointer to code. So that's two cells. This is true whether DOES> is used or not. When DOES> is used, add a pointer to the DOES> code and overwrite some bits of the pointer to code. So, there are now three pointers. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-01-14 13:07 +0000 |
| Message-ID | <52d53545.1819376698@news.demon.co.uk> |
| In reply to | #27882 |
On Tue, 14 Jan 2014 03:41:30 -0600, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >But... the alternative, <BUILDS, also wastes one cell per child of >DOES> , and it also has to write a flash cell twice, does it not? <BUILDS is only used with DOES> and must be used with DOES> in such systems. Thus the critical part can be left as $FFFF and can then be modified by DOES>. This still requires you to be able to program an unused two-byte unit in Flash, but many Flash systems do permit this. The MSP430 in paticular has a suitably friendly Flash. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-01-14 17:53 +0100 |
| Message-ID | <lb3q1e$ibt$1@online.de> |
| In reply to | #27882 |
Andrew Haley wrote: >> * Every word wastes one cell of precious memory (could be reduced to >> wasting only cells on CREATE) > > Hold on a second: are you saying that you waste a cell for every word > (rather than just words from CREATE) voluntarily and unnecessarily, > yet you are complaining about the overhead that could be avoided by > <BUILDS ? No, I just follow the general idea from the concept of not having <BUILDS that CREATE is the vanilla defining word, and all other defining words are one way or another derived from CREATE, and there's no special casing for DOES> (this is to be compatible with code that makes that assumption - non- standard code, though, but not worth breaking). There is an additional pointer to RAM, as well... but that one really is only there if it needs to be. The usual case for CREATE DOES> is constant data, and therefore, there should be a way to have constant ROM-based data after the CREATE (not wasting precious RAM and one pointer less in precious flash). Let's say you want a cell array in RAM, so you would define: : array: ( n -- ) <BUILDS RAM here ROM , RAM cells allot DOES> ( n <addr> -- ) @ swap cells + ; This separation of RAM and ROM even makes sense on a native code desktop Forth like VFX, iForth or bigForth, as you don't worry about sharing data and code in the code cache, you only worry about sharing writable data (this can cause a big performance hit). > But... the alternative, <BUILDS, also wastes one cell per child of > DOES> , and it also has to write a flash cell twice, does it not? <BUILDS would give a reason for special-casing it - it is not the root of all defining words, but the special case for DOES>. And as the usual embedded flashs are word-writable, you just put in the DOES> address when you get to the DOES>. > There has to be a pointer to RAM from flash, and there has to be a > pointer to code. So that's two cells. This is true whether DOES> is > used or not. When DOES> is used, add a pointer to the DOES> code > and overwrite some bits of the pointer to code. So, there are now > three pointers. Yes; the point is that there has to be one additional unused pointer for every header that can be modified by DOES>. -- 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-14 17:35 +0000 |
| Message-ID | <52d57569$0$25074$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #27893 |
In article <lb3q1e$ibt$1@online.de>, Bernd Paysan <bernd.paysan@gmx.de> wrote: >Andrew Haley wrote: >>> * Every word wastes one cell of precious memory (could be reduced to >>> wasting only cells on CREATE) >> >> Hold on a second: are you saying that you waste a cell for every word >> (rather than just words from CREATE) voluntarily and unnecessarily, >> yet you are complaining about the overhead that could be avoided by >> <BUILDS ? > >No, I just follow the general idea from the concept of not having <BUILDS >that CREATE is the vanilla defining word, and all other defining words are >one way or another derived from CREATE, and there's no special casing for >DOES> (this is to be compatible with code that makes that assumption - non- >standard code, though, but not worth breaking). There is an additional No, CREATE is not the vanilla defining word! This became very clear to me when I started designing my own indirectly threaded Forth. CREATE is tied to DOES>. For example ciforth doesn't relate VARIABLE in any way to CREATE and the standard doesn't require it to. On the other hand, the standard requires CREATE'd words to have a pointer and that must be a pointer to high level code, i.e. : ; type of code. In many implementation, especially those compiling to native code, the impression exists that that can be the code pointer, the same code pointer that exists in assembler words like DROP and +. Many implementation seem to manage that double use, or at least use enough tricks to confound the issue. On the other hand, in an indirect threaded forth the issue is clear. VARIABLE has a code pointer to DOVAR, and a data area. CREATE has a code pointer to DODOES and a data area consisting of two fields: the DOES> pointer and the BODY in the ISO sense. The does pointer is data, as we are well aware as soon as we are thinking flash and separation between code and data. Much I've seen in this thread has to do with attempts of double use of the code pointer and the DOES> pointer. A case of premature optimisation if there was one, and -- may I repeat -- the root of much evil. <SNIP> >Yes; the point is that there has to be one additional unused pointer for >every header that can be modified by DOES>. Let's embrace it, it is the Standard. And I wouldn't say it is unused, superfluous maybe. >-- >Bernd Paysan > -- 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-14 08:23 -1000 |
| Message-ID | <_dmdnRLsJI03HUjPnZ2dnUVZ_smdnZ2d@supernews.com> |
| In reply to | #27893 |
On 1/14/14 6:53 AM, Bernd Paysan wrote: > Andrew Haley wrote: >>> * Every word wastes one cell of precious memory (could be reduced to >>> wasting only cells on CREATE) >> >> Hold on a second: are you saying that you waste a cell for every word >> (rather than just words from CREATE) voluntarily and unnecessarily, >> yet you are complaining about the overhead that could be avoided by >> <BUILDS ? > > No, I just follow the general idea from the concept of not having <BUILDS > that CREATE is the vanilla defining word, and all other defining words are > one way or another derived from CREATE, and there's no special casing for > DOES> (this is to be compatible with code that makes that assumption - non- > standard code, though, but not worth breaking). CREATE has been tied to DOES> since 1994, 20 years now. It's good to avoid breaking standard code, but tying yourself in knots to protect non-standard code is unnecessary and inappropriate. CREATE can, in some implementations, be a generic defining word, but it isn't expected to be, and Forth94 explicitly avoided making that a requirement or even an expectation. > There is an additional > pointer to RAM, as well... but that one really is only there if it needs to > be. The usual case for CREATE DOES> is constant data, and therefore, there > should be a way to have constant ROM-based data after the CREATE (not > wasting precious RAM and one pointer less in precious flash). I absolutely deny that "the *usual* case for CREATE DOES> is constant data". In my experience, the most common use of it is to build variable arrays. 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-14 13:19 -0600 |
| Message-ID | <G-WdnRIzN-ExEEjPnZ2dnUVZ_hOdnZ2d@supernews.com> |
| In reply to | #27893 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: >>> * Every word wastes one cell of precious memory (could be reduced to >>> wasting only cells on CREATE) >> >> Hold on a second: are you saying that you waste a cell for every word >> (rather than just words from CREATE) voluntarily and unnecessarily, >> yet you are complaining about the overhead that could be avoided by >> <BUILDS ? > > No, I just follow the general idea from the concept of not having > <BUILDS that CREATE is the vanilla defining word, and all other > defining words are one way or another derived from CREATE, and > there's no special casing for DOES> (this is to be compatible with > code that makes that assumption - non- standard code, though, but > not worth breaking). There is an additional pointer to RAM, as > well... but that one really is only there if it needs to be. The > usual case for CREATE DOES> is constant data, Well, it's both, really. > and therefore, there should be a way to have constant ROM-based data > after the CREATE (not wasting precious RAM and one pointer less in > precious flash). But that's very nonstandard: by definition anything after CREATE is writable. > Let's say you want a cell array in RAM, so you would define: > > : array: ( n -- ) > <BUILDS RAM here ROM , RAM cells allot > DOES> ( n <addr> -- ) @ swap cells + ; > > This separation of RAM and ROM even makes sense on a native code > desktop Forth like VFX, iForth or bigForth, as you don't worry about > sharing data and code in the code cache, you only worry about > sharing writable data (this can cause a big performance hit). Of course, I know that, but there's no reason that : array: ( n -- ) create cells allot does> ( n <addr> -- ) swap cells + ; can't work, given appropriate definitions for CREATE and DOES> >> There has to be a pointer to RAM from flash, and there has to be a >> pointer to code. So that's two cells. This is true whether DOES> is >> used or not. When DOES> is used, add a pointer to the DOES> code >> and overwrite some bits of the pointer to code. So, there are now >> three pointers. > > Yes; the point is that there has to be one additional unused pointer > for every header that can be modified by DOES>. You don't need to allocate space for that pointer until DOES> is executed, therefore there is no space wasted. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | oh2aun@gmail.com |
|---|---|
| Date | 2014-01-14 12:31 -0800 |
| Message-ID | <af80fe30-a017-4c52-8cd2-358d42db84c4@googlegroups.com> |
| In reply to | #27896 |
In FlashForth CREATE compiles DOVAR and the address of the free data space. DOES> then modifies DOVAR to DOtheDOEScode. : defer create ['] abort , does> @execute ; ' abort . 4480 ok ram here . 1024 ok ram defer ping ok see ping 62dc eb27 rcall DODEFER 62de 1024 pointer to ram ok 1024 4480 address of abort flash here . 62ea ok flash defer pong ok see pong 62f2 eb1c rcall DODEFER 62f4 62f6 pointer to flash 62f6 4480 address of abort ok This works quite well but requires that DOVAR can be modified to the DODEFER in the example. Without buffering flash in ram it is a bit difficult to implement on some flash architectures, specially on flash that only supports block write. In hindsight <BUILDS was a cleaner solution than CREATE because CREATE has been given a double meaning with both of DOVAR and DOtheDOEScode. And maybe some other DO actions as well...? Mikael
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-01-14 21:37 +0100 |
| Message-ID | <lb476a$7t4$1@online.de> |
| In reply to | #27896 |
Andrew Haley wrote: > Bernd Paysan <bernd.paysan@gmx.de> wrote: >> No, I just follow the general idea from the concept of not having >> <BUILDS that CREATE is the vanilla defining word, and all other >> defining words are one way or another derived from CREATE, and >> there's no special casing for DOES> (this is to be compatible with >> code that makes that assumption - non- standard code, though, but >> not worth breaking). There is an additional pointer to RAM, as >> well... but that one really is only there if it needs to be. The >> usual case for CREATE DOES> is constant data, > > Well, it's both, really. Yes, the problem with CREATE is that it is dual-purpose: First, CREATE <name> is just creating a data label. And then, CREATE is the starting point of what becomes modified by DOES>. There are systems where this dual use is no problem at all, and there are systems (as discusssed) where this dual use is really problematic. The usual case of CREATE + ALLOT something in RAM is already dealt with BUFFER:, a special-purpose word. >> and therefore, there should be a way to have constant ROM-based data >> after the CREATE (not wasting precious RAM and one pointer less in >> precious flash). > > But that's very nonstandard: by definition anything after CREATE is > writable. Er, we are talking about dictionary-in-flash mode. If you are in this mode, everything is exactly write-once. If you want to have stuff in RAM, switch to RAM mode. > Of course, I know that, but there's no reason that > > : array: ( n -- ) > create cells allot > does> ( n <addr> -- ) swap cells + ; > > can't work, given appropriate definitions for CREATE and DOES> And ALLOT, which however is not the case. ALLOT manipulates the current dictionary, and if that's flash (ROM), then it is write-once. Defining VARIABLE in that mode will redirect you to RAM space (implemented as CONSTANT). You can hide this fact by being clever, but being clever is orthogonal to being simple. These resource-constrained environments absolutely require being simple. > You don't need to allocate space for that pointer until DOES> is > executed, therefore there is no space wasted. Unfortunately, the user is allowed to allocate stuff from the dictionary *before* DOES> is executed. However, when you hide the flash space, and the user only can manipulate RAM space, while all the code and header stuff goes to flash, this restriction goes away. However, as these systems are very RAM-constrained, it is important that the user can put all constant data into flash. -- 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-14 16:12 -0600 |
| Message-ID | <TtWdnbqjzY_9K0jPnZ2dnUVZ_j6dnZ2d@supernews.com> |
| In reply to | #27898 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: > >> Bernd Paysan <bernd.paysan@gmx.de> wrote: >>> No, I just follow the general idea from the concept of not having >>> <BUILDS that CREATE is the vanilla defining word, and all other >>> defining words are one way or another derived from CREATE, and >>> there's no special casing for DOES> (this is to be compatible with >>> code that makes that assumption - non- standard code, though, but >>> not worth breaking). There is an additional pointer to RAM, as >>> well... but that one really is only there if it needs to be. The >>> usual case for CREATE DOES> is constant data, >> >> Well, it's both, really. > > Yes, the problem with CREATE is that it is dual-purpose: First, > CREATE <name> is just creating a data label. And then, CREATE is > the starting point of what becomes modified by DOES>. There are > systems where this dual use is no problem at all, and there are > systems (as discusssed) where this dual use is really problematic. I don't think so. I think you've shot yourself in the foot by doing that. I think the problem is using the name CREATE to define something other than data space. > The usual case of CREATE + ALLOT something in RAM is already dealt with > BUFFER:, a special-purpose word. > >>> and therefore, there should be a way to have constant ROM-based data >>> after the CREATE (not wasting precious RAM and one pointer less in >>> precious flash). >> >> But that's very nonstandard: by definition anything after CREATE is >> writable. > > Er, we are talking about dictionary-in-flash mode. The dictionary has to be in flash, but HERE can certainly be in RAM. >> Of course, I know that, but there's no reason that >> >> : array: ( n -- ) >> create cells allot >> does> ( n <addr> -- ) swap cells + ; >> >> can't work, given appropriate definitions for CREATE and DOES> > > And ALLOT, which however is not the case. ALLOT manipulates the > current dictionary, and if that's flash (ROM), then it is > write-once. Defining VARIABLE in that mode will redirect you to RAM > space (implemented as CONSTANT). OK, you can do it that way, but I don't know why you do it that way: you could just as easily make ram the default space for ALLOT and HERE, and use different names for the dictionary in flash. That's what I always did with systems with separate code and data spaces. It makes porting a heck of a lot easier. But why do you care about standards re <BUILDS when your system is so designed as to be utterly nonstandard? That's the part I don't understand. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-01-14 12:18 -1000 |
| Message-ID | <f7ydnUik3cEzKkjPnZ2dnUVZ_jqdnZ2d@supernews.com> |
| In reply to | #27898 |
On 1/14/14 10:37 AM, Bernd Paysan wrote: > Andrew Haley wrote: > >> Bernd Paysan <bernd.paysan@gmx.de> wrote: >>> No, I just follow the general idea from the concept of not having >>> <BUILDS that CREATE is the vanilla defining word, and all other >>> defining words are one way or another derived from CREATE, and >>> there's no special casing for DOES> (this is to be compatible with >>> code that makes that assumption - non- standard code, though, but >>> not worth breaking). There is an additional pointer to RAM, as >>> well... but that one really is only there if it needs to be. The >>> usual case for CREATE DOES> is constant data, >> >> Well, it's both, really. > > Yes, the problem with CREATE is that it is dual-purpose: First, CREATE > <name> is just creating a data label. And then, CREATE is the starting > point of what becomes modified by DOES>. There are systems where this dual > use is no problem at all, and there are systems (as discusssed) where this > dual use is really problematic. > > The usual case of CREATE + ALLOT something in RAM is already dealt with > BUFFER:, a special-purpose word. > >>> and therefore, there should be a way to have constant ROM-based data >>> after the CREATE (not wasting precious RAM and one pointer less in >>> precious flash). >> >> But that's very nonstandard: by definition anything after CREATE is >> writable. > > Er, we are talking about dictionary-in-flash mode. If you are in this mode, > everything is exactly write-once. If you want to have stuff in RAM, switch > to RAM mode. > >> Of course, I know that, but there's no reason that >> >> : array: ( n -- ) >> create cells allot >> does> ( n <addr> -- ) swap cells + ; >> >> can't work, given appropriate definitions for CREATE and DOES> > > And ALLOT, which however is not the case. ALLOT manipulates the current > dictionary, and if that's flash (ROM), then it is write-once. Defining > VARIABLE in that mode will redirect you to RAM space (implemented as > CONSTANT). Wrong. ALLOT manipulates the *data space pointer* not the dictionary, and HERE returns the address of the next available location in *data space*. Applications have no inherent right to manipulate dictionary space. Yes, there have always been (and still are) systems in which data space and dictionary are intermingled, but as a programmer you need to be able to think of them separately. That concept is essential for dealing with RAM/ROM/FLASH environments. 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-15 04:19 +0100 |
| Message-ID | <lb4uni$e44$1@online.de> |
| In reply to | #27901 |
Elizabeth D. Rather wrote:
> Wrong. ALLOT manipulates the *data space pointer* not the dictionary,
> and HERE returns the address of the next available location in *data
> space*.
>
> Applications have no inherent right to manipulate dictionary space. Yes,
> there have always been (and still are) systems in which data space and
> dictionary are intermingled, but as a programmer you need to be able to
> think of them separately. That concept is essential for dealing with
> RAM/ROM/FLASH environments.
The RAM/ROM part is orthogonal to data/code. ROM is for constant data and
constant code, RAM is for variables. There's a lot of constant data, as
well, and RAM can be used for temporary code - we do have use cases for
that, too. Some processors (8051, AVR) assign flash and RAM to these roles
by being Harward architectures, others don't.
The current standard is not fitting well with the situation we have on these
small controllers. Andrew asks me why I bother with standards when my
system is uttrly non-standard. The reason is: I do care, but I can't,
because the standard collides hard with the reality of these systems - so
this opens up the question whether this is a problem with the standard or
these systems. One reality of these systems is that code and data are no
longer separated in flash and RAM - the more recent systems are von Neumann
architectures, you can intermingle data and code - and it helps to fully
utilize the few resources if you do.
We are not talking about esotheric hardware, we are talking about mainstream
controllers - whether small ARM Cortex-M0 or -M1, the MSP430, or the R8C
family. They all are no longer arcane 8 bit microcontrollers as it used to
be, but scaled down derivatives of respected architectures (PDP-11 in case
of MSP430 and R8C, ARM Thumb mode in case of the Cortex series).
Programs written for such systems can still be portable. If you don't have
a flash, but everything is in RAM (like on a PC), well, then writing to the
ROM space is actually possible. The program that doesn't write into ROM
space still will work. Unless you overdo it with switching between RAM and
ROM, all you need to do on a PC is to define the two words as NOOP.
Let's give an example: In the R8C port of Dirk Zoller's Tetris for
Terminals, bricks look like that (comments partially stripped in this code
for faster downloading):
\ Define shapes of bricks:
: def-brick create
does> rot 4 * rot + 2* + ;
: ,s" [char] " parse bounds
DO i c@ c, LOOP ;
def-brick brick1
,s" "
,s" ###### "
,s" ## "
,s" "
This is all ROM space, because we have a number of bricks, but we don't have
enough RAM for all the bricks - and the data is constant, anyways. Then we
have the space for two bricks which is actually in RAM:
\ this brick is actually in use:
ram
def-brick brick ,s" "
,s" "
,s" "
,s" "
def-brick scratch ,s" "
,s" "
,s" "
,s" "
rom
The whole program fits very tightly into the available memory. My
experience with all these projects is that they fill up all available space,
and therefore have to make best use of what's there. Being free to select
RAM or ROM for data is one of the key features that allows this. Having one
intermingled dictionary is also conceptually easier. Remember: We use these
controllers as carrot on a stick to get people interested in Forth. It is
much more fun to program these controllers in Forth than with C, and we do
get them that way. They are not interested in Forth on PCs, because Python
gives them all they need, including interactiviy. Python doesn't run on a
controller.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-15 17:52 +0000 |
| Subject | DOES> and flash (was: PICK changed from 1-based to 0-based?) |
| Message-ID | <2014Jan15.185210@mips.complang.tuwien.ac.at> |
| In reply to | #27893 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>The usual case for CREATE DOES> is constant data, and therefore, there
>should be a way to have constant ROM-based data after the CREATE (not
>wasting precious RAM and one pointer less in precious flash).
But the standard CREATE...DOES> must put the data in RAM, because the
user is entitled to do stuff like
5 ' foo >body !
at any time if FOO has been CREATEd and at least one cell has been
ALLOTed. And changing the body of a child of CREATE...DOES> is pretty
common (e.g., consider the reference implementation of X:deferred), so
dealing with that by "environmental restriction" is not a good idea.
How about this:
CREATE...DOES> has writable data. <BUILDS...DOES> has read-only data.
The incentive for programmers to use <BUILDS where appropriate even
when they don't care for flash-based systems would be the possibility
that the compiler may optimize accesses to the data.
Implementation on a flash-based system:
CREATE produces
dovar (probably same code as docon)
RAM body pointer
If DOES> sees a dovar, it turns it into
dodoesram
RAM body pointer
code pointer
<BUILDS produces
dodoesflash
placeholder for code pointer
if DOES> sees a dodoesflash, it stores the code pointer in the
placeholder.
>Let's say you want a cell array in RAM, so you would define:
>
>: array: ( n -- )
> <BUILDS RAM here ROM , RAM cells allot
> DOES> ( n <addr> -- ) @ swap cells + ;
With the ideas above it might be something like either
: array: ( n1 -- )
create cells allot
does> ( n2 -- )
@ swap cells + ;
or something like
: array: ( n1 -- )
here cells allot <builds ,
does> ( n2 -- )
@ swap cells + ;
>This separation of RAM and ROM even makes sense on a native code desktop
>Forth like VFX, iForth or bigForth, as you don't worry about sharing data
>and code in the code cache, you only worry about sharing writable data (this
>can cause a big performance hit).
It's pretty straightforward to get rid of the cache consistency
problems by just separating code from data, no need for new Forth
words; and that will also eliminate other issues, in particular
consistency problems between any kind of data and code (P5 and K6) and
lower cache utilization (any CPU with separate I-cache and D-cache).
But marking some memory areas as read-only can help optimization. I
am not sure that ROM and RAM really are the best way to do that (e.g.,
it probably would not help for ALLOCATEd memory), but maybe they are
good enough.
- 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 | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-01-15 21:56 +0000 |
| Subject | Re: DOES> and flash (was: PICK changed from 1-based to 0-based?) |
| Message-ID | <52d703e1.1937804717@news.demon.co.uk> |
| In reply to | #27910 |
On Wed, 15 Jan 2014 17:52:10 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >How about this: > >CREATE...DOES> has writable data. <BUILDS...DOES> has read-only data. >The incentive for programmers to use <BUILDS where appropriate even >when they don't care for flash-based systems would be the possibility >that the compiler may optimize accesses to the data. > >Implementation on a flash-based system: > >CREATE produces > >dovar (probably same code as docon) >RAM body pointer > >If DOES> sees a dovar, it turns it into > >dodoesram >RAM body pointer >code pointer > ><BUILDS produces > >dodoesflash >placeholder for code pointer > >if DOES> sees a dodoesflash, it stores the code pointer in the >placeholder. So DOES> always writes twice to Flash. No, no, no. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-16 09:30 +0000 |
| Subject | Re: DOES> and flash (was: PICK changed from 1-based to 0-based?) |
| Message-ID | <2014Jan16.103021@mips.complang.tuwien.ac.at> |
| In reply to | #27911 |
stephenXXX@mpeforth.com (Stephen Pelc) writes:
>On Wed, 15 Jan 2014 17:52:10 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>How about this:
>>
>>CREATE...DOES> has writable data. <BUILDS...DOES> has read-only data.
>>The incentive for programmers to use <BUILDS where appropriate even
>>when they don't care for flash-based systems would be the possibility
>>that the compiler may optimize accesses to the data.
>>
>>Implementation on a flash-based system:
>>
>>CREATE produces
>>
>>dovar (probably same code as docon)
>>RAM body pointer
>>
>>If DOES> sees a dovar, it turns it into
>>
>>dodoesram
>>RAM body pointer
>>code pointer
>>
>><BUILDS produces
>>
>>dodoesflash
>>placeholder for code pointer
>>
>>if DOES> sees a dodoesflash, it stores the code pointer in the
>>placeholder.
>
>So DOES> always writes twice to Flash. No, no, no.
<BUILDS...DOES> writes to each cell only once. The placeholder is not
written before the code pointer is written there.
CREATE...DOES> writes to the code field cell twice, using the trick
that Bernd uses now.
- 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 | Matthias Koch <matthias.koch@hot.uni-hannover.de> |
|---|---|
| Date | 2014-01-17 12:44 +0100 |
| Subject | Re: DOES> and flash |
| Message-ID | <lbb5at$rnh$1@newsserver.rrzn.uni-hannover.de> |
| In reply to | #27915 |
> <BUILDS...DOES> writes to each cell only once. The placeholder is not > written before the code pointer is written there. > > CREATE...DOES> writes to the code field cell twice, using the trick > that Bernd uses now. > > - anton Oh yes, this is the problem I face both on MSP430 and ARM Cortex M while compiling into Flash and posted to this list some time ago. Please finally address write once Flash memory in standard conferences. I vote for a <builds does> approach. Re-Does> should not be asked for in standard and should be declared as possible environmental depedence. Additionally, create should exist in two flavours on native code systems: one (create) with no action at all for hand-coded assembly definitions and create or create> with the common standard action : create> <builds ( -- ) does> ( -- addr ) ; "put address on stack" for data tables. Matthias
[toc] | [prev] | [next] | [standalone]
| From | oh2aun@gmail.com |
|---|---|
| Date | 2014-01-17 08:05 -0800 |
| Subject | Re: DOES> and flash |
| Message-ID | <2d2fa398-1a61-4f21-8d1b-67180cae2536@googlegroups.com> |
| In reply to | #27923 |
On Friday, January 17, 2014 1:44:17 PM UTC+2, Matthias Koch wrote: > Oh yes, this is the problem I face both on MSP430 and ARM Cortex M while compiling into Flash and posted to this list some time ago. Please finally address write once Flash memory in standard conferences. I vote for a <builds does> approach. Re-Does> should not be asked for in standard and should be declared as possible environmental depedence. > > Additionally, create should exist in two flavours on native code systems: one (create) with no action at all for hand-coded assembly definitions and create or create> with the common standard action : create> <builds ( -- ) does> ( -- addr ) ; "put address on stack" for data tables. > Matthias For FlashForth I tried to find a solution that makes interactive usage comfortable. The cross compiler standard is not really applicable for a native system so I skipped that. The requirements were: 1. Possibility to have data space in all types of memory. -> RAM EEPROM FLASH words to select the dataspace. 2. Possibility to compile code in all types of memory. -> COMPILETOFLASH COMPILETORAM COMPILETOXXXX words to select the compilation target memory. -> Only needed for VonNeumann, not for Harvard architecture. 3. Same words for both VonNeumann and Harvard architectures. -> @ ! C@ C! that works with all kind of memory -> @ ! C@ C! can branch to read/write routines based on address mapped memory types if the hardware does not support it directly. -> Gets rid of multiple copies of highlevel words for each memory type. 4. Works with both block and word writeable flash. -> Automatic ram buffer for flash writes (=Always block write). -> Enables multiple writes to flash solving all problems with word headers, CREATE and DOES> -> No need for the programmer to worry if the memory is writeonce or writefew. -> MARKER FORGET works in an optimal way. -> Enables also peephole optimiser. 5. No need to reflash the kernel whatever the user throws at the system -> Kernel write protection inside the flash write code. -> Address range check in flash block write or HW write protection. -> Cold literals can always be copied from write protected flash. -> The word COLD is always FINDable. The only case where this generic solution does not work is with flash controllers that are very small and do not have ram to buffer one flash block. Those controllers would need the <BUILDS word. Some controlled writing of the word header bits is still needed if you want to combine several bits in one write (IMMEDIATE_MASK COMPILEONLY_MASK INLINED_MASK AND AND LATEST !) Or are all flashes word:bit writeable ? Mikael
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-17 16:43 +0000 |
| Subject | Re: DOES> and flash |
| Message-ID | <2014Jan17.174343@mips.complang.tuwien.ac.at> |
| In reply to | #27925 |
oh2aun@gmail.com writes:
>Some controlled writing of the word header bits is still needed
>if you want to combine several bits in one write=20
>(IMMEDIATE_MASK COMPILEONLY_MASK INLINED_MASK AND AND LATEST !)
>Or are all flashes word:bit writeable ?
AFAIK they are at best cell-writable (sometimes twice to allow byte
writing). IMMEDIATE and similar flags are certainly also a challenge,
and it's interesting that they have not been mentioned here before.
One implementation approach would be to store that information
elsewhere (e.g., a list that contains all immediate words; I leave
thinking up optimizations as an exercise to the reader).
- 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-01-17 20:37 +0100 |
| Subject | Re: DOES> and flash |
| Message-ID | <lbc0ou$2vd$1@online.de> |
| In reply to | #27927 |
Anton Ertl wrote: > AFAIK they are at best cell-writable (sometimes twice to allow byte > writing). IMMEDIATE and similar flags are certainly also a challenge, > and it's interesting that they have not been mentioned here before. Yes, I wonder a bit about that, too. I do immediate and compile-only by having these bits 1 as "inactive", and overwrite them with zero; in total, a flash word might then receive three writes. -- 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-18 04:40 -0600 |
| Subject | Re: DOES> and flash |
| Message-ID | <xqSdnTfNpr6Kx0fPnZ2dnUVZ_t6dnZ2d@supernews.com> |
| In reply to | #27928 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Anton Ertl wrote: >> AFAIK they are at best cell-writable (sometimes twice to allow byte >> writing). IMMEDIATE and similar flags are certainly also a challenge, >> and it's interesting that they have not been mentioned here before. > > Yes, I wonder a bit about that, too. I do immediate and compile-only by > having these bits 1 as "inactive", and overwrite them with zero; in total, a > flash word might then receive three writes. Just a thought: couldn't a header or a word be constructed in a staging area and moved to flash later? That wouldn't be much more complicated than all the other, er, techniques we've been talking abut. :-) Andrew.
[toc] | [prev] | [next] | [standalone]
Page 10 of 17 — ← Prev page 1 … 8 9 [10] 11 12 … 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web