Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #32301 > unrolled thread
| Started by | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| First post | 2014-07-10 02:35 -0700 |
| Last post | 2014-07-13 09:57 -0700 |
| Articles | 20 on this page of 161 — 28 participants |
Back to article view | Back to comp.lang.forth
Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-10 02:35 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-10 17:18 +0200
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-10 08:41 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-10 17:55 +0200
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-10 19:53 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded jacko <jackokring@gmail.com> - 2014-07-15 05:15 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-10 09:02 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Elizabeth D. Rather" <erather@forth.com> - 2014-07-10 15:45 -1000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-10 21:44 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Elizabeth D. Rather" <erather@forth.com> - 2014-07-10 18:53 -1000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-11 12:59 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-11 09:33 -0500
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Elizabeth D. Rather" <erather@forth.com> - 2014-07-11 07:33 -1000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded visualforth@rocketmail.com - 2014-07-11 20:32 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Elizabeth D Rather <erather@forth.com> - 2014-07-11 18:02 -1000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-07-12 11:54 +0100
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded rickman <gnuarm@gmail.com> - 2014-07-20 23:41 -0400
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Elizabeth D. Rather" <erather@forth.com> - 2014-07-20 21:09 -1000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Mark Wills <markwills1970@gmail.com> - 2014-07-11 00:59 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded bruce.mcfarling@gmail.com - 2014-07-10 09:06 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-10 11:12 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded BruceMcF <agila61@netscape.net> - 2014-07-10 11:30 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-10 11:59 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded mhx@iae.nl - 2014-07-10 12:54 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded bruce.mcfarling@gmail.com - 2014-07-10 12:56 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded bruce.mcfarling@gmail.com - 2014-07-10 13:19 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Coos Haak <chforth@hccnet.nl> - 2014-07-10 23:01 +0200
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded bruce.mcfarling@gmail.com - 2014-07-10 16:29 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Coos Haak <chforth@hccnet.nl> - 2014-07-11 02:15 +0200
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded bruce.mcfarling@gmail.com - 2014-07-10 20:00 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Elizabeth D. Rather" <erather@forth.com> - 2014-07-10 17:56 -1000
Implementing UM/MOD (was: Forth16e, Forth32e, ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-11 12:12 +0000
Re: Implementing UM/MOD (was: Forth16e, Forth32e, ...) bruce.mcfarling@gmail.com - 2014-07-11 07:41 -0700
Re: Implementing UM/MOD (was: Forth16e, Forth32e, ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-11 15:56 +0000
Re: Implementing UM/MOD (was: Forth16e, Forth32e, ...) bruce.mcfarling@gmail.com - 2014-07-11 09:26 -0700
Re: Implementing UM/MOD AKK <akk@nospam.org> - 2014-07-11 20:05 +0200
Re: Implementing UM/MOD (was: Forth16e, Forth32e, ...) bruce.mcfarling@gmail.com - 2014-07-12 01:38 -0700
Re: Implementing UM/MOD (was: Forth16e, Forth32e, ...) bruce.mcfarling@gmail.com - 2014-07-12 02:00 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-13 09:31 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded bruce.mcfarling@gmail.com - 2014-07-13 07:02 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-13 09:35 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded bruce.mcfarling@gmail.com - 2014-07-13 10:02 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-13 12:18 -0500
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-13 10:45 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Elizabeth D. Rather" <erather@forth.com> - 2014-07-13 08:06 -1000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Elizabeth D. Rather" <erather@forth.com> - 2014-07-13 08:02 -1000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-07-11 10:28 +0100
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded bruce.mcfarling@gmail.com - 2014-07-11 06:28 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-10 20:18 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-07-12 19:01 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-07-15 22:18 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-16 00:01 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-07-16 18:25 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Alexander Skobelev <al.skobelev@gmail.com> - 2014-07-17 10:21 +0400
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-07-17 15:56 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Alexander Skobelev <al.skobelev@gmail.com> - 2014-07-18 09:35 +0400
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-17 00:32 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-17 00:36 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-07-17 16:52 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Elizabeth D. Rather" <erather@forth.com> - 2014-07-16 22:55 -1000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-07-17 16:34 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded stephenXXX@mpeforth.com (Stephen Pelc) - 2014-07-18 14:30 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-18 14:40 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Alex McDonald" <blog@rivadpm.com> - 2014-07-18 17:05 +0200
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-18 17:26 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Alex McDonald" <blog@rivadpm.com> - 2014-07-19 22:31 +0200
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-21 15:14 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-19 00:37 +0200
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Paul Rubin <no.email@nospam.invalid> - 2014-07-18 16:30 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-19 01:40 +0200
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Paul Rubin <no.email@nospam.invalid> - 2014-07-18 17:00 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-07-19 16:36 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-19 21:36 -0400
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-07-19 21:05 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-21 02:01 -0400
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-20 06:09 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-20 06:25 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-07-20 22:11 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-20 22:47 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Elizabeth D. Rather" <erather@forth.com> - 2014-07-20 21:02 -1000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-07-21 21:54 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-22 03:47 -0400
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-22 01:06 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-22 01:12 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-22 04:25 -0400
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded bruce.mcfarling@gmail.com - 2014-07-22 20:41 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Elizabeth D. Rather" <erather@forth.com> - 2014-07-22 08:25 -1000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-07-22 19:15 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-23 04:23 -0400
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Lars Brinkhoff <lars.spam@nocrew.org> - 2014-07-23 12:48 +0200
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-07-21 21:35 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-21 23:53 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-07-22 18:11 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-22 22:08 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-22 22:22 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-23 03:27 -0500
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-07-24 19:00 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-25 03:51 -0500
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded jkn_gg@nicorp.f9.co.uk - 2014-07-25 04:50 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Mark Wills <markwills1970@gmail.com> - 2014-07-25 08:11 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-07-25 23:01 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Mark Wills <markwills1970@gmail.com> - 2014-07-26 04:13 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-26 08:02 -0400
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Elizabeth D. Rather" <erather@forth.com> - 2014-07-25 13:10 -0400
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-07-25 23:09 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-22 03:45 -0400
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-21 01:59 -0400
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-21 12:41 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-21 08:42 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded BruceMcF <agila61@netscape.net> - 2014-07-20 09:28 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-21 02:01 -0400
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-19 20:05 -0400
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded rickman <gnuarm@gmail.com> - 2014-09-20 04:30 -0400
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-20 18:15 -0400
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-09-21 06:48 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-21 20:50 -0400
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-09-21 20:38 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-21 08:37 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded stephenXXX@mpeforth.com (Stephen Pelc) - 2014-07-20 11:45 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-07-20 19:55 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-21 15:10 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded stephenXXX@mpeforth.com (Stephen Pelc) - 2014-07-21 16:34 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-22 10:53 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded stephenXXX@mpeforth.com (Stephen Pelc) - 2014-07-22 14:42 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-23 15:50 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded BruceMcF <agila61@netscape.net> - 2014-07-23 16:40 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-24 14:08 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded bruce.mcfarling@gmail.com - 2014-07-25 06:36 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-07-18 22:59 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-19 11:17 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-07-19 17:04 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-19 21:38 -0400
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-17 10:16 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-07-17 16:13 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded mhx@iae.nl - 2014-07-19 08:04 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded bruce.mcfarling@gmail.com - 2014-07-16 20:51 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded hughaguilar96@yahoo.com - 2014-07-27 21:08 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-10 20:12 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded bruce.mcfarling@gmail.com - 2014-07-10 13:49 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded "Elizabeth D. Rather" <erather@forth.com> - 2014-07-10 11:31 -1000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded bruce.mcfarling@gmail.com - 2014-07-10 16:30 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Mark Wills <markwills1970@gmail.com> - 2014-07-11 01:11 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-10 21:30 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Coos Haak <chforth@hccnet.nl> - 2014-07-10 21:57 +0200
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded rickman <gnuarm@gmail.com> - 2014-07-20 23:47 -0400
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-10 12:48 -0500
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-10 11:33 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-10 23:35 +0200
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-10 21:51 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-07-11 12:30 +0200
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-07-11 11:56 +0100
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-11 07:08 -0500
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-07-12 18:46 +0100
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-07-14 15:50 +0200
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded BruceMcF <agila61@netscape.net> - 2014-07-11 17:50 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded bruce.mcfarling@gmail.com - 2014-07-14 17:32 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-12 21:56 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded bruce.mcfarling@gmail.com - 2014-07-12 23:12 -0700
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-13 10:42 +0000
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-13 13:54 +0200
Re: Forth16e, Forth32e, "de facto" forth programming standards for embedded bruce.mcfarling@gmail.com - 2014-07-13 09:57 -0700
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-21 15:10 +0000 |
| Message-ID | <2014Jul21.171044@mips.complang.tuwien.ac.at> |
| In reply to | #32484 |
Paul Rubin <no.email@nospam.invalid> writes:
>It's nice if
>floats and ints fit in the same cells.
Not in my experience. Apart from occasional alignment considerations
(which would be better handled with a word MAXALIGNED rather than by
making cells and floats the same size), I have not noticed situations
where I had even the faintest desired for 1 FLOATS=1 CELLS.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-07-21 16:34 +0000 |
| Message-ID | <53cd4035.1088032155@news.demon.co.uk> |
| In reply to | #32484 |
On Fri, 18 Jul 2014 17:00:49 -0700, Paul Rubin <no.email@nospam.invalid> wrote: >Bernd Paysan <bernd.paysan@gmx.de> writes: >> The last is a non-issue here, floating points don't become bigger (or double >> calculations don't become faster) when you use the 64 bit mode of x86-64. > >Well I thought this was also about the Forth cell size. It's nice if >floats and ints fit in the same cells. For many real world *users* 64 floats are a source of error. 128 bit IEEE float libraries exist. A very few machines implement it in hardware. I would hazard a guess that 64 bit ints are not a practical solution to overflows, but 128 bit ints are close to it. This if you want the same cell size, a 128 bit cell is the sensible choice. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-22 10:53 +0000 |
| Message-ID | <2014Jul22.125353@mips.complang.tuwien.ac.at> |
| In reply to | #32521 |
stephenXXX@mpeforth.com (Stephen Pelc) writes:
>I would hazard a guess that 64 bit ints are not a practical solution
>to overflows, but 128 bit ints are close to it.
64 bit integers are also close to it. My guess is that 128 bit
integers are hardly closer, i.e., if your integers exceed 64 bits, you
probably need unlimited integers, because you are doing number
theoretic work.
Evidence for my guess: There are languages that define 64-bit integers
(e.g., int64_t in C), and languages that have unlimited integers
(Python etc.), but I don't know of any that define 128-bit integers.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-07-22 14:42 +0000 |
| Message-ID | <53ce76c9.1167540124@news.demon.co.uk> |
| In reply to | #32542 |
On Tue, 22 Jul 2014 10:53:53 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >Evidence for my guess: There are languages that define 64-bit integers >(e.g., int64_t in C), and languages that have unlimited integers >(Python etc.), but I don't know of any that define 128-bit integers. There are applications that use 96 and 128 bit ints in Forth because the applications *need* that many bits. I'm sure that the same is true in C and other languages. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-23 15:50 +0000 |
| Message-ID | <2014Jul23.175035@mips.complang.tuwien.ac.at> |
| In reply to | #32544 |
stephenXXX@mpeforth.com (Stephen Pelc) writes:
>On Tue, 22 Jul 2014 10:53:53 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>Evidence for my guess: There are languages that define 64-bit integers
>>(e.g., int64_t in C), and languages that have unlimited integers
>>(Python etc.), but I don't know of any that define 128-bit integers.
>
>There are applications that use 96 and 128 bit ints in Forth
>because the applications *need* that many bits.
These are the exceptions that prove the rule.
>I'm sure that
>the same is true in C and other languages.
And yet I have heard about multiprecision libraries for C, but not
about 128-bit libraries. Apparently the demand for 128 bits but not
more is relatively small.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2014-07-23 16:40 -0700 |
| Message-ID | <55490b61-1975-4bef-a57c-fec21bddb0e8@googlegroups.com> |
| In reply to | #32573 |
On Wednesday, July 23, 2014 11:50:35 AM UTC-4, Anton Ertl wrote: > And yet I have heard about multiprecision libraries for C, but not > about 128-bit libraries. Apparently the demand for 128 bits but not > more is relatively small. Or perhaps existing multi-precision libraries is what those who need 128 bits turn to, so there is no particular residual demand for a 128-bit-only library.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-24 14:08 +0000 |
| Message-ID | <2014Jul24.160830@mips.complang.tuwien.ac.at> |
| In reply to | #32592 |
BruceMcF <agila61@netscape.net> writes:
>On Wednesday, July 23, 2014 11:50:35 AM UTC-4, Anton Ertl wrote:
>> And yet I have heard about multiprecision libraries for C, but not
>> about 128-bit libraries. Apparently the demand for 128 bits but not
>> more is relatively small.
>
>Or perhaps existing multi-precision libraries is what those who need 128 bits turn to, so there is no particular residual demand for a 128-bit-only library.
Yes, maybe. Multi-precision is probably quite a bit slower than fixed
128 bits, but I guess the number of performance-sensitive applications
for >64 but <128 bit integers is really small.
In any case, we have the systems for these kinds of applications:
64-bit Forth systems, with their doubles (and we have had them for at
least 19 years (11 years on PCs)). I have not heard of people
flocking to Forth for that reason.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-25 06:36 -0700 |
| Message-ID | <ac2f6fb9-92e0-49dd-b13f-c702b43076a5@googlegroups.com> |
| In reply to | #32620 |
On Thursday, July 24, 2014 10:08:30 AM UTC-4, Anton Ertl wrote: > BruceMcF writes: >>On Wednesday, July 23, 2014 11:50:35 AM UTC-4, Anton Ertl wrote: >>> And yet I have heard about multiprecision libraries for C, but not >>> about 128-bit libraries. Apparently the demand for 128 bits but not >>> more is relatively small. >> >>Or perhaps existing multi-precision libraries is what those who need 128 bits turn to, so there is no particular residual demand for a 128-bit-only library. > Yes, maybe. Multi-precision is probably quite a bit slower than fixed > 128 bits, but I guess the number of performance-sensitive applications > for >64 but <128 bit integers is really small. > In any case, we have the systems for these kinds of applications: > 64-bit Forth systems, with their doubles (and we have had them for at > least 19 years (11 years on PCs)). I have not heard of people > flocking to Forth for that reason. Though sufficient interest to see people develop and maintain fixed 128 bit C libraries rather than use existing multi-precision would be a substantially lower threshold then the interest required to get many people to switch to an obscure niche language for those tasks. And there are legacy affects as well ... people who were already using multi-precision libraries for 128 bit work on 32 bit systems wouldn't feel any pressure to switch when moving to 64 bit systems where all of those operations get a speed boost in any event.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-18 22:59 -0700 |
| Message-ID | <65f2d67c-1c7c-4189-ad5d-07df2854aec5@googlegroups.com> |
| In reply to | #32468 |
On Friday, July 18, 2014 7:30:34 AM UTC-7, Stephen Pelc wrote: > On Thu, 17 Jul 2014 16:34:46 -0700 (PDT), hughaguilar96@yahoo.com > >Also, just by writing HostForth in 64-bit x86 assembly rather than 32-bit x= > >86 assembly, I have taken a big step toward defeating Pelc who is mired in = > >the obsolete 32-bit x86 world. Defeating Forth Inc. is too easy, as SwiftFo= > >rth is slow as molasses --- defeating MPE is much more difficult --- but it= > > should be possible, especially for programs that deal primarily in 64-bit = > >data. How much fun would that be? A lot! ;-) > It's difficult to argue against your vapourware. I'm taking my time with it. You are moving at glacial speed on Forth-200x, and what you are producing is just a bloated version of ANS-Forth --- I don't feel any pressure from that direction --- I don't think you are anybody to knock me for moving slowly. I don't want to be like Forth Inc. and release code that hasn't been tested at all (such as SwiftForth-v2 in which (LOCAL) would crash the system when it was used). Mostly, I just keep running into new ideas, and having to rethink the design. I've already started over from scratch three times. There are good ideas that come up on comp.lang.forth. For example: https://groups.google.com/forum/#!searchin/comp.lang.forth/lauri$20abstraction/comp.lang.forth/SaC_e4frlxs/uPzdj37wnEQJ She was making a good point that I hadn't given any thought to, and so I think that I will do this in my language. Unfortunately, any time that anybody introduces any new thinking to comp.lang.forth, the person is attacked --- telling her to read the Wikipedia article was incredibly insulting. Most Forths can be implemented quickly, because they are just a rework of an old Forth system from the 1970s, without any new thinking. For example, PolyForth for the 16-bit x86 didn't take advantage of the segment registers at all --- the compiler, dictionary, application program, application library --- everything --- fit into a single 64K segment. It apparently was just a direct port from a system for an old processor that was limited to 64K (most likely the PDP-11). Porting old 1970s Forth systems to new hardware seems like a waste of time to me --- I want to put together something that is innovative. > It's certainly true that 64 bit CPUs are good for applications > that use a lot of 64 bit data. Outside the scientific domains > there does not seem to be a great demand for 64 bit data. > We only have one client who can show a need for much better > processing of 64/128 bit data. I mentioned CAM already. If you use 32-bit numbers, and you set unity at 2^20, then you have 6 decimal digits to the right of your decimal point and 3 to the left. This is doable, but it is pretty marginal --- round-off error is going to be a problem --- and CAM is actually a pretty pedestrian application, as it deals with a physical machine that moves over a small area (maybe 8 foot square at the most) and a limited precision (+-.0005 inches at the very best). I think that what you are doing, is relying on floating-point for applications that I would do in fixed-point. This is a bad idea. Floating-point is at least twice as slow as fixed-point, and no amount of optimizing will change this. Also, in ANS-Forth floating-point is cumbersome because it uses a different stack, and you can't store floats in locals. If you write a CAM program in VFX, it is going to be unduly slow and cumbersome --- and, like I said, CAM is a pretty pedestrian application --- this is not a "scientific domain," this is a machine-shop. You are making your job much more difficult than necessary. Now you have to write an optimizing compiler for floating-point operations as well as fixed-point operations. By comparison, I only worry about fixed-point operations, so I have half the work that you have (this is assuming that I don't support floating-point, which I may not, although I'm undecided if I will or won't).
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-07-19 11:17 +0000 |
| Message-ID | <53ca53d5$0$4683$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #32468 |
In article <53c928c6.819888433@news.demon.co.uk>, Stephen Pelc <stephenXXX@mpeforth.com> wrote: >On Thu, 17 Jul 2014 16:34:46 -0700 (PDT), hughaguilar96@yahoo.com >wrote: > >>Also, just by writing HostForth in 64-bit x86 assembly rather than 32-bit x= >>86 assembly, I have taken a big step toward defeating Pelc who is mired in = >>the obsolete 32-bit x86 world. Defeating Forth Inc. is too easy, as SwiftFo= >>rth is slow as molasses --- defeating MPE is much more difficult --- but it= >> should be possible, especially for programs that deal primarily in 64-bit = >>data. How much fun would that be? A lot! ;-) > >It's difficult to argue against your vapourware. > >It's certainly true that 64 bit CPUs are good for applications >that use a lot of 64 bit data. Outside the scientific domains >there does not seem to be a great demand for 64 bit data. >We only have one client who can show a need for much better >processing of 64/128 bit data. In the light delay tunnel of the Chili ESA space observatory (60 m), the distance was measured in 256-th of the wavelength of an infra red beam. (14 nm RMS deviation ). The results needed more than 32 bits. One of the rare occasions I came across. > >Stephen -- 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 | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-19 17:04 -0700 |
| Message-ID | <0a64052c-2651-49d3-a56a-ff3957982b31@googlegroups.com> |
| In reply to | #32468 |
On Friday, July 18, 2014 7:30:34 AM UTC-7, Stephen Pelc wrote: > On Thu, 17 Jul 2014 16:34:46 -0700 (PDT), hughaguilar96@yahoo.com > wrote: > >Also, just by writing HostForth in 64-bit x86 assembly rather than 32-bit x= > >86 assembly, I have taken a big step toward defeating Pelc who is mired in = > >the obsolete 32-bit x86 world. Defeating Forth Inc. is too easy, as SwiftFo= > >rth is slow as molasses --- defeating MPE is much more difficult --- but it= > > should be possible, especially for programs that deal primarily in 64-bit = > >data. How much fun would that be? A lot! ;-) > > It's difficult to argue against your vapourware. It is easy to call my Lambda Forth "vaporware" (or "vapourware" using your screwed up English) --- because it is vaporware at this time. This is not a long-term plan though. Eventually I will release my system. This is assuming that I am capable of writing a cross-compiler, and I am, as I have done this before with MFX for the MiniForth. If you stick with ANS-Forth, then you are going to get soundly defeated when Lambda Forth comes out --- because ANS-Forth has serious design flaws (it was mandated to be fully compatible with SwiftForth without any change in SwiftForth whatsoever). Upgrading to Forth-200x isn't going to help, because Forth-200x is mandated to be fully compatible with ANS-Forth --- upgrading to Forth-200x may actually make you worse off, because Forth-200x is significantly more bloated than ANS-Forth, and all of this bloat increases the difficulty of optimization rather than lessen it. Realistically, you can't defeat me, so you might as well join me --- and the sooner that you do, the better off you will be, as you can contribute to the design rather than have to just accept it after I've written it in stone. I'm totally baffled as to why Elizabeth Rather has any cred at all. The only Forth code she has posted on C.L.F. since C.L.F. came into being, has been taken straight out of the "Starting Forth" book. That is pathetic! Forth Inc. embarrassed the entire Forth community badly with PolyForth being crammed into a single 64K segment on the 16-bit x86 (this was actually worse than the Tiny memory-model, as the compiler and symbol table had to fit in the 64K along with the application code and data) --- this was at a time when all of the C compilers supported all six memory models. PolyForth compared badly to QBasic, and QBasic was considered to be a toy even by its proponents. Forth Inc. has never made any positive contribution to Forth --- Forth Inc. is just an ongoing scam --- they don't deserve any respect whatsoever.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-07-19 21:38 -0400 |
| Message-ID | <op.xi9v6cbt6zenlw@localhost> |
| In reply to | #32495 |
On Sat, 19 Jul 2014 20:04:28 -0400, <hughaguilar96@yahoo.com> wrote: > If you stick with ANS-Forth, then you are going to get soundly > defeated when Lambda Forth comes out [...] ... > Realistically, you can't defeat me, so you might as well join me --- > and the sooner that you do, the better off you will be, as you can > contribute to the design rather than have to just accept it after > I've written it in stone. "Resistance is futile." Perhaps, Lambda Forth should be renamed Borg-Forth ... "We are the Borg. Your biological and technological distinctiveness will be added to our own. Resistance is futile." -Borg, Star Trek, The Next Generation s/Borg/Hugh We are the Hugh ... except, for now, you're a collective of ONE. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-17 10:16 +0000 |
| Message-ID | <2014Jul17.121640@mips.complang.tuwien.ac.at> |
| In reply to | #32439 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>16bit forths and 32bit forths compatibility in forth is a dream. In a 16bit=
> forth even if you have a "portable" 32bit data variable, fetching it will =
>take two cells instead of one for 32bit forth, and it's all over.
Just have a DL@ ( addr -- d ) or maybe UDL@ ( addr -- ud ) that
accesses 32 bits. You can implement that on 16-bit systems, 32-bit
systems and 64-bit systems.
My experience is that Forth portability between 32-bit and 64-bit
platforms works very well (better than C portability); I don't see a
reason why a program should not be portable from a 16-bit system to a
32-bit system (the other way round can be harder, if the 32-bit system
supports more words and the program uses these words).
> Meaning you just double it from the start, and=
> don't want to support mixed sizes 32bit/64bit ?
Gforth on 32-bit platforms has 32-bit cells and 64-bit doubles; Gforth
on 64-bit platforms has 64-bit cells and 128-bit doubles.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-17 16:13 -0700 |
| Message-ID | <a9b6db94-101b-4e70-930e-3f5dcfadbcce@googlegroups.com> |
| In reply to | #32443 |
On Thursday, July 17, 2014 3:16:40 AM UTC-7, Anton Ertl wrote: > My experience is that Forth portability between 32-bit and 64-bit > platforms works very well (better than C portability); I don't see a > reason why a program should not be portable from a 16-bit system to a > 32-bit system (the other way round can be harder, if the 32-bit system > supports more words and the program uses these words). Porting from a 16-bit system to a 32-bit system is easy if you are willing to double your memory usage (every datum that had previously occupied two bytes now occupies four bytes), which I already described as being problematic (a 32-bit processor doesn't necessarily have more memory than a 16-bit processor). Difficulty occurs when a program's data is naturally 32-bit (the +-32KB range of a 16-bit integer is pretty restrictive, and a lot of times you just need the +-2GB range of 32-bit numbers), but the processor is 16-bit. There are two solutions. The first solution is to write the program in a 16-bit Forth, but use double-precision integers for the data. This can make for some rather cumbersome code. The second solution is to use a 32-bit Forth on the 16-bit processor, and use single-precision integers for the data. The latter solution is what Raimond is advocating, and I agree with him that this makes the user's job easier. The compiler-writer's job is harder, because he has to write a 32-bit cross-compiler for a 16-bit processor, that is has likely already written a 16-bit cross-compiler for --- but the cross-compiler writer is likely to be me, and I don't mind extra work so long as I'm getting paid --- if the user wants a 32-bit cross-compiler for a 16-bit processor because it makes his life easier, and he is willing to pay for it, then why not?
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2014-07-19 08:04 -0700 |
| Message-ID | <9875cdc3-4faa-4b31-9784-5efa1f3f1ecb@googlegroups.com> |
| In reply to | #32439 |
On Thursday, July 17, 2014 9:32:46 AM UTC+2, Raimond Dragomir wrote: [..] > Forth cannot hide the size for operators, do you cannot have a "+" > that work on single cells or double cells. You can use the standard word TO for this. -marcel
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-16 20:51 -0700 |
| Message-ID | <9dd8a49a-cad9-4e89-9aac-e5925dd8df85@googlegroups.com> |
| In reply to | #32429 |
On Wednesday, July 16, 2014 3:01:50 AM UTC-4, Raimond Dragomir wrote: > I will concentrate on cortex-m microcontrollers (m0, m3, m4) but even so I don't like the 64bit math, because I just don't need it. But a 32bit system is usefull for smaller microcontrollers also. Even that noone seems to agree this for an 8051 or avr (avr is quite decent though) I can think of elegant implementations for MSP430 or PIC24 which are 16bitters. It seems rather that whatever you are viewing as elegant, most prefer their Forth to map more closely to their processor. And then, under that preference, the double is not as striking an issue, since they have not defined all of their single cells operations to work on double processor words, so their double operations are double processor word operations, not quadruple processor word operations. > Anyway, forth has this single cell/double cell "compatibility" kind of view, which is nice, but not all the time. > But C does recognize the need of specifying the size of objects directly. That's why it has int8_t, int16_t, int32_t, int64_t and the unsigned uint... etc, even that this is done with some defines or typedefs. Yes, as Forth systems have normally done, though with the flexibility of Forth those have been more commonly target specific words than abstract sizes. > The idea is: sometimes you need an "int", a forth "cell". You don't care what the size is because you really know it is enough (a small index, or other variable) and you want it to be the most easy thing the system can deal with. > But many times you need specific sizes. For example, I have an application with large tables of 16bit values. I choose the 16bit value despite the cpu being 32bit, because it saved me lot of ram. That brings me the real need of having half cells in my 32bit forth, H@, H!. Yes, that is the normal Forth approach to that situation. There is a complete Forth200x proposal reserving a whole bucket of word size and big endian / little endian names, along those lines. > The point is: Using (only) the terms "single" and "double" "cell" for portability is not enough in itself without the direct size specifiers. It depends on portability to what. Having the direct size specifiers are not sufficient for portability either, since there is still big v little endian, compacted versus aligned, and so on. > Now I'm having H@ H! for my 32bit forth, but these are just not possible in a 16bit forth. But if you define unsigned 16s as "W"s, and name them W@ W!, they are possible whether in 16, 18, 20, 32, or 64 bits. And if 16 bits of unsigned range is sufficient for that algorithm, it will work on any of those. > Also, for "doubles", if I use doubles in a 16bit systems, those will compile as 64bit objects in a 32bit forth system. Which is precisely what many people who would only use a 32bit Forth on a 32bit processor would wish to have happen. > People using doubles in the 16bit forths are using them because they need 32bits. Why forcing them to use 64bits in a 32bit forth system? But as we have seen in the discussion, this is only partly true. People use 64bits intermediate product in a 32bit */ for largely the same reason they use a 32bit intermediate product in a 16bit */ ... because that is the natural range of a 32 bit multiply. If you don't WANT the intermediate product to be 64 bits, you can always do * and / in succession in the process clip the range, and still have */ for any occasion where you do not want to risk clipping the range. > People do not need "doubles". They need specific sizes that cover their needs, and use the double because this is what they have at hand. It is used with care anyway. You seem to enjoy double word operations so much that you have written Forth systems for 16bit word processors in which every operand is a double word. That implies you feel you can do without the single word operations. And if your stack cells are already intrinsically double words, it makes sense for efficiency's sake, to dispense with doubling it up again, so you'd only need double operations for paired-cell operations, like: : PARSE-NAME ( -- ca u ) in$ ws-skip 2DUP ws-scan chop 2SWAP >in$ ; > Well, long story for quite a short subject. CELL compatibility is needed, and a good to have. For forth is almost a must because of the stacks. But it must stop here. "Doubles" shouldn't exist. You were aiming to arrive at this conclusion, and so along the way made assertions about what "people need" which seem more to be what you find you need after you have baked double word operations into every single cell operation. > Along with CELL, it must exists byte/char/int8, in16, int32, int64 or any better names you can find for forth. For accessing specific hardware and for writing specific externally-defined data formats, certainly. But there are certain intrinsic relationships that followed from integer arithmetic, including the fact that for a cell size of 2^n bits, the intrinsic range of unsigned multiplication is 2^[2n] bits. While there may be a manner of elegance in carrying around those extra n bits all the time in order to avoid the inelegance of mixed size operations, there is also a different manner of elegance in tuning the cell size to the word size of the processor and only availing of those extra n bits when required. Virtually, @BruceMcF
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-27 21:08 -0700 |
| Message-ID | <65374f11-9c6a-48ee-b378-363ebb99b306@googlegroups.com> |
| In reply to | #32428 |
> On Friday, November 20, 2009 12:07:12 AM UTC-7, Elizabeth D Rather wrote: > > Hugh Aguilar wrote: > > > The problem is the ANS-Forth standard. Really, how obvious was the > > > need for double-precision arithmetic? This could have been an > > > extension to the language similar to floating-point. ... > > > ... M*/ was one of Chuck's most brilliant innovations. I'm > > sure if Chuck were trying to do your continued fractions that is what he > > would rely on. Yes, that sometimes requires thinking differently, like > > many other things in Forth. Lets forget about the Acorn --- that was just a distraction --- lets focus our minds on the D/ issue. It is now 20 years since ANS-Forth came out. Will Forth-200x have D/ or not? If so, will Elizabeth Rather be considered the "leading expert" on Forth-200x, or just ANS-Forth? In that same thread, Elizabeth Rather said this: On Saturday, November 21, 2009 9:05:42 PM UTC-7, Elizabeth D Rather wrote: > Uwe Klo� wrote: > > Elizabeth D Rather schrieb: > >> The major reason Forth hasn't been accepted is lack of marketing, either > >> in the form of adoption by major companies or organizations or papers in > >> various publications, meetings, etc. The vast majority of programmers > >> out there haven't considered Forth and rejected it for some reason > >> (although some have heard -- and passed on -- rumors about > >> unreadability, etc.), they simply never heard of it. > > > > In that case we have to ask "why". > > What do other languages have, that Forth has not? > > An organization behind them that is either large, well-funded, or both. Is this what everybody on the Forth-200x committee believes? Essentially, Elizabeth Rather is saying that Forth-200x will succeed if Forth Inc. is large and well-funded, or both. She is saying that the only reason ANS-Forth failed, was a lack of marketing --- that if all Forth programmers give money to Forth Inc. then she will put her awesome sales skills to work on selling the heck out of Forth-200x. Does this pretty much sum up the Forth-200x philosophy?
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-07-10 20:12 +0000 |
| Message-ID | <53bef39f$0$15881$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #32316 |
In article <ccb1d2d4-3f31-4f2c-bcc1-12b9afa55d67@googlegroups.com>, BruceMcF <agila61@netscape.net> wrote: >On Thursday, July 10, 2014 2:12:18 PM UTC-4, Raimond Dragomir wrote: >> On the other hand we want single words that should work on more than >one type: this is the picture numeric output: have one for doubles, >because it will work for singles too. Yes, but with BIG overheads. > >But an equally concise single celled version just rests on having a >punctuation character you are willing to devote to the single cell >equivalent of # ... if & then: > <& & HOLD &S &> I would go for <% % %S %> as &S is sometimes used for CHAR S. (Was in iforth, maybe still, and has always been in ciforth.) > >... in the implementation and the problem is fixed ... and if there is ><# # #S and #> defined in a source file somewhere, then you've >"provided" those CORE words. > >Andrew's experience with motor control matches my experience with data >logging ~ its the identical problem, the discontinuity around 0 ... > >... and it seems like a part of the reason that SM/REM is fine for you >is that you've have the range of values where the flaw with SM/REM comes >up. > >There's a lot of people for whom the difference doesn't make a >difference, but on the other hand *among* those for whom it makes a >difference, more need the FM/MOD version than the SM/REM version ... so >SM/REM provides a way to export a hardware symmetric divide under a >standard name so that people who need an FM/MOD are able to make the >conversion. > >Making FM/MOD CORE means that an implementer that doesn't include it in >the binary of their system really ought to include source for the FM/MOD >word for the use of those who need it. See also http://stackoverflow.com/questions/3602827/what-is-the-behavior-of-integer-division-in-c Summary: The consensus now is that truncating division is a mistake, e.g. Python mandates floored division. Not to speak of more math languages like Haskell. It is a thorn in the side of the mathematician, having 2n equivalence classes, and this translate to many practical issues. ( Some of which have been mentioned in this thread.) In the first C-standard it was implementation defined how % works. That newer C standards prescribe truncated comes from FORTRAN compatibility. As we all know FORTRAN was thrown together haphazardly and never cleaned up. ;-) Admittedly SM/REM is occasionally useful in control applications. Well that's why we have it. 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 | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-10 13:49 -0700 |
| Message-ID | <9a89d164-69d7-44ca-95ed-2f4f041337bc@googlegroups.com> |
| In reply to | #32325 |
On Thursday, July 10, 2014 4:12:15 PM UTC-4, Albert van der Horst wrote: > I would go for <% % %S %> as &S is sometimes used for CHAR S. I was grabbing a punctuation at random, but in sense of a percentage normally being a pure ratio, like divided by like, there is a faint connotation rationale for using % for the single-cell integer being divided by a single-cell BASE. Given that it acts on an integer and doesn't deliver a string until it's done, I don't see any way that it would interact with the use of %token% for pattern replacement.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-07-10 11:31 -1000 |
| Message-ID | <-audnSw-HYnQmyLOnZ2dnUVZ_jadnZ2d@supernews.com> |
| In reply to | #32328 |
On 7/10/14 10:49 AM, bruce.mcfarling@gmail.com wrote: > On Thursday, July 10, 2014 4:12:15 PM UTC-4, Albert van der Horst wrote: >> I would go for <% % %S %> as &S is sometimes used for CHAR S. > > I was grabbing a punctuation at random, but in sense of a percentage normally being a pure ratio, like divided by like, there is a faint connotation rationale for using % for the single-cell integer being divided by a single-cell BASE. > > Given that it acts on an integer and doesn't deliver a string until it's done, I don't see any way that it would interact with the use of %token% for pattern replacement. > Well, there's prior art here that you can use. Since Open Firmware had minimum cell size of 32 bits, they used single-precision number formatting words <# u# u#s sign hold and u#> (with the double words # #s and #> defined but not used; IMO it's perfectly acceptable to have them available in an auxiliary, optional load). Anyway, if you're going to have single versions, IMO you should use these names. 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]
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web