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 1 of 17 [1] 2 3 … 17 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-12-28 23:39 -0800 |
| Subject | PICK changed from 1-based to 0-based? |
| Message-ID | <7xvby8f6md.fsf@ruckus.brouhaha.com> |
Someone on Stack Overflow pointed to page 27 of the Forth-79 standard, https://mywebspace.wisc.edu/lnmaurer/web/forth/Forth-79.pdf It indicates that PICK is 1-based, e.g. it says "2 PICK is equivalent to OVER". These days, PICK is 0-based, i.e. OVER is equivalent to 1 PICK. I realize PICK is frowned on regardless, but did the Forth world really accept a breaking change like this? Or is the document wrong compared to actual practice at the time?
[toc] | [next] | [standalone]
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2013-12-28 21:52 -1000 |
| Message-ID | <DK-dnUMa6-ElSSLPnZ2dnUVZ_radnZ2d@supernews.com> |
| In reply to | #27495 |
On 12/28/2013 9:39 PM, Paul Rubin wrote: > Someone on Stack Overflow pointed to page 27 of the Forth-79 standard, > > https://mywebspace.wisc.edu/lnmaurer/web/forth/Forth-79.pdf > > It indicates that PICK is 1-based, e.g. it says "2 PICK is equivalent to > OVER". > > These days, PICK is 0-based, i.e. OVER is equivalent to 1 PICK. > > I realize PICK is frowned on regardless, but did the Forth world really > accept a breaking change like this? Or is the document wrong compared > to actual practice at the time? > It happened in Forth83. The predominant philosophy of that committee was, "current usage be damned, we'll make things work RIGHT!". PICK was one of the less-traumatic changes. From the Forth94 description of changes from prior standards: "Forth 83 was similar to Forth 79 in most respects. However, Forth 83 changed the definition of several well-defined features of Forth 79. For example, the rounding behavior of integer division, the base value of the operands of PICK and ROLL, the meaning of the address returned by ', the compilation behavior of ', the value of a “true” flag, the meaning of NOT, and the “chaining” behavior of words defined by VOCABULARY were all changed. Forth 83 relaxed the implementation restrictions of Forth 79 to allow any kind of threaded code, but it did not fully allow compilation to native machine code (this was not specifically prohibited, but rather was an indirect consequence of another provision)." 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 | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2013-12-29 11:28 +0100 |
| Message-ID | <52bff96e$0$2861$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #27496 |
Elizabeth D Rather wrote: > "Forth 83 was similar to Forth 79 in most respects. However, Forth 83 > changed the definition of several well-defined features of Forth 79. For > example, the rounding behavior of integer division, the base value of > the operands of PICK and ROLL, the meaning of the address returned by ', > the compilation behavior of ', the value of a “true” flag, the meaning > of NOT, and the “chaining” behavior of words defined by VOCABULARY were > all changed. Forth 83 relaxed the implementation restrictions of Forth > 79 to allow any kind of threaded code, but it did not fully allow > compilation to native machine code (this was not specifically > prohibited, but rather was an indirect consequence of another provision)." Forth-83 is where Forth IMHO went wrong. In every high level programming language there are concepts and abstractions. E.g. when you write in C: argv[1][1] There is no twodimensional matrix somewhere in memory space, but the abstraction allows you to think that way. Some abstractions are very elaborate, like OO - or did you really think there was an object floating somewhere in memory with all its methods attached like a swiss army knife? What people essentially did in Forth-83 was to strip most/some/all intuitive concepts of Forth and turn it into a somewhat glorified assembler. "falling through" in a loop concept like DO..LOOP. Turning "true" into an "all bits set" value - just because you could do some obfuscated binary tricks with it. I can forgive them for PICK and ROLL because no Forther in his right mind would use these. Unfortunately, although ANS-94 fixed some of these, a lot of 'em are still there. Add to that some C-type "bolt on" constructs and you got the mess we are in now. Current developments? One step ahead, two steps back. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | "Ed" <invalid@invalid.com> |
|---|---|
| Date | 2013-12-29 23:12 +1100 |
| Message-ID | <l9p3kp$gjp$1@speranza.aioe.org> |
| In reply to | #27497 |
Hans Bezemer wrote: > ... > I can forgive them for PICK and ROLL because no Forther in his right > mind would use these. I needed and defined -ROLL. SwiftForth has them too :)
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-12-29 07:45 -0600 |
| Message-ID | <x6Gdncg0V-wYul3PnZ2dnUVZ_vWdnZ2d@supernews.com> |
| In reply to | #27497 |
Hans Bezemer <the.beez.speaks@gmail.com> wrote: > Forth-83 is where Forth IMHO went wrong. [ ... ] > > What people essentially did in Forth-83 was to strip most/some/all > intuitive concepts of Forth and turn it into a somewhat glorified > assembler. "falling through" in a loop concept like > DO..LOOP. Turning "true" into an "all bits set" value - just because > you could do some obfuscated binary tricks with it. I can forgive > them for PICK and ROLL because no Forther in his right mind would > use these. Some of the big changes were essential, though: we couldn't live with 16-bit threaded code forever. The 83-standard DO..LOOP was undoubtedly a mistake, but what possible damage did "all bits set" do? How is it unintuitive? PICK and ROLL don't matter. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2013-12-29 18:33 +0100 |
| Message-ID | <52c05cfd$0$2919$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #27503 |
Andrew Haley wrote: > <snip> but what possible damage did "all bits set" do? > How is it unintuitive? Because it feels like a feeble attempt to (a) eradicate the difference between "logical" and "binary" values and (b) to abuse a logical value as a mask for some fancy binary tricks. It's the same kind of attitude that makes people abuse COUNT as C@+ and attributes to Forths reputation as an "unmaintainable" and "write-only" language. In ANS-Forth the 'TRUE' has the value "-1", which means all bits are set. Which is very clever. You can 'XOR', 'OR', 'AND' and 'INVERT' it with any other value and it will behave as logical value. But "the all bits set" flag has its drawbacks too. Let's see what the ANS-Forth standard says about flags: "A FALSE flag is a single-cell datum with all bits unset, and a TRUE flag is a single-cell datum with all bits set. While Forth words which test flags accept any non-null bit pattern as true, there exists the concept of the well-formed flag. If an operation whose result is to be used as a flag may produce any bit-mask other than TRUE or FALSE, the recommended discipline is to convert the result to a well-formed flag by means of the Forth word 0<> so that the result of any subsequent logical operations on the flag will be predictable. In addition to the words which move, fetch and store single-cell items, the following words are valid for operations on one or more flag data residing on the data stack: AND OR XOR INVERT" I highly recommend the discipline of converting a non-zero value to a well-formed flag. But I don't understand why 'INVERT' is a valid way to manipulate a flag. I'll try to explain you why. Forth traditionally has no specific logical operators. Instead, binary operators were used. This put 'INVERT' (or 'NOT' as it was called in Forth-79) in a difficult position. 'INVERT'ing any non-zero value will result in a non-zero value, except when all bits are set. That is why '0=' was introduced, a full-fledged logical operator. So why use 'INVERT' when you want to perform a logical operation? Another quote: "Since a "char" can store small positive numbers and since the character data type is a sub-range of the unsigned integer data type, C! must store the n least-significant bits of a cell (8 <= n <= bits/cell). Given the enumeration of allowed number representations and their known encodings, "TRUE xx C! xx C@" must leave a stack item with some number of bits set, which will thus will be accepted as non-zero by IF." This is another problem of using "all bits set" as a true flag: you store a well formed flag in an address unit that should easily be able to handle it and you'll never get it back. A flag is a boolean and can have two values: either true or false. The smallest unit that can hold a boolean is a bit. But why are some Forth programmers so keen on their "all bits set" flag? Well, you can do neat things with it. : >CHAR DUP 9 > 7 AND + ASCII 0 + ; This will convert a digit to its ASCII representation. True, it is a clever piece of programming, but in my opinion it is bad style. Why? Because you are using a flag as a bitmask, which is a completely different datatype. Although there is no such thing as "data typing" in Forth, this way of programming makes it difficult to understand and maintain a program, which the ANS-Forth standard acknowledges: "The discipline of circumscribing meaning which a program may assign to various combinations of bit patterns is sometimes called data typing. Many computer languages impose explicit data typing and have compilers that prevent ill-defined operations. Forth rarely explicitly imposes data-type restrictions. Still, data types implicitly do exist, and discipline is required, particularly if portability of programs is a goal. In Forth, it is incumbent upon the programmer (rather than the compiler) to determine that data are accurately typed." I would applaud it if Forth would feature some true logical operators, because the return values of AND, OR and INVERT are not guaranteed to be well-formed flags UNLESS their input were BOTH well-formed flags. Simple maintenance can easily introduce subtle bugs which are hard to track. Not to mention it obfuscates the intentions of the programmer - like using COUNT for C@+. I *never ever* use INVERT for inverting a flag - that's what 0= is for. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-12-29 16:57 -0600 |
| Message-ID | <ycOdnXu0crJxNV3PnZ2dnUVZ_r2dnZ2d@supernews.com> |
| In reply to | #27510 |
Hans Bezemer <the.beez.speaks@gmail.com> wrote: > Andrew Haley wrote: > >> <snip> but what possible damage did "all bits set" do? >> How is it unintuitive? > Because it feels like a feeble attempt to (a) eradicate the difference > between "logical" and "binary" values and (b) to abuse a logical value as a > mask for some fancy binary tricks. > > It's the same kind of attitude that makes people abuse COUNT as C@+ and > attributes to Forths reputation as an "unmaintainable" and "write-only" > language. > > In ANS-Forth the 'TRUE' has the value "-1", which means all bits are set. No, it doesn't, except by accident. It has the value 11111111... or FFFF.... > That is why '0=' was introduced, a full-fledged logical operator. So > why use 'INVERT' when you want to perform a logical operation? Because NOT, which IMO is the correct name for this purpose, could not be standardized. > But why are some Forth programmers so keen on their "all bits set" > flag? Well, you can do neat things with it. > > : >CHAR DUP 9 > 7 AND + ASCII 0 + ; > > This will convert a digit to its ASCII representation. True, it is a > clever piece of programming, but in my opinion it is bad style. Why? > Because you are using a flag as a bitmask, which is a completely > different datatype. But it's not a different datatype in Standard Forth: it's a well-formed flag, which is defined to be all ones or all zeroes. It maye be a different datatype in other languages. > Although there is no such thing as "data typing" in Forth, this way > of programming makes it difficult to understand and maintain a > program, which the ANS-Forth standard acknowledges: > > "The discipline of circumscribing meaning which a program may assign > to various combinations of bit patterns is sometimes called data > typing. Many computer languages impose explicit data typing and have > compilers that prevent ill-defined operations. Forth rarely > explicitly imposes data-type restrictions. Still, data types > implicitly do exist, and discipline is required, particularly if > portability of programs is a goal. In Forth, it is incumbent upon > the programmer (rather than the compiler) to determine that data are > accurately typed." Indeed. So, it all depends on what you think the datatype of a well- formed flag is. The type of the result of a comparison in Forth is not a boolean -- it's a well-formed flag, which is a cell. > I would applaud it if Forth would feature some true logical > operators, because the return values of AND, OR and INVERT are not > guaranteed to be well-formed flags UNLESS their input were BOTH > well-formed flags. Following the logic of this argument, it seems to me you are saying that you *do not care* what the value for TRUE is because none of your programs will assume anything about it, other than that you want it to fit in a byte. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2013-12-30 00:25 +0100 |
| Message-ID | <52c0af58$0$2957$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #27515 |
Andrew Haley wrote: > Following the logic of this argument, it seems to me you are saying > that you *do not care* what the value for TRUE is because none of your > programs will assume anything about it, other than that you want it to > fit in a byte. Yes and no. No, none of my programs assume ANY value of TRUE, since they all work with "well-formed flags". Consequently, I have no trouble "porting" them to Forth. However, the other way around I find many Forth programs who DO assume that TRUE has a certain value (examples given) - which makes my life a lot harder. Like the people who abuse COUNT. Fortunately, I have to clean it up only once. I think this despicable attitude towards programming holds back Forth in several ways. Not the least the people why cry out when someone comes with a proposal to clean up the mess - because they have a lot of badly written legacy code to maintain. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | "Ed" <invalid@invalid.com> |
|---|---|
| Date | 2014-01-01 13:29 +1100 |
| Message-ID | <l9vuvc$ova$1@speranza.aioe.org> |
| In reply to | #27510 |
Hans Bezemer wrote: > ... > I highly recommend the discipline of converting a non-zero value to a > well-formed flag. But surely only if it's necessary. Consider the situation in which two flags must be tested before continuing. Under 83/94 there is a high probability one of them will be "fully-formed" in which case they can simply be ANDed. One couldn't do that if 'true' was 1. When I encounter the above situation (which occurs not infrequently), I give thanks 'true' is all bits set - otherwise I'd have to apply 0<> which would waste processor time. Thinking Forth says: 'don't decide, calculate'. It's acknowledgment that everything on the stack, including flags, are just numbers to be exploited.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-01-01 14:18 +0000 |
| Message-ID | <52c423c0$0$25047$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #27573 |
In article <l9vuvc$ova$1@speranza.aioe.org>, Ed <invalid@invalid.com> wrote: >Hans Bezemer wrote: >> ... >> I highly recommend the discipline of converting a non-zero value to a >> well-formed flag. > >But surely only if it's necessary. > >Consider the situation in which two flags must be tested before continuing. >Under 83/94 there is a high probability one of them will be "fully-formed" >in which case they can simply be ANDed. One couldn't do that if 'true' was 1. That is the situation where this practice is most dangerous. I don't bother using IF on the result of a link field, but if you AND while one of the flags is not proper you may be lulled into believing the result is a well-formed flag. On the other hand `` (flag) DUP a OR SWAP INVERT b OR '' is fast and idiomatic in my book, whatever Hans says. >When I encounter the above situation (which occurs not infrequently), I give >thanks 'true' is all bits set - otherwise I'd have to apply 0<> which >would waste >processor time. > >Thinking Forth says: 'don't decide, calculate'. It's acknowledgment that >everything on the stack, including flags, are just numbers to be exploited. Agreed with that! Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2014-01-01 15:46 +0100 |
| Message-ID | <52c42a4b$0$2867$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #27577 |
Albert van der Horst wrote: > On the other hand `` (flag) DUP a OR SWAP INVERT b OR '' is fast and > idiomatic in my book, whatever Hans says. I couldn't find a single occurrence of "OR SWAP INVERT" in the entire c.l.f. Either you haven't posted that much code or it isn't that idiomatic. ;-) Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2014-01-01 15:26 +0100 |
| Message-ID | <52c42581$0$2875$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #27573 |
Ed wrote: > But surely only if it's necessary. I usually DON'T before a test (IF, WHILE). There is a difference between being "thorough and solid" and "pedantic" ;-) When dealing with the AND and OR abominations, I very rarely do not. > Consider the situation in which two flags must be tested before > continuing. Under 83/94 there is a high probability one of them will be > "fully-formed" > in which case they can simply be ANDed. One couldn't do that if 'true' > was 1. > > When I encounter the above situation (which occurs not infrequently), I > give thanks 'true' is all bits set - otherwise I'd have to apply 0<> which > would waste processor time. I could easily give you situations where 1 has the advantage (as a matter of fact, I started such an example). However, the basis of my case is not whether a majority of cases favor one or the other solution - it's how solid its conceptual foundation is. > Thinking Forth says: 'don't decide, calculate'. It's acknowledgment that > everything on the stack, including flags, are just numbers to be > exploited. Very true and a solid principle in itself, I consider this the party trick department. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | "Ed" <invalid@invalid.com> |
|---|---|
| Date | 2014-01-03 13:22 +1100 |
| Message-ID | <la56uo$a9c$1@speranza.aioe.org> |
| In reply to | #27578 |
Hans Bezemer wrote: > Ed wrote: > > > But surely only if it's necessary. > I usually DON'T before a test (IF, WHILE). There is a difference between > being "thorough and solid" and "pedantic" ;-) When dealing with the AND and > OR abominations, I very rarely do not. > > > Consider the situation in which two flags must be tested before > > continuing. Under 83/94 there is a high probability one of them will be > > "fully-formed" > > in which case they can simply be ANDed. One couldn't do that if 'true' > > was 1. > > > > When I encounter the above situation (which occurs not infrequently), I > > give thanks 'true' is all bits set - otherwise I'd have to apply 0<> which > > would waste processor time. > I could easily give you situations where 1 has the advantage (as a matter of > fact, I started such an example). However, the basis of my case is not > whether a majority of cases favor one or the other solution - it's how > solid its conceptual foundation is. Forth is empirically based. It matters whether a majority of cases favour a particular solution. It was this that drove the decision to make PICK and ROLL zero-based - even at the expense of breaking code. Short-term pain for long-term gain. Floored integer division favoured the majority of cases but completely ignored the reality of hardware division which was symmetric. The result - long-term pain. > > Thinking Forth says: 'don't decide, calculate'. It's acknowledgment that > > everything on the stack, including flags, are just numbers to be > > exploited. > Very true and a solid principle in itself, I consider this the party trick > department. ISTM it can't be both. Either it's a party trick or an efficient practice, albeit one wherein only certain languages derive gain.
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2014-01-03 11:54 +0100 |
| Message-ID | <52c696ce$0$2930$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #27616 |
Ed wrote: > Forth is empirically based. It matters whether a majority of cases favour > a particular solution. It was this that drove the decision to make PICK > and ROLL zero-based - even at the expense of breaking code. Short-term > pain for long-term gain. Floored integer division favoured the majority > of cases but completely ignored the reality of hardware division which was > symmetric. The result - long-term pain. I'd say it is opportunistically based. "Hey, every major system has 16 bits. Let's make all cells 16 bits." Worst decision EVER! Completely pragmatic and visionless. "Hey, we can't reach our entire address range with LOOP. Let's violate sane design so we can." "Hey, we need to work with ordinary files. Let's completely ignore proper design and glue an entire C library on top of it." "Hey, we need to define a CORE system. Let's simply see what we use on an average day and mix our special brew of unsigned, mixed, double and single words together and call it CORE". And so on, and on and on. Long term pain - like ordinary program design - is avoided by vision, architecture and a proper design - not "what feels good at the moment to the majority". > ISTM it can't be both. Either it's a party trick or an efficient > practice, albeit one wherein only certain languages derive gain. An efficient practice has its proper roots in mathematics and architecture. A party trick is coincidental specific behavior resulting from the inappropriate use of a datatype or algorithm. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | "Ed" <invalid@invalid.com> |
|---|---|
| Date | 2014-01-06 10:57 +1100 |
| Message-ID | <lacs2r$7jb$1@speranza.aioe.org> |
| In reply to | #27624 |
Hans Bezemer wrote: > Ed wrote: > > > Forth is empirically based. It matters whether a majority of cases favour > > a particular solution. It was this that drove the decision to make PICK > > and ROLL zero-based - even at the expense of breaking code. Short-term > > pain for long-term gain. Floored integer division favoured the majority > > of cases but completely ignored the reality of hardware division which was > > symmetric. The result - long-term pain. > I'd say it is opportunistically based. "Hey, every major system has 16 bits. > Let's make all cells 16 bits." Worst decision EVER! Completely pragmatic > and visionless. "Hey, we can't reach our entire address range with LOOP. > Let's violate sane design so we can." "Hey, we need to work with ordinary > files. Let's completely ignore proper design and glue an entire C library > on top of it." "Hey, we need to define a CORE system. Let's simply see what > we use on an average day and mix our special brew of unsigned, mixed, > double and single words together and call it CORE". And so on, and on and > on. Long term pain - like ordinary program design - is avoided by vision, > architecture and a proper design - not "what feels good at the moment to > the majority". > ... As you've mentioned it I have to ask. What do you find wrong with the ANS file functions - and what would you use instead? My impression is the ANS functions are more straightforward than C's. Apart from some debatable items, they do what's necessary and can be implemented in environments as hostile as CP/M with ease and efficiency (much to my surprise I might add).
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-01-03 14:07 +0100 |
| Message-ID | <la6cnl$8r9$1@online.de> |
| In reply to | #27616 |
Ed wrote: > Forth is empirically based. It matters whether a majority of cases favour > a particular solution. It was this that drove the decision to make PICK > and ROLL zero-based - even at the expense of breaking code. Short-term > pain for long-term gain. Floored integer division favoured the majority > of cases but completely ignored the reality of hardware division which was > symmetric. The result - long-term pain. Actually, the pain you pay here is not existing. Symmetric hardware division is actually generated code by the decoder, which uses the internal unsigned division algorithm and some conditional code to fix the sign. If you write this down for floored division, it is about as fast as the hardware symmetric division. If you use Forth Inc's floored division (divide by unsigned), you are even faster than the symmetric hardware division. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Ed" <invalid@invalid.com> |
|---|---|
| Date | 2014-01-06 12:42 +1100 |
| Message-ID | <lad28g$kil$1@speranza.aioe.org> |
| In reply to | #27629 |
Bernd Paysan wrote: > Ed wrote: > > Forth is empirically based. It matters whether a majority of cases favour > > a particular solution. It was this that drove the decision to make PICK > > and ROLL zero-based - even at the expense of breaking code. Short-term > > pain for long-term gain. Floored integer division favoured the majority > > of cases but completely ignored the reality of hardware division which was > > symmetric. The result - long-term pain. > > Actually, the pain you pay here is not existing. Symmetric hardware > division is actually generated code by the decoder, which uses the internal > unsigned division algorithm and some conditional code to fix the sign. If > you write this down for floored division, it is about as fast as the > hardware symmetric division. Even if the timings were similar, why would anyone choose to write a division routine when opcode for it was sitting there in hardware ready to use with exceptions automatically handled and documented. With rare exception, no-one would. When it comes to implementing floored division those with hardware division base it on the signed division instruction, not unsigned, for the same reasons. > If you use Forth Inc's floored division > (divide by unsigned), you are even faster than the symmetric hardware > division. A nice technique but 83/94 "floored division" requires *signed* divisors. Also it's not possible to detect overflows IIRC.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-03 14:22 +0000 |
| Message-ID | <2014Jan3.152213@mips.complang.tuwien.ac.at> |
| In reply to | #27616 |
"Ed" <invalid@invalid.com> writes:
>Forth is empirically based. It matters whether a majority of cases favour a
>particular solution. It was this that drove the decision to make PICK and
>ROLL zero-based - even at the expense of breaking code.
Please enlighten me about the empirical basis of "zero-based" PICK and
ROLL.
>Short-term
>pain for long-term gain.
Long-term pain for no gain.
>Floored integer division favoured the majority of
>cases but completely ignored the reality of hardware division which was
>symmetric. The result - long-term pain.
What pain? Gforth changed division from platform-specific (but
probably symmetric everywhere) to floored (symmetric could be chosen
as a build option), and nobody complained. The performanc impact was
small even for pure division microbenchmarks:
From <2007Jan26.165751@mips.complang.tuwien.ac.at>
| development 0.6.2
| floored symmetric symmetric
|/ 194 ms 181 ms 175 ms
|mod 197 ms 181 ms 175 ms
|/mod 193 ms 183 ms 175 ms
|*/ 252 ms 250 ms 908 ms
|*/mod 258 ms 259 ms 885 ms
|fm/mod 278 ms 277 ms 1283 ms
|sm/rem 196 ms 196 ms 1215 ms
|um/mod 235 ms 235 ms 693 ms
|m*/ 2018 ms 1764 ms 2373 ms
- 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-03 09:06 -0800 |
| Message-ID | <7xzjnd5713.fsf@ruckus.brouhaha.com> |
| In reply to | #27638 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > Gforth changed division from platform-specific (but probably symmetric > everywhere) to floored... and nobody complained. The performance > impact was small even for pure division microbenchmarks: That's probably because of interpreter overhead. In (compiled) ghc, `quot` (symmetric) is significantly faster than `mod` (floored), enough to make a real difference in the running speed of certain programs. Otherwise quot is ugly and it would sure be nice if cpus implemented floored division directly.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-03 11:10 -0600 |
| Message-ID | <RcWdnYcol7J1c1vPnZ2dnUVZ_hudnZ2d@supernews.com> |
| In reply to | #27644 |
Paul Rubin <no.email@nospam.invalid> wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> Gforth changed division from platform-specific (but probably symmetric >> everywhere) to floored... and nobody complained. The performance >> impact was small even for pure division microbenchmarks: > > That's probably because of interpreter overhead. In (compiled) ghc, > `quot` (symmetric) is significantly faster than `mod` (floored), enough > to make a real difference in the running speed of certain programs. I suspect that's an implmentation problem, nothing to do with the actual machine. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 1 of 17 [1] 2 3 … 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web