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 12 of 17 — ← Prev page 1 … 10 11 [12] 13 14 … 17 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-01-16 00:22 -0800 |
| Subject | Re: DOES> and flash |
| Message-ID | <7xsiso1glo.fsf@ruckus.brouhaha.com> |
| In reply to | #27913 |
Lars Brinkhoff <lars.spam@nocrew.org> writes: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> Now we have these PDP-11 derivatives with little RAM and some flash; > Which are thosse? I think that means MSP430.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-01-16 15:38 +0100 |
| Subject | Re: DOES> and flash |
| Message-ID | <lb8qsd$q3q$1@online.de> |
| In reply to | #27914 |
Paul Rubin wrote: > Lars Brinkhoff <lars.spam@nocrew.org> writes: >> Bernd Paysan <bernd.paysan@gmx.de> writes: >>> Now we have these PDP-11 derivatives with little RAM and some flash; >> Which are thosse? > > I think that means MSP430. R8C also has a PDP-11 derived instruction set. On the upper end, Freescale has now smaller ColdFire MCUs, which also could count as PDP-11 inspired ISAs (though 32 bit). The smallest V1 MCU has 8k RAM and 128k flash. The same applies as with the smaller controllers: Flash is ample, RAM is scarce. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2014-01-20 09:45 +0100 |
| Subject | Re: DOES> and flash |
| Message-ID | <85y52b6nyp.fsf@junk.nocrew.org> |
| In reply to | #27914 |
> Lars Brinkhoff <lars.spam@nocrew.org> writes: >> Bernd Paysan <bernd.paysan@gmx.de> writes: >>> Now we have these PDP-11 derivatives with little RAM and some flash; >> Which are those? Paul Rubin <no.email@nospam.invalid> writes: > I think that means MSP430. Looks 11-ish indeed. Bernd Paysan <bernd.paysan@gmx.de> writes: > R8C also has a PDP-11 derived instruction set. On the upper end, > Freescale has now smaller ColdFire MCUs, which also could count as > PDP-11 inspired ISAs (though 32 bit). Sure, ColdFire being a 68000 derivative. I grew up on the 68k, and when I (much later) saw the PDP-11 ISA it felt very familiar. I suppose it was heavliy influenced by PDP-11 when designed in the late 70'ies.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-16 09:33 +0000 |
| Subject | Re: DOES> and flash (was: PICK changed from 1-based to 0-based?) |
| Message-ID | <2014Jan16.103318@mips.complang.tuwien.ac.at> |
| In reply to | #27912 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> 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.
>
>You tell the Forth system whether it's RAM or ROM, so you know that you can
>only put constants into ROM (write-once flash).
Sure, once you have a non-standard word like ROM in your program, from
then on everything goes. E.g., you could make ROM CREATE behave like
what I suggested for <BUILDS.
>Arguing that the standard entitles to treat everything as RAM and therefore
>you don't want to have stuff in flash is a bit silly, because this is
>exactly the deficit of the standard implementers on small embedded systems
>face: You have much more flash than RAM on all of them.
I understand why there is the desire to put stuff into flash where the
standard requires writable memory. The questions are:
Do you want to comply with the standard?
If so, what should be added to the standard to support these
flash-based systems?
If you implement standard words in a non-compliant way, you obviously
have no interest in the standard, and we can stop this discussion.
>> 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.
>
>I wouldn't waste too much time on constant folding ALLOCATEd memory ;-).
>The main purpose of dynamic memory is to handle things that come and go. If
>it is just a one-time allocation of static data, don't ALLOCATE it.
Knowing that stuff in ALLOCATEd memory won't change can be used for
optimization even if that memory is later freed. The implementation
of such optimizations is non-trivial, though.
And there are also good uses of ALLOCATE for memory that will not be FREEd.
- 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-16 16:09 +0100 |
| Subject | Re: DOES> and flash (was: PICK changed from 1-based to 0-based?) |
| Message-ID | <lb8snr$t17$1@online.de> |
| In reply to | #27916 |
Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>You tell the Forth system whether it's RAM or ROM, so you know that you >>can only put constants into ROM (write-once flash). > > Sure, once you have a non-standard word like ROM in your program, from > then on everything goes. E.g., you could make ROM CREATE behave like > what I suggested for <BUILDS. "anything goes" still doesn't make sense. People use tutorials like the one in Gforth's manual, or Starting Forth, and therefore, the ROM switch can only do one thing: Make the ROM the dictionary. You can't play Humpty Dumpty, you must make your additions consistent, and thus easy to learn. >>Arguing that the standard entitles to treat everything as RAM and >>therefore you don't want to have stuff in flash is a bit silly, because >>this is exactly the deficit of the standard implementers on small embedded >>systems face: You have much more flash than RAM on all of them. > > I understand why there is the desire to put stuff into flash where the > standard requires writable memory. The questions are: > > Do you want to comply with the standard? Yes. This reduces porting effort, and makes programmers more portable (i.e. they have to learn less idiosyncracies to be productive with an embedded Forth). > If so, what should be added to the standard to support these > flash-based systems? There's already something in the (to be reviewed and rewritten) cross compiler proposal: We need ways to deal with the fact that there can be more than one contiguous memory for the dictionary, and that the properties of these regions differ (write-many, write-once, write-few for EEPROM). This requires adding conceptional stuff like what a write-once or write-few memory is, adding standard names for operators writing there (it is sometimes not possible to use standard ! to do so), and I think it is better to resurrect <BUILDS than relying on the two tricky methods I and Albert/Willem use. The other option for write-once memory is a combination of DOER: <name> ... ; BUILDS ( doer "name" ) where you get all the header building done in one atomic operation, and then there is no confusion possible about how many times you could use DOES> (it's an atomic operation). > If you implement standard words in a non-compliant way, you obviously > have no interest in the standard, and we can stop this discussion. This is the "there is no middle ground" logical fallacy: The standard has a deficit, i.e. a conflict between reality (write-once flash is a reality) and the fiction in the standard, that all memory is write-many. I think we need to revisit the cross compiler stuff, and split it up into different parts, the same way we did it for the internationalization stuff. Each part should deal with one specific topic. That way it is easier to integrate into the standard, and the components are more flexible to use (e.g. the memory regions can be used by flash-based standalone systems). > Knowing that stuff in ALLOCATEd memory won't change can be used for > optimization even if that memory is later freed. The implementation > of such optimizations is non-trivial, though. > > And there are also good uses of ALLOCATE for memory that will not be > FREEd. You won't see an ALLOCATE on a small embedded system, so the discussion about ALLOCATE with constant data (and complicated optimizations on those) certainly is for larger systems only ;-). If you are lucky, you'll get a native code compiler in the bigForth style on a small system (with macro copies, and a bit of peephole optimization). -- 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-17 03:28 -0600 |
| Subject | Re: DOES> and flash |
| Message-ID | <05GdnYkiIN4rakXPnZ2dnUVZ_tWdnZ2d@supernews.com> |
| In reply to | #27918 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > > There's already something in the (to be reviewed and rewritten) cross > compiler proposal: We need ways to deal with the fact that there can be more > than one contiguous memory for the dictionary, and that the properties of > these regions differ (write-many, write-once, write-few for EEPROM). > > This requires adding conceptional stuff like what a write-once or write-few > memory is, adding standard names for operators writing there (it is > sometimes not possible to use standard ! to do so), and I think it is better > to resurrect <BUILDS than relying on the two tricky methods I and > Albert/Willem use. > > The other option for write-once memory is a combination of > > DOER: <name> ... ; > > BUILDS ( doer "name" ) > > where you get all the header building done in one atomic operation, and then > there is no confusion possible about how many times you could use DOES> > (it's an atomic operation). Wouldn't it make more sense to have a word that simply takes an XT and creates a header? Or is there some implementation reason that won't work? I suppose there'd have to be a jump from the code that pushes the address of the child word's data, which would be a bad thing, but the result is notationally quite nice. It'd look like : constant [: @ ;] builds , ; The runtime action appears before the compile-time action. Dunno if that matters. >> Knowing that stuff in ALLOCATEd memory won't change can be used for >> optimization even if that memory is later freed. The implementation >> of such optimizations is non-trivial, though. >> >> And there are also good uses of ALLOCATE for memory that will not be >> FREEd. > > You won't see an ALLOCATE on a small embedded system, so the discussion > about ALLOCATE with constant data (and complicated optimizations on those) > certainly is for larger systems only ;-). Mmmm, but people keep tellink me that an embedded system has 128k of RAM and half a megabyte of flash! :-) Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-01-17 11:39 +0000 |
| Subject | Re: DOES> and flash |
| Message-ID | <52d9167a$0$9234$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #27921 |
In article <05GdnYkiIN4rakXPnZ2dnUVZ_tWdnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Bernd Paysan <bernd.paysan@gmx.de> wrote: >> >> There's already something in the (to be reviewed and rewritten) cross >> compiler proposal: We need ways to deal with the fact that there can be more >> than one contiguous memory for the dictionary, and that the properties of >> these regions differ (write-many, write-once, write-few for EEPROM). >> >> This requires adding conceptional stuff like what a write-once or write-few >> memory is, adding standard names for operators writing there (it is >> sometimes not possible to use standard ! to do so), and I think it is better >> to resurrect <BUILDS than relying on the two tricky methods I and >> Albert/Willem use. >> >> The other option for write-once memory is a combination of >> >> DOER: <name> ... ; >> >> BUILDS ( doer "name" ) >> >> where you get all the header building done in one atomic operation, and then >> there is no confusion possible about how many times you could use DOES> >> (it's an atomic operation). > >Wouldn't it make more sense to have a word that simply takes an XT and >creates a header? Or is there some implementation reason that won't >work? I suppose there'd have to be a jump from the code that pushes >the address of the child word's data, which would be a bad thing, but >the result is notationally quite nice. If you have a generic header system, then you finally would have a clean way to handle xt's. xt's are part of the problem, not the solution. > >It'd look like > >: constant [: @ ;] builds , ; > >The runtime action appears before the compile-time action. Dunno if >that matters. > >>> Knowing that stuff in ALLOCATEd memory won't change can be used for >>> optimization even if that memory is later freed. The implementation >>> of such optimizations is non-trivial, though. >>> >>> And there are also good uses of ALLOCATE for memory that will not be >>> FREEd. >> >> You won't see an ALLOCATE on a small embedded system, so the discussion >> about ALLOCATE with constant data (and complicated optimizations on those) >> certainly is for larger systems only ;-). > >Mmmm, but people keep tellink me that an embedded system has 128k of >RAM and half a megabyte of flash! :-) > >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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-17 08:16 -0600 |
| Subject | Re: DOES> and flash |
| Message-ID | <1s2dnTi3fLfJpkTPnZ2dnUVZ_t6dnZ2d@supernews.com> |
| In reply to | #27922 |
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <05GdnYkiIN4rakXPnZ2dnUVZ_tWdnZ2d@supernews.com>, > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >>Bernd Paysan <bernd.paysan@gmx.de> wrote: >>> >>> There's already something in the (to be reviewed and rewritten) cross >>> compiler proposal: We need ways to deal with the fact that there can be more >>> than one contiguous memory for the dictionary, and that the properties of >>> these regions differ (write-many, write-once, write-few for EEPROM). >>> >>> This requires adding conceptional stuff like what a write-once or write-few >>> memory is, adding standard names for operators writing there (it is >>> sometimes not possible to use standard ! to do so), and I think it is better >>> to resurrect <BUILDS than relying on the two tricky methods I and >>> Albert/Willem use. >>> >>> The other option for write-once memory is a combination of >>> >>> DOER: <name> ... ; >>> >>> BUILDS ( doer "name" ) >>> >>> where you get all the header building done in one atomic operation, and then >>> there is no confusion possible about how many times you could use DOES> >>> (it's an atomic operation). >> >>Wouldn't it make more sense to have a word that simply takes an XT and >>creates a header? Or is there some implementation reason that won't >>work? I suppose there'd have to be a jump from the code that pushes >>the address of the child word's data, which would be a bad thing, but >>the result is notationally quite nice. > > If you have a generic header system, then you finally would have > a clean way to handle xt's. xt's are part of the problem, not the > solution. I don't know what you mean. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-01-17 16:06 +0000 |
| Subject | Re: DOES> and flash |
| Message-ID | <lbbket$fkq$1@dont-email.me> |
| In reply to | #27924 |
on 17/01/2014 14:16:48, Andrew Haley wrote: > Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: >> In article <05GdnYkiIN4rakXPnZ2dnUVZ_tWdnZ2d@supernews.com>, >> Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >>>Bernd Paysan <bernd.paysan@gmx.de> wrote: >>>> >>>> There's already something in the (to be reviewed and rewritten) cross >>>> compiler proposal: We need ways to deal with the fact that there can be more >>>> than one contiguous memory for the dictionary, and that the properties of >>>> these regions differ (write-many, write-once, write-few for EEPROM). >>>> >>>> This requires adding conceptional stuff like what a write-once or write-few >>>> memory is, adding standard names for operators writing there (it is >>>> sometimes not possible to use standard ! to do so), and I think it is better >>>> to resurrect <BUILDS than relying on the two tricky methods I and >>>> Albert/Willem use. >>>> >>>> The other option for write-once memory is a combination of >>>> >>>> DOER: <name> ... ; >>>> >>>> BUILDS ( doer "name" ) >>>> >>>> where you get all the header building done in one atomic operation, and then >>>> there is no confusion possible about how many times you could use DOES> >>>> (it's an atomic operation). >>> >>>Wouldn't it make more sense to have a word that simply takes an XT and >>>creates a header? Or is there some implementation reason that won't >>>work? I suppose there'd have to be a jump from the code that pushes >>>the address of the child word's data, which would be a bad thing, but >>>the result is notationally quite nice. >> >> If you have a generic header system, then you finally would have >> a clean way to handle xt's. xt's are part of the problem, not the >> solution. > > I don't know what you mean. > > Andrew. > I suspect we're going to have a discussion about name tokens (nts).
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-18 17:21 +0000 |
| Subject | Re: DOES> and flash |
| Message-ID | <2014Jan18.182135@mips.complang.tuwien.ac.at> |
| In reply to | #27921 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Wouldn't it make more sense to have a word that simply takes an XT and
>creates a header? Or is there some implementation reason that won't
>work? I suppose there'd have to be a jump from the code that pushes
>the address of the child word's data, which would be a bad thing, but
>the result is notationally quite nice.
>
>It'd look like
>
>: constant [: @ ;] builds , ;
Nice. In particular, if we have serveral alternative behaviour
implementations for the defined words, this avoids the pretty opaque
code we need now. E.g., instead of
: imp-a DOES> code for implementation A ;
: imp-b DOES> code for implementation B ;
: def-something
create ...
some-condition if
imp-a
else
imp-b
then ;
we could write:
: def-something
some-condition if
[: code for implementation A ;]
else
[: code for implementation B ;]
then
builds ... ;
- 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-19 12:32 +0000 |
| Subject | Re: DOES> and flash |
| Message-ID | <52dbaba5.62122406@news.demon.co.uk> |
| In reply to | #27921 |
On Fri, 17 Jan 2014 03:28:22 -0600, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Mmmm, but people keep tellink me that an embedded system has 128k of >RAM and half a megabyte of flash! :-) I just could not resist the temptation to tease. However, there's a serious point in all this. The chip of choice for teaching electronics and software is probably an MSP430. It has a reasonable CPU; humans can read the data sheets and understand it; and it can be had in a DIP package. DIP packaging is important because schools (at least in the UK) use solderless breadboards which have tracks in one direction broken at the centre line. After trying it a few times, I conclude that even the smallest Cortex-M0 CPU is too complex (in terms of documentation) for school and universities students as a first CPU. TI do DIP MSP430s in the Launchpad family with programming tools. These are cheap, but have fussy USB drivers. A Launchpad typically has an MSP430G2553 CPU with 16k Flash and 512 bytes RAM. For the next step up, we can move to a Cortex of some flavour. These range from 32k Flash and 2k RAM at 24 MHz to 1/2 Mb Flash and 256 kb RAM at 180 MHz. ST do a good range of low-cost Discovery boards with integrated JTAG units. I'm not going to reopen the umbilical versus standalone Forth debate. I have developed and used both. However, the demand from people involved with education is for a standalone embedded Forth. On the topic of what to call the word that isn't CREATE and must be used with DOES>, I suggest that we call it <CREATE as it reads well and has no historical connection that I know of. Being a new name, we can add as much or as little specification as is required for a Flash system. 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-19 09:19 -0600 |
| Subject | Re: DOES> and flash |
| Message-ID | <j86dnaAVEJiIcEbPnZ2dnUVZ_sSdnZ2d@supernews.com> |
| In reply to | #27946 |
Stephen Pelc <stephenXXX@mpeforth.com> wrote: > On Fri, 17 Jan 2014 03:28:22 -0600, Andrew Haley > <andrew29@littlepinkcloud.invalid> wrote: > >>Mmmm, but people keep tellink me that an embedded system has 128k of >>RAM and half a megabyte of flash! :-) > > I just could not resist the temptation to tease. Now you say that! Andrew.
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-01-19 18:20 +0000 |
| Subject | Re: DOES> and flash |
| Message-ID | <52dc153a.89150998@news.demon.co.uk> |
| In reply to | #27949 |
On Sun, 19 Jan 2014 09:19:49 -0600, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Stephen Pelc <stephenXXX@mpeforth.com> wrote: >> On Fri, 17 Jan 2014 03:28:22 -0600, Andrew Haley >> <andrew29@littlepinkcloud.invalid> wrote: >> >>>Mmmm, but people keep tellink me that an embedded system has 128k of >>>RAM and half a megabyte of flash! :-) >> >> I just could not resist the temptation to tease. > >Now you say that! But it's also true that for low volume stuff where the CPU is not price sensitive, an STM32F4xx with 1 Mb Flash and 192 kb RAM at 180 MHz makes perfect sense. The move to 90nm devices changed the memory economics. 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-01-20 01:25 -0800 |
| Subject | Re: DOES> and flash |
| Message-ID | <7x4n4zxax3.fsf@ruckus.brouhaha.com> |
| In reply to | #27946 |
stephenXXX@mpeforth.com (Stephen Pelc) writes: > The chip of choice for teaching electronics and software is probably > an MSP430. It has a reasonable CPU; humans can read the data sheets > and understand it; and it can be had in a DIP package.... > After trying it a few times, I conclude that even the smallest > Cortex-M0 CPU is too complex (in terms of documentation) for > school and universities students as a first CPU. I wonder how the MSP430 compares to the AVR8/Atmega (and the whole Arduino world) for ease of learning. I get the impression MSP430 aims at ultra low power by (slightly) complex power control modes to deal with, while the AVR runs at an old fashioned fixed clock and keeps power fairly low by just being small. I can agree that the '430 instruction set is nicer for assembly language programming. I'd take the view that performance per se doesn't matter much or the person wouldn't be using this class of chip to begin with. FWIW, there's a nice powerful Cortex M4 board with DIP pins that fits into those solderless breadboards: http://pjrc.com/store/teensy31_pins.html
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-14 08:31 +0000 |
| Message-ID | <2014Jan14.093136@mips.complang.tuwien.ac.at> |
| In reply to | #27869 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>At risk of repeating myself, I still don't think it's worth
>resurrecting <BUILDS DOES> for
Yes, now we can discuss how to support the program-in-flash systems.
It seems that Bernd Paysan suggests adding <BUILDS and then having the
program-in-flash systems have environmental restrictions on not using
CREATE...DOES> and using DOES> on <BUILDS-created words only once.
This does not look attractive to me. I don't think it will produce a
significantly higher number of programs portable to these platforms
than the current situation.
Another idea would be to phase out CREATE...DOES> in favour of
<BUILDS...DOES> for all systems. Do the benefits of <BUILDS for the
program-in-flash systems really outweigh the costs to all programs?
Or is there a better idea for solving the problem?
- 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-01-14 01:33 -0800 |
| Message-ID | <7xr48a6h6y.fsf@ruckus.brouhaha.com> |
| In reply to | #27880 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > Yes, now we can discuss how to support the program-in-flash systems.... > Another idea would be to phase out CREATE...DOES> in favour of > <BUILDS...DOES> for all systems. Do the benefits of <BUILDS for the > program-in-flash systems really outweigh the costs to all programs? Surely there's an awful lot of code out there using CREATE DOES> by now. Can there ever be more than one CREATE at a time where the code pointer can still potentially be overwritten? Is it enough to just assign a RAM cell to hold the code pointer for the most recently created symbol, with the compiler knowing to look there for it? You'd write it out to flash when the next symbol is created. At the end of the program text you might have to type "finished" or such, to make sure that the flash for the last created word got updated. Maybe I don't understand the problem correctly.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-14 10:05 +0000 |
| Message-ID | <2014Jan14.110510@mips.complang.tuwien.ac.at> |
| In reply to | #27881 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Yes, now we can discuss how to support the program-in-flash systems....
>> Another idea would be to phase out CREATE...DOES> in favour of
>> <BUILDS...DOES> for all systems. Do the benefits of <BUILDS for the
>> program-in-flash systems really outweigh the costs to all programs?
>
>Surely there's an awful lot of code out there using CREATE DOES> by now.
Yes, changing that would be the cost. Do the benefits justify that
cost? It does not seem so to me.
>Can there ever be more than one CREATE at a time where the code pointer
>can still potentially be overwritten?
Not in standard Forth.
>Is it enough to just assign a RAM
>cell to hold the code pointer for the most recently created symbol, with
>the compiler knowing to look there for it? You'd write it out to flash
>when the next symbol is created. At the end of the program text you
>might have to type "finished" or such, to make sure that the flash for
>the last created word got updated.
Probably also falls into Bernd's "too clever" category, and it would
probably be even more complicated than what he is doing now, but it
could save the second cell even for non-DOES> CREATEd 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-14 11:58 +0000 |
| Subject | CREATE...DOES> on program-in-flash systems |
| Message-ID | <2014Jan14.125824@mips.complang.tuwien.ac.at> |
| In reply to | #27884 |
>Paul Rubin <no.email@nospam.invalid> writes:
>>Is it enough to just assign a RAM
>>cell to hold the code pointer for the most recently created symbol, with
>>the compiler knowing to look there for it? You'd write it out to flash
>>when the next symbol is created.
Pitfall:
variable foo
create bar 1 , ' bar foo !
foo @ execute @ .
create flip 2 ,
foo @ execute @ .
With the usual header organizations, the xt would change when you move
bar to its final destination; and you have no way of tracking all the
places where the xt could be stored.
Another implementation idea:
For a CREATE...DOES> word the header is in flash, the body is in RAM,
no? So for a CREATEd word the flash dictionary pointer is not moved
until the next word is defined. So we can append additional data to
the header later. We don't need to reserve a second cell from the
start, only when we see a DOES>.
I.e., the header after CREATE would look like
Other header fields (name, link, etc.)
code field: dovar
body pointer
DOES> would then change dovar to dodoes (with Bernd's clever trick),
and appends the code pointer, resulting in:
Other header fields (name, link, etc.)
code field: dodoes
body pointer
pointer to code behind DOES>
So CREATEd words don't need the extra code pointer in general, only in
connection with DOES>. Anything wrong with this idea (apart from also
using the "too clever" trick)?
- 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-01-11 08:43 -1000 |
| Message-ID | <7a6dnQKMpYlxDUzPnZ2dnUVZ_sOdnZ2d@supernews.com> |
| In reply to | #27807 |
On 1/11/14 3:31 AM, Stephen Pelc wrote: ... > Arguing that people should not want what they say they want has > never been an effective tool. We prefer to offer them both > approaches in the same package and then let them choose. The difficulty with this argument is that a lot of the "wanting" in this discussion is second hand: people wanting an environment for others to use. One person may well be happy with a very spartan programming environment, but another may have higher expectations in terms of performance, support tools, etc., particularly if there's serious programming to be done. And even if the system is for newbies, many newbies today have expectations that will be unsatisfied, and conclude that "Forth" is unusable, whereas it's really that particular implementation that has cut too many corners. I agree with your approach, of offering both, but in practice we find relatively few takers for bare-bones development. 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 | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-01-11 19:37 +0000 |
| Message-ID | <52d19d1c.1583803052@news.demon.co.uk> |
| In reply to | #27814 |
On Sat, 11 Jan 2014 08:43:56 -1000, "Elizabeth D. Rather" <erather@forth.com> wrote: >I agree with your approach, of offering both, but in practice we find >relatively few takers for bare-bones development. I agree. That's why our standalone Forths are no longer bare bones. 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]
Page 12 of 17 — ← Prev page 1 … 10 11 [12] 13 14 … 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web