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 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-10 16:30 -0700 |
| Message-ID | <aa6a57ab-138a-4804-9c8b-74c4aa3ca04d@googlegroups.com> |
| In reply to | #32330 |
On Thursday, July 10, 2014 5:31:56 PM UTC-4, Elizabeth D. Rather wrote: > 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). There you go, problem already solved by Open Firmware, <# U# U#S SIGN HOLD and U#> it is, then.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-07-11 01:11 -0700 |
| Message-ID | <2b2788a7-8d47-4fee-af73-8ccef28feb72@googlegroups.com> |
| In reply to | #32333 |
On Friday, 11 July 2014 00:30:37 UTC+1, bruce.m...@gmail.com wrote: > On Thursday, July 10, 2014 5:31:56 PM UTC-4, Elizabeth D. Rather wrote: > > > > > 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). > > > > There you go, problem already solved by Open Firmware, <# U# U#S SIGN HOLD and U#> it is, then. Oh that's cool. I wasn't aware of that. That's a neat solution for me in the 16-bit world, where I have numbers that I wish to format, but I know they are <= 16-bits.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-10 21:30 -0700 |
| Message-ID | <f049ca93-5f47-41c3-a9d7-add3a8416461@googlegroups.com> |
| In reply to | #32330 |
> > 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." > > ================================================== Thank you, I didn't know. So my words are not #, #S, #> but U#, U#S, U#>. I'm perfectly ok with that. Best regards,
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2014-07-10 21:57 +0200 |
| Message-ID | <1833moah21k75$.1khkmluf64s4h.dlg@40tude.net> |
| In reply to | #32314 |
Op Thu, 10 Jul 2014 11:12:18 -0700 (PDT) schreef Raimond Dragomir: >> The other reason to want to be compliant with the standard is because you are sharing something. In my mind, that is the more important reason, though those engaged in selling something could well disagree. >> > Yup, that comes to my mid too. > > The most annoying is the <# # #> thing. It looks like it is suppose to be working everywere, anytime, and it is, until the "0" that comes for doubling the otherwise single cell unsigned number... > > That zero makes my stuff not compatible with existing stuff. I did not like this even for a 16bit system. Why force 32bit operations for 8 bit microcontrollers, when you know that you have 16bit numeric output? You specifically put with your own hand the 0 to make it double. Do you never work with signed numbers? Then you have to use S>D instead of zero. > > Here comes some forth paradoxes: on one hand, forth have different name for different types on operators, for unsigned, for floats, etc. > 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. What about addressing characters with C@ C! and cells with @ ! +!. Do you really have trouble with these? Overloading operators is a C++ thing, not Forth's. -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-07-20 23:47 -0400 |
| Message-ID | <lqi2hi$hr4$1@dont-email.me> |
| In reply to | #32314 |
On 7/10/2014 2:12 PM, Raimond Dragomir wrote: >> The other reason to want to be compliant with the standard is because you are sharing something. In my mind, that is the more important reason, though those engaged in selling something could well disagree. >> > Yup, that comes to my mid too. > > The most annoying is the <# # #> thing. It looks like it is suppose to be working everywere, anytime, and it is, until the "0" that comes for doubling the otherwise single cell unsigned number... > > That zero makes my stuff not compatible with existing stuff. I did not like this even for a 16bit system. Why force 32bit operations for 8 bit microcontrollers, when you know that you have 16bit numeric output? You specifically put with your own hand the 0 to make it double. > > Here comes some forth paradoxes: on one hand, forth have different name for different types on operators, for unsigned, for floats, etc. > 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. I have avoided this thread until now and have not reached the end yet, but I would like to discuss a thought. Your code can be standard compliant by including the 0 to make the input word double precision. But if you know your apps will not need double precision output, you can simplify the output words to just toss the extended precision cell and do the conversion in single precision. It could even do a quick check to verify there are no significant digits and providing an error if the input is not single precision. Then your Forth may not be completely compatible with the standard, but you can document that. It won't be running anyone else's code so who cares? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-07-10 12:48 -0500 |
| Message-ID | <1uSdndVHe6lDTCPOnZ2dnUVZ_qqdnZ2d@supernews.com> |
| In reply to | #32301 |
Raimond Dragomir <raimond.dragomir@gmail.com> wrote: > Also, why having both FM/MOD and SM/REM? We are in 2014, living in a > C world. C division is SM/REM (or at least it's a hardware division > and C doesn't care). My applications also don't care. Besides being > optional these mixed precision words, the division should be just > symmetrical, and a user needing a FM/MOD will be just a user with a > problem. Anyway, I'm sure 99% of the C programmers are just unaware > that there even exist two kind of division algorythms for signed > numbers. I can answer that one: it's to do with the application areas for which Forth was designed, and it's still true today. SM/REM has a discontinuity about zero which produces a jog in the slope of a line. "Discontinuity can present a problem in as ordinary an example as moving a robot arm through physical space. The application might make use of virtual co-ordinates such that the arm would have to traverse an imaginary zero point. If the physical co-ordinates are computed by addition or subtraction of the virtual co-ordinates, the arm will jump or stall whenever it crosses the virtual zero point." [1] Andrew. [1] Division, Relationals, and Loops, Leo Brodie and Dean Sanderson, FORTH, Inc. Proc. Rochester Forth Standards Conference, 1981.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-10 11:33 -0700 |
| Message-ID | <c5b04fd3-5c2f-48c3-a2ee-9928fdbf845e@googlegroups.com> |
| In reply to | #32313 |
> I can answer that one: it's to do with the application areas for which > > Forth was designed, and it's still true today. > > > > SM/REM has a discontinuity about zero which produces a jog in the slope > > of a line. "Discontinuity can present a problem in as ordinary an > > example as moving a robot arm through physical space. The application > > might make use of virtual co-ordinates such that the arm would have to > > traverse an imaginary zero point. If the physical co-ordinates are > > computed by addition or subtraction of the virtual co-ordinates, the > > arm will jump or stall whenever it crosses the virtual zero point." [1] > > > > Andrew. > > > > [1] Division, Relationals, and Loops, Leo Brodie and Dean Sanderson, > > FORTH, Inc. Proc. Rochester Forth Standards Conference, 1981. I'm sure there are applications for FM/MOD. But I think Forth care too much about it, when the rest of the world even doesn't care or works out the problem quietly (I don't think they use forth when they need floored division :)
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-07-10 23:35 +0200 |
| Message-ID | <lpn0up$u7g$1@online.de> |
| In reply to | #32317 |
Raimond Dragomir wrote: > I'm sure there are applications for FM/MOD. But I think Forth care too > much about it, when the rest of the world even doesn't care or works out > the problem quietly (I don't think they use forth when they need floored > division :) No, a significant portion of the rest of the world has followed our lead. Like Python, which now requires floored division. Python is one of the most important non-C-derived programming languages, and the C family has some pressure to stay compatible with the garbage the C standard team decided 15 years ago ;-). Guido van Rossum's blog post on that topic is nearly 4 years old now: http://python-history.blogspot.de/2010/08/why-pythons-integer-division-floors.html Forth's discussion about floored divions is in the order of 30 years old (about standards, with some chaos when Forth-79 was symmetric, Forth-83 was floored, and ANS Forth allowed both). You can't expect everybody to understand immediately, but as time goes by, it sinks in. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-10 21:51 -0700 |
| Message-ID | <ecc52e69-e044-468b-a93a-6099437c6d42@googlegroups.com> |
| In reply to | #32331 |
vineri, 11 iulie 2014, 00:35:20 UTC+3, Bernd Paysan a scris: > Raimond Dragomir wrote: > > > I'm sure there are applications for FM/MOD. But I think Forth care too > > > much about it, when the rest of the world even doesn't care or works out > > > the problem quietly (I don't think they use forth when they need floored > > > division :) > > > > No, a significant portion of the rest of the world has followed our lead. > > Like Python, which now requires floored division. Python is one of the most > > important non-C-derived programming languages, and the C family has some > > pressure to stay compatible with the garbage the C standard team decided 15 > > years ago ;-). > > > > Guido van Rossum's blog post on that topic is nearly 4 years old now: > > > > http://python-history.blogspot.de/2010/08/why-pythons-integer-division-floors.html > > > > Forth's discussion about floored divions is in the order of 30 years old > > (about standards, with some chaos when Forth-79 was symmetric, Forth-83 was > > floored, and ANS Forth allowed both). You can't expect everybody to > > understand immediately, but as time goes by, it sinks in. > > > > -- > > Bernd Paysan > > "If you want it done right, you have to do it yourself" > > http://bernd-paysan.de/ Ok, both SM/REM and FM/MOD have their applications. In fact my biggest problem is not that they are two, but that they are at all, any of them, because they are double :) There is a whole class of 32bit applications that really don't need any 64bit operations. And 32bit forth systems in that class are really nice. 32bit forth "lite" systems which don't have doubles (in the sens of double word math, not cell pairs).
[toc] | [prev] | [next] | [standalone]
| From | Matthias Koch <matthias.koch@hot.uni-hannover.de> |
|---|---|
| Date | 2014-07-11 12:30 +0200 |
| Message-ID | <lpoeh3$bpm$1@newsserver.rrzn.uni-hannover.de> |
| In reply to | #32301 |
All the parts you mentioned are at least doable given enough code space and work, and I want to put two technical implementation problems into the discussion one more time:
CREATE with a default action and DOES> that can rewrite this action, multiple times. This is a real hassle with one-time-writeable memory. Mikael Nordmann pointed out that Flash write buffers solve the issue successfully, see FlashForth, but in worst case they need erase cycles.
For standalone embedded systems offering direct compilation into "large paged" Flash memory as in STM32F407 a CREATE with unchangeable default action and an old style <BUILDS DOES> that cannot be redefined multiple times solve the issue.
The second issue is collecting the Flags. ANS defines IMMEDIATE which can be placed outside of a definition, but as I am having additional flags for inlining, foldability, instruction set optimisations, compile-only and RAM-allocation, I need to bundle them together somehow before the flag field can be written (one time). Having the flags inside of the definition is a great help.
But basically, I am fine. The standard helps to have a common base and a few lines of documentation are enough to clarify what is different in a particular implementation.
Matthias
PS: Floored division for symmetric cores, for Mecrisp for MSP430 and usable on Mecrisp-Stellaris on ARM Cortex, too. You can omit the inline and foldable flags:
: sm/rem ( d1 n1 -- n2 n3 ) m/mod inline 3-foldable ;
: fm/mod ( d1 n1 -- n2 n3 floored signed div'n courtesy of Ed Smeda )
dup >r
sm/rem 2dup 1 < and
if swap r@ + swap 1- then
r>
drop
3-foldable ;
-3. 2 sm/rem . . -1 -1 ok.
-3. 2 fm/mod . . -2 1 ok.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2014-07-11 11:56 +0100 |
| Message-ID | <lpofs4$nln$1@dont-email.me> |
| In reply to | #32350 |
On 11/07/2014 11:30, Matthias Koch wrote: > PS: Floored division for symmetric cores, for Mecrisp for MSP430 and > usable on Mecrisp-Stellaris on ARM Cortex, too. You can omit the inline > and foldable flags: > > : sm/rem ( d1 n1 -- n2 n3 ) m/mod inline 3-foldable ; > > : fm/mod ( d1 n1 -- n2 n3 floored signed div'n courtesy of Ed Smeda ) > dup >r > sm/rem 2dup 1 < and > if swap r@ + swap 1- then > r> > drop > 3-foldable ; > > > -3. 2 sm/rem . . -1 -1 ok. > -3. 2 fm/mod . . -2 1 ok. I don't know what M/MOD does but if inline and 3-foldable are only flags and can be omitted the above implies it is the same as SM/REM. If that is true then: 2. 3 fm/mod . . -1 5 ok \ Is not ok See my earlier reply to Bruce McFarling -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-07-11 07:08 -0500 |
| Message-ID | <p_OdnfuqDbhJTiLOnZ2dnUVZ_tmdnZ2d@supernews.com> |
| In reply to | #32351 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote: > On 11/07/2014 11:30, Matthias Koch wrote: >> PS: Floored division for symmetric cores, for Mecrisp for MSP430 and >> usable on Mecrisp-Stellaris on ARM Cortex, too. You can omit the inline >> and foldable flags: >> >> : sm/rem ( d1 n1 -- n2 n3 ) m/mod inline 3-foldable ; >> >> : fm/mod ( d1 n1 -- n2 n3 floored signed div'n courtesy of Ed Smeda ) >> dup >r >> sm/rem 2dup 1 < and >> if swap r@ + swap 1- then >> r> >> drop >> 3-foldable ; >> >> >> -3. 2 sm/rem . . -1 -1 ok. >> -3. 2 fm/mod . . -2 1 ok. > > I don't know what M/MOD does but if inline and 3-foldable are only flags > and can be omitted the above implies it is the same as SM/REM. If that > is true then: > > 2. 3 fm/mod . . -1 5 ok \ Is not ok > > See my earlier reply to Bruce McFarling And, for a bit more info, my posting of twenty years ago. :-) https://groups.google.com/d/msg/comp.lang.forth/QBtluXNh7J0/tpkvAYv2ytQJ Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2014-07-12 18:46 +0100 |
| Message-ID | <lprs88$u7s$1@dont-email.me> |
| In reply to | #32352 |
On 11/07/2014 13:08, Andrew Haley wrote:
> And, for a bit more info, my posting of twenty years ago. :-)
>
> https://groups.google.com/d/msg/comp.lang.forth/QBtluXNh7J0/tpkvAYv2ytQJ
An implementation of FM/MOD using your method putting the -m/mod in-line is:
: fm/mod-1 ( d n -- r q )
dup 0< dup >r if negate >r dnegate r> then
over 0< if dup >r + r> then um/mod
r> if swap negate swap then
;
Compare this with the version I posted elsewhere (slightly modified):
: fm/mod-2 ( d n -- r q )
dup >r 2dup xor 0< >r sm/rem
over r> and if 1- swap r> + swap exit then r> drop
;
They both give the same results with the numbers I've used to test them
fm/mod-2 is a bit shorter with fewer IFs. It looks like the method you
posted is a neat idea spoiled somewhat by having to deal with all
combinations of positive and negative numbers.
Of course fm/mod-1 can be simplified a bit by restoring -m/mod as a factor
: -m/mod ( d +n -- r q ) over 0< if dup >r + r> then um/mod ;
: fm/mod-1a ( d n -- r q )
dup 0<
if negate >r dnegate r> -m/mod swap negate swap exit then
-m/mod
;
--
Gerry
[toc] | [prev] | [next] | [standalone]
| From | Matthias Koch <matthias.koch@hot.uni-hannover.de> |
|---|---|
| Date | 2014-07-14 15:50 +0200 |
| Message-ID | <lq0nca$sii$1@newsserver.rrzn.uni-hannover.de> |
| In reply to | #32380 |
Hi Andrew, Hi Gerry, thank you for pointing me to this ! Matthias
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2014-07-11 17:50 -0700 |
| Message-ID | <4dbbc29b-47ee-4857-8df4-c5191e13c513@googlegroups.com> |
| In reply to | #32351 |
On Friday, July 11, 2014 6:56:16 AM UTC-4, Gerry wrote: >> -3. 2 sm/rem . . -1 -1 ok. >> -3. 2 fm/mod . . -2 1 ok. > > I don't know what M/MOD does but if inline and 3-foldable are only flags > and can be omitted the above implies it is the same as SM/REM. If that > is true then: > > 2. 3 fm/mod . . -1 5 ok \ Is not ok > > See my earlier reply to Bruce McFarling And my prior reference to the benefit of having words tested on a system for tricky corner cases versus what had been presented as the presumed first recourse of googling for definitions ~ indeed, not necessarily googling, since I find that I have both definitions in various source files on the hard drive of my play netbook upstairs.
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-14 17:32 -0700 |
| Message-ID | <465e4d3a-8a25-4056-93d1-82e73dfbfa3c@googlegroups.com> |
| In reply to | #32350 |
On Friday, July 11, 2014 6:30:56 AM UTC-4, Matthias Koch wrote: > For standalone embedded systems offering direct compilation into "large paged" Flash memory as in STM32F407 a CREATE with unchangeable default action and an old style <BUILDS DOES> that cannot be redefined multiple times solve the issue. ... though under some distinctive names, like: <ACTOR ... ACTION> ... given that an effective means of guarding against an attempt to use a source that does a redefining CREATE ... DOES> is to issue a warning for DOES> used by the source. > The second issue is collecting the Flags. ANS defines IMMEDIATE which can be placed outside of a definition, but as I am having additional flags for inlining, foldability, instruction set optimisations, compile-only and RAM-allocation, I need to bundle them together somehow before the flag field can be written (one time). Having the flags inside of the definition is a great help. ... so a semantic like: : <name> ... ;[ IMM COMP-ONLY OPIMIZE <etc> ... ]; where: ;[ ( compilingg: -- word-status-id ) complete the compilation of the current definition, enter interpretation state, place on the stack the word-status-id of the default word status. ]; ( word-status-id -- ) enter the most recent definition into the dictionary with the status indicated by word-status-id on the top of stack. ... and a bunch of, ``IMM ( word-status-id1 -- word-status-id2 )'' ... where, again, ``IMMEDIATE'' can give a warning.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-12 21:56 -0700 |
| Message-ID | <67a7fe7a-48e4-4d76-9cdf-b6459258f27f@googlegroups.com> |
| In reply to | #32301 |
Some early conclusions: - Pictured numeric output: <# U# U#S U#> for single <# # #S #> for double If you look at these a cleaner naming would be: <# # #S #> for single <# D# D#S D#> for double But it's too late for this I think FM/MOD: Not clear. I'm glad I don't need it. I think all double math should be optional. As Hugh said, defined but optional. As I said before, I didn't know how to define my single cell numeric output words. So I didn't renamed at all and use <# # #> but this breaks the compatibility. I think it's better to just don't have some words at all (even if they are CORE in the standard) than having standard names with non-standard behaviour.
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-12 23:12 -0700 |
| Message-ID | <6d83f56c-7f3c-4c65-9a9f-7442d894e3ab@googlegroups.com> |
| In reply to | #32397 |
On Sunday, July 13, 2014 12:56:23 AM UTC-4, Raimond Dragomir wrote: > Some early conclusions: > - Pictured numeric output: > <# U# U#S U#> for single > <# # #S #> for double > If you look at these a cleaner naming would be: > <# # #S #> for single > <# D# D#S D#> for double > But it's too late for this I think Something like 40 years too late ... de facto and informal standards had already evolved around the state of the art when embedded programming was dominated by 16 bit address space processors. I think the single line % for single cell and doubled line # for double cell is a bit evocative, but better to go with existing practice. > FM/MOD: Not clear. I'm glad I don't need it. But remember that the "M" in SM/REM means "mixed", since its: SM/REM ( d1 n2 -- n2 n3 ) ... so if you are going to have single cell division alone, and its going to be symmetric, call it /MOD, and document that its symmetric. If you want to claim the system is a Forth94 system, it needs to have FM/MOD and SM/REM, if only in included source, but there's certainly nothing wrong with omitting those if you only wish to be "aligned" with Forth94 (as with eForth ... is it v2.0? or v3.0? I can't recall off the top of my head). > I think all double math should be optional. As Hugh said, defined but optional. It is optional for it to be included in the binary of a Forth94 system. And its optional whether you want to make a system a Forth94 system, for which you would have to at least provide it in source. So, for all real world intents and purposes, its optional. > I think it's better to just don't have some words at all (even if they are CORE in the standard) than having standard names with non-standard behaviour. Yes. Source that assumes a word is present failing, because the word is not found is an early fail, and quite explicit: FM/MOD ? ... and you can work out whether you can write around the absence of the word or not. If you have source that is written to be cross-platform but it works within the range of /MOD then whether or not a /MOD that is really ``/REM'' is more likely to require some thinking than the fact that you have to change 2>R and 2SWAP to >R and SWAP.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-07-13 10:42 +0000 |
| Message-ID | <53c26293$0$15859$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #32397 |
In article <67a7fe7a-48e4-4d76-9cdf-b6459258f27f@googlegroups.com>, Raimond Dragomir <raimond.dragomir@gmail.com> wrote: >Some early conclusions: > >- Pictured numeric output: ><# U# U#S U#> for single ><# # #S #> for double > >If you look at these a cleaner naming would be: ><# # #S #> for single ><# D# D#S D#> for double >But it's too late for this I think What we still can do is to introduce those words, and make # #S #> obsolescent. The U words can be used for signed numbers, which is a bit strange. My exercise with yourforth has learned me that in order to be able to print an unsigned 32 bit, you still need 64 by 32 bit division. (or dedicated unsigned operators). FM/MOD (on Intel SM/REM) and M* are still the primitives of choice for very simple systems with no regard for efficiency. > >FM/MOD: Not clear. I'm glad I don't need it. Actually it is the most simple operation. When you were in school, you multiplied two 3 digit numbers, and got a 6 digit number, and were quite used to it. In computers there is the abstraction that a register holds numbers of indefinite size. > >I think all double math should be optional. As Hugh said, defined but optional. >As I said before, I didn't know how to define my single cell numeric >output words. So I didn't renamed at all and use <# # #> but this breaks >the compatibility. Agreed but note that unsigned math presents the same kind of problems. Even on 64 bit systems negative addresses don't want to go away. > >I think it's better to just don't have some words at all (even if they >are CORE in the standard) than having standard names with non-standard >behaviour. > Who wouldn't agree with you? Still I'm guilty of cutting a corner here and there. 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-07-13 13:54 +0200 |
| Message-ID | <lpts1g$1sj$1@online.de> |
| In reply to | #32403 |
Albert van der Horst wrote: > In article <67a7fe7a-48e4-4d76-9cdf-b6459258f27f@googlegroups.com>, > Raimond Dragomir <raimond.dragomir@gmail.com> wrote: >>Some early conclusions: >> >>- Pictured numeric output: >><# U# U#S U#> for single >><# # #S #> for double >> >>If you look at these a cleaner naming would be: >><# # #S #> for single >><# D# D#S D#> for double >>But it's too late for this I think > > What we still can do is to introduce those words, and make > # #S #> obsolescent. > > The U words can be used for signed numbers, which is a bit > strange. Actuall, not. If you want to convert a signed number, you need to do dup abs <# u#s swap sign u#> Just like with #s, which also needs tuck dabs <# #s rot sign #> for signed input. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
Page 8 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