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 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-10 02:35 -0700 |
| Subject | Forth16e, Forth32e, "de facto" forth programming standards for embedded |
| Message-ID | <49aa991d-41c6-44ae-afe4-ad1b7434011b@googlegroups.com> |
Hi all, I don't want to start another ANS forth standard war here. It's just my own experience that for an 32bit embedded system (microcontroller class) a good simple ANS forth system or cross compiler is quite an overkill. ANS maps quite good for a 16bit system, and that's normal. But the compatibility between 16bit and 32bit adds a big overhead for a 32bit system. Here are two sensible areas: 1. picture numeric output. It imposes the usage of double numbers. For a 16bit system it is about ok. You're likely to need it, and if you really want, you can add a 16bit numeric output version for where the absolute performance is needed. But for a 32bit system it requires 64bit numbers and maths. That's huge. I never needed 64bit in my 20years of embedded, being C or forth or anything else. Also, just think that the 32bit system is not a Cortex-M, maybe it is an 8051! (I have an 8051 system which I made 32bit because it's just plain simpler to work with). So, for picture numeric output, a "single cell" version is in fact the most usefull for embedded, and the double cell version might be an otional feature. Why is it a problem for 32bit and not for 16 bit? Because for 16bit the single cell variant can be optional and you are ANS compliant, but for the 32bitters you can do a single cell variant but you MUST carry the double cell variant to be ANS compliant. 2. FM/MOD, SM/REM and mixed precision math. Mixed precision has the same problem as the picture numeric output above. Again, I never needed 64 bit numbers even for scaling. And I have done a lot of applications that needed scaling, including for 32bit microcontrollers. In fact, I don't have a single application done with floating point stuff. Well, you can fake a */ like this: : */ * / ; for a 32bit system, but that's not the point. 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. What I had over time: - a standalone 32bit 8051 forth system - a standalone 32bit avr forth system Both have non-standard single cell picture numeric output (but it is 32bit) Both don't have mixed precision math. Both have simmetric division, and I really not care about it in fact, because I never had a need for dividing negative numbers until now - I have now a cortex-m 32bit system (it's "almost" standalone, but it doesn't have the compiler. But everything else is in, including dictionary headers). I made it like the 8051 and avr systems above, without any double numbers math. I don't need 64bit numbers on the cortex even that it is not quite an overkill for these mcu's. Besides, without the 64bit numbers these systems are in fact 100% compatible which is quite nice. So, this is the context. I care only of embedded systems. I really don't care about the "host". A "Forth16e" standard for 16bit embedded systems is quite close to the ANS if not almost it. I think not much is to discuss about it. 200x standard even had done a good step in recognizing that double cells of any kind may not even be found in severly constrained 16bit systems. A "Forth32e" standard for 32bit embedded systems has some problems with the ANS standard. It may be already 90-95% of the ANS, maybe. It's the most interesting one to talk about. Once again, this talking is not about the forth ANS standard. I never wanted to be compliant with the standard, because I'm not selling anything. My forths are for me solely. But I was inspired by the ANS in some of my implementation decisions over time. If you ask me, I think ANS in the 200x form is maybe 90% of what it should have to be. My personal view is that the standard has (or had?) a chance to encourage new programming and new applications, and not maintaining legacy code all over again. But that's my personal view. All that I want to discuss here, is something like "de facto" standards for embedded. The ANS is here in the discussion as a point of reference. For example, a "Forth32e" de-facto standard goal is to provide good compatibility between 32bit systems for: - 8051 - AVR - PIC16, PIC24 - PIC32 - ARM of any kind - you name it
[toc] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-07-10 17:18 +0200 |
| Message-ID | <lpmat1$f9b$1@online.de> |
| In reply to | #32301 |
Raimond Dragomir wrote: > Hi all, > I don't want to start another ANS forth standard war here. > It's just my own experience that for an 32bit embedded system > (microcontroller class) a good simple ANS forth system or cross compiler > is quite an overkill. ANS maps quite good for a 16bit system, and that's > normal. But the compatibility between 16bit and 32bit adds a big overhead > for a 32bit system. Ok, so your proposal is to move the following words from core e.g. to the double number wordset (which is optional, and if you don't like it, don't include it:) # #S #> <# >NUMBER (in favor of a single cell >NUMBER variant? S>D SM/REM FM/MOD UM/MOD M* UM* and possible */, because it has a widening internal multiplication (in favor of a */ variant that doesn')? -- 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 08:41 -0700 |
| Message-ID | <f3cb0eab-df48-44c6-9b6d-1209b8d76bc3@googlegroups.com> |
| In reply to | #32306 |
joi, 10 iulie 2014, 18:18:56 UTC+3, Bernd Paysan a scris: > Raimond Dragomir wrote: > > > > > Hi all, > > > I don't want to start another ANS forth standard war here. > > > It's just my own experience that for an 32bit embedded system > > > (microcontroller class) a good simple ANS forth system or cross compiler > > > is quite an overkill. ANS maps quite good for a 16bit system, and that's > > > normal. But the compatibility between 16bit and 32bit adds a big overhead > > > for a 32bit system. > > > > Ok, so your proposal is to move the following words from core e.g. to the > > double number wordset (which is optional, and if you don't like it, don't > > include it:) > > > > # > > #S > > #> > > <# > > >NUMBER (in favor of a single cell >NUMBER variant? > > S>D > > SM/REM > > FM/MOD > > UM/MOD > > M* > > UM* > > > > and possible */, because it has a widening internal multiplication (in favor > > of a */ variant that doesn')? > > > > -- > > Bernd Paysan > > "If you want it done right, you have to do it yourself" > > http://bernd-paysan.de/ Something like that. Faking the */ is not a solution of course. I'm using a fake */ in my 32bit systems because I need it for scaling, but I should have renamed it different (I really don't know how :) I always have values for scale under 16bit. That comes not from my older 16bit systems but from actual real life sensors. From those words you listed, I feel that the <# # #S #> >NUMBER should have been in CORE EXT, the rest in the double number word set. But a single cell versions of these should or may be present, not necessarly in the core, could be in the core ext also. Well, my proposal is for a hypotethycal 32bit Forth standard for embedded systems. I'm sure nobody will take me seriously in respect with the ANS. But I really like to know what are other forthers doing in the embedded area, and if they have the same problems as I do.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-07-10 17:55 +0200 |
| Message-ID | <lpmd1j$mnc$1@online.de> |
| In reply to | #32309 |
Raimond Dragomir wrote: > But I really like to know what are other forthers doing in the embedded > area, and if they have the same problems as I do. Usually, you find 32 bit embedded Forths only on 32 bit platforms, e.g. the mecrisp-stellaris from Matthias Koch. There is no severe space limitation, so the double words simply go in. I think that's why nobody complained so far: For 16 bit systems, the double words are necessary, and for 32 bit Forths, they aren't a burden. There is enough space for them. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-07-10 19:53 +0000 |
| Message-ID | <53beef46$0$15881$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #32310 |
In article <lpmd1j$mnc$1@online.de>, Bernd Paysan <bernd.paysan@gmx.de> wrote: >Raimond Dragomir wrote: >> But I really like to know what are other forthers doing in the embedded >> area, and if they have the same problems as I do. > >Usually, you find 32 bit embedded Forths only on 32 bit platforms, e.g. the >mecrisp-stellaris from Matthias Koch. There is no severe space limitation, >so the double words simply go in. I think that's why nobody complained so >far: For 16 bit systems, the double words are necessary, and for 32 bit >Forths, they aren't a burden. There is enough space for them. For 64 bit systems, they are over the top, unless ... I'm very happy with all those double precision words for number theoretical applications (read projecteuler.net ) > >-- >Bernd Paysan -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | jacko <jackokring@gmail.com> |
|---|---|
| Date | 2014-07-15 05:15 -0700 |
| Message-ID | <e505b910-dbd0-4925-9089-05884808acea@googlegroups.com> |
| In reply to | #32321 |
On Thursday, 10 July 2014 20:53:42 UTC+1, Albert van der Horst wrote: > > I'm very happy with all those double precision words for number > > theoretical applications (read projecteuler.net ) > Certainly very useful in this arena. one of the reasons I added Q/ and Q* to a forth I was writing at the time but have not developed to working.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-10 09:02 -0700 |
| Message-ID | <bd5eff7a-19af-4bb7-8b7c-d8c4940b4051@googlegroups.com> |
| In reply to | #32309 |
For quite a long time, I didn't care much about portability of my applications. They were 16bit all (even if they were C), with very few 32bit operations for scaling. But when the first arm7tdmi micros appeared (lpc2106 and the like) I started thinking more about a 32bit system. I have done one for 8051 and one for my AVR boards. It turned that the 32bit system was cleaner, with less words (no need with lots of double number words) even if the basic system was slower. After the cortex chips appeared, I have done some applications with them, in C. I found that I still don't need double numbers (long longs), even if these applications was bigger. Now I'm porting a 32bit system for the cortex. And if I want portability of my previous work, it's natural to make the system "standard". But it's my "standard". I was thinking to make the cortex system ANS compatible. But it breaks the compatibility with the other systems, and making my other systems ANS compatible is just out of questions (I can't even think of 64bit math for the poor 8051 or avr). That's why I want to here other opinions. Maybe there are few people indeed that do what I'm doing (32bit systems for 8 or 16bitters) indeed. But I like more my 32bit system as it is, than an ANS 16bit one.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-07-10 15:45 -1000 |
| Message-ID | <mcWdnRV7AuFR3CLOnZ2dnUVZ_oOdnZ2d@supernews.com> |
| In reply to | #32309 |
On 7/10/14 5:41 AM, Raimond Dragomir wrote: > joi, 10 iulie 2014, 18:18:56 UTC+3, Bernd Paysan a scris: >> Raimond Dragomir wrote: >> >>> Hi all, >> >>> I don't want to start another ANS forth standard war here. >>> It's just my own experience that for an 32bit embedded system >>> (microcontroller class) a good simple ANS forth system or cross compiler >>> is quite an overkill. ANS maps quite good for a 16bit system, and that's >>> normal. But the compatibility between 16bit and 32bit adds a big overhead >>> for a 32bit system. ... > Faking the */ is not a solution of course. I'm using a fake */ in my 32bit systems because I need it for scaling, but I should have renamed it different (I really don't know how :) > I always have values for scale under 16bit. That comes not from my older 16bit systems but from actual real life sensors. > > From those words you listed, I feel that the <# # #S #> >NUMBER should have been in CORE EXT, the rest in the double number word set. But a single cell versions of these should or may be present, not necessarly in the core, could be in the core ext also. > > Well, my proposal is for a hypotethycal 32bit Forth standard for embedded systems. I'm sure nobody will take me seriously in respect with the ANS. > > But I really like to know what are other forthers doing in the embedded area, and if they have the same problems as I do. Well, FORTH, Inc. has been supporting products and writing custom applications for embedded systems since 1974. Obviously the technology has changed dramatically, but we have successfully followed that evolution with evolving Forth systems aimed at professional programmers. Until the early 80's, all of or systems used a 16-bit cell size. With the advent of the x86 and 68K families of processors, we began supporting both 16-bit and 32-bit implementations, and developed programming styles and practices to minimize the difficulties. We currently support 12 different processor families with our SwiftX cross-compilers, ranging from 8051's to i386, ARM, and 68K variants. Most of the 8-bit and 16-bit processors use a 16-bit Forth, although we have done a 32-bit 8051 implementation for a special project. Frankly, it has not been our experience that maintaining a reasonable level of compatibility across implementations of different cell sizes adds "a big overhead." We have over 30 files of source for kernel features that run without change on every processor we support. Individual processors additionally have about 20 files of source for processor-specific features, including an optimizing compiler, plus some for board-level features. Our priorities in our implementations are performance and programmer convenience second. We helped develop a draft cross-compiler standard (jointly with MPE) some years ago. I believe some people in the current Forth200x group are interested in updating it, but I don't know the current status. It does not, however, address cell size much beyond the strategies originally developed for Forth94. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-10 21:44 -0700 |
| Message-ID | <e2f5047d-10f6-4af7-b4f1-aaa77eb8e113@googlegroups.com> |
| In reply to | #32336 |
> > Well, FORTH, Inc. has been supporting products and writing custom > > applications for embedded systems since 1974. Obviously the technology > > has changed dramatically, but we have successfully followed that > > evolution with evolving Forth systems aimed at professional programmers. > > > > Until the early 80's, all of or systems used a 16-bit cell size. With > > the advent of the x86 and 68K families of processors, we began > > supporting both 16-bit and 32-bit implementations, and developed > > programming styles and practices to minimize the difficulties. > > > > We currently support 12 different processor families with our SwiftX > > cross-compilers, ranging from 8051's to i386, ARM, and 68K variants. > > Most of the 8-bit and 16-bit processors use a 16-bit Forth, although we > > have done a 32-bit 8051 implementation for a special project. > > > > Frankly, it has not been our experience that maintaining a reasonable > > level of compatibility across implementations of different cell sizes > > adds "a big overhead." We have over 30 files of source for kernel > > features that run without change on every processor we support. > > Individual processors additionally have about 20 files of source for > > processor-specific features, including an optimizing compiler, plus some > > for board-level features. Our priorities in our implementations are > > performance and programmer convenience second. > > > > We helped develop a draft cross-compiler standard (jointly with MPE) > > some years ago. I believe some people in the current Forth200x group are > > interested in updating it, but I don't know the current status. It does > > not, however, address cell size much beyond the strategies originally > > developed for Forth94. > > > > 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." > > ================================================== Forth 200x recognizes severly constrained embedded systems. It's a pleasant surprise for me. But I may add: In addition to severly constrained 16bit systems, there may be severly constrained 32bit systems also. 32bit systems like the old 8051. Or take a more modern and very popular AVR. 64bit multiplication a division is not something that I want my AVR to use on everyday application. It's just weird that double cell multiplication and divisions are "a must" for the current standard (core), but the D+ and D- are optional doubles :) You remainded me about that cross-compiler documents. I have them somewhere and I will read them. I have some plans for cross-compiling my newest cortex system.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-07-10 18:53 -1000 |
| Message-ID | <kJidnRtRQfNB8CLOnZ2dnUVZ_qudnZ2d@supernews.com> |
| In reply to | #32343 |
On 7/10/14 6:44 PM, Raimond Dragomir wrote: > Forth 200x recognizes severly constrained embedded systems. It's a pleasant surprise for me. But I may add: In addition to severly constrained 16bit systems, there may be severly constrained 32bit systems also. 32bit systems like the old 8051. Or take a more modern and very popular AVR. 64bit multiplication a division is not something that I want my AVR to use on everyday application. > > It's just weird that double cell multiplication and divisions are "a must" for the current standard (core), but the D+ and D- are optional doubles :) At least, */ is trivial to implement with a double intermediate product, because on most processors MUL leaves a double product in registers, and DIV takes a double dividend in the same registers. So it's a no-brainer to do in code. And it's an incredibly useful word. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-11 12:59 +0000 |
| Message-ID | <2014Jul11.145910@mips.complang.tuwien.ac.at> |
| In reply to | #32345 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>At least, */ is trivial to implement with a double intermediate product,
>because on most processors MUL leaves a double product in registers, and
>DIV takes a double dividend in the same registers.
When I actually looked, it was not that many. Looking at the
platforms supported by Gforth (non-EC):
yes 386
no alpha (mixed multiplication, but no division)
yes amd64
no? arm
no? hppa (probably no division)
no? ia64 (certainly not used in Gforth)
yes m68k
yes mips (has two special-purpose registers for this)
no power (no mixed mul/div support at all)
yes sparc (mul/div step support, later full muls)
>So it's a no-brainer
>to do in code.
If I had known how messy it is in advance, I probably would not have
reworked the mixed division words in 2006.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-07-11 09:33 -0500 |
| Message-ID | <kuidndKcHbY-aCLOnZ2dnUVZ8nWdnZ2d@supernews.com> |
| In reply to | #32354 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >>At least, */ is trivial to implement with a double intermediate product, >>because on most processors MUL leaves a double product in registers, and >>DIV takes a double dividend in the same registers. > > When I actually looked, it was not that many. Looking at the > platforms supported by Gforth (non-EC): > > yes 386 > no alpha (mixed multiplication, but no division) > yes amd64 > no? arm I agree. ARM has MUL for the low part and MULH for the high part. Division is still something of a problem: I don't think there's any easy way to do it. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-07-11 07:33 -1000 |
| Message-ID | <lrednat31Z1Igl3OnZ2dnUVZ_qGdnZ2d@supernews.com> |
| In reply to | #32354 |
On 7/11/14 2:59 AM, Anton Ertl wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> At least, */ is trivial to implement with a double intermediate product, >> because on most processors MUL leaves a double product in registers, and >> DIV takes a double dividend in the same registers. > > When I actually looked, it was not that many. Looking at the > platforms supported by Gforth (non-EC): > > yes 386 > no alpha (mixed multiplication, but no division) > yes amd64 > no? arm > no? hppa (probably no division) > no? ia64 (certainly not used in Gforth) > yes m68k > yes mips (has two special-purpose registers for this) > no power (no mixed mul/div support at all) > yes sparc (mul/div step support, later full muls) > >> So it's a no-brainer >> to do in code. > > If I had known how messy it is in advance, I probably would not have > reworked the mixed division words in 2006. That's very interesting. I am not familiar with some of those. My observation was certainly true some years ago (the 386/68K/SPARC generation and before). Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2014-07-11 20:32 -0700 |
| Message-ID | <1bdc399d-3fa0-4888-9d56-747b664ecd48@googlegroups.com> |
| In reply to | #32336 |
On Thursday, July 10, 2014 9:45:47 PM UTC-4, Elizabeth D. Rather wrote: > Well, FORTH, Inc. has been supporting products and writing custom > applications for embedded systems since 1974. Obviously the technology > has changed dramatically, but we have successfully followed that > evolution with evolving Forth systems aimed at professional programmers. I started ten years later, 1984, using RSC-Forth, but I can confirm, the technology obviously has changed dramatically: while Rockwell's 6511AQ only had a serial line and timers on chip, nowadays microcontrollers have all sorts of hardware I/O on chip. In my opinion it would be helpful, especially for people new to Forth, if there would be words like @ADC, !DAC, !PWM, !SPI, @SPI and so forth supported. Then a program probably would still run when changing to another microprocessor model. I am sorry, I never worked with Swift Forth. Does Swift Forth support these words - @ADC, !DAC, !PWM, !SPI, @SPI as example? I know this is a challenge. It would be great if there would be some kind of standard to make microcontroller Forth programs portable.
[toc] | [prev] | [next] | [standalone]
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2014-07-11 18:02 -1000 |
| Message-ID | <FbSdnRYwN5PZLl3OnZ2dnUVZ_rednZ2d@supernews.com> |
| In reply to | #32371 |
On 7/11/2014 5:32 PM, visualforth@rocketmail.com wrote: > On Thursday, July 10, 2014 9:45:47 PM UTC-4, Elizabeth D. Rather wrote: > >> Well, FORTH, Inc. has been supporting products and writing custom >> applications for embedded systems since 1974. Obviously the technology >> has changed dramatically, but we have successfully followed that >> evolution with evolving Forth systems aimed at professional programmers. > > I started ten years later, 1984, using RSC-Forth, but I can confirm, the technology obviously has changed dramatically: while Rockwell's 6511AQ only had a serial line and timers on chip, nowadays microcontrollers have all sorts of hardware I/O on chip. > > In my opinion it would be helpful, especially for people new to Forth, if there would be words like @ADC, !DAC, !PWM, !SPI, @SPI and so forth supported. Then a program probably would still run when changing to another microprocessor model. > > I am sorry, I never worked with Swift Forth. Does Swift Forth support these words - @ADC, !DAC, !PWM, !SPI, @SPI as example? > > I know this is a challenge. It would be great if there would be some kind of standard to make microcontroller Forth programs portable. > SwiftX is our product for embedded systems. It's an interactive cross-compiler that runs as a SwiftForth application (Win, Linux, OSX) and supports many boards on the most popular microcontrollers. SwiftX supports the I/O on each board, with demo apps that use it, and all source is available so you can adapt to different hardware. The concept of "standardizing" functions like that is interesting, but in my experience there's too much variance in the actual hardware to make it completely portable. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul E Bennett <Paul_E.Bennett@topmail.co.uk> |
|---|---|
| Date | 2014-07-12 11:54 +0100 |
| Message-ID | <c2ciflFdjsU1@mid.individual.net> |
| In reply to | #32371 |
visualforth@rocketmail.com wrote: > On Thursday, July 10, 2014 9:45:47 PM UTC-4, Elizabeth D. Rather wrote: > >> Well, FORTH, Inc. has been supporting products and writing custom >> applications for embedded systems since 1974. Obviously the technology >> has changed dramatically, but we have successfully followed that >> evolution with evolving Forth systems aimed at professional programmers. > > I started ten years later, 1984, using RSC-Forth, but I can confirm, the > technology obviously has changed dramatically: while Rockwell's 6511AQ > only had a serial line and timers on chip, nowadays microcontrollers have > all sorts of hardware I/O on chip. > > In my opinion it would be helpful, especially for people new to Forth, if > there would be words like @ADC, !DAC, !PWM, !SPI, @SPI and so forth > supported. Then a program probably would still run when changing to > another microprocessor model. > > I am sorry, I never worked with Swift Forth. Does Swift Forth support > these words - @ADC, !DAC, !PWM, !SPI, @SPI as example? > > I know this is a challenge. It would be great if there would be some kind > of standard to make microcontroller Forth programs portable. I think these words (or very similar) exist on some systems but they have been connected with specific boards and attached Forth products. I have worked on some systems that had used the Triangle Digital Services TDS modules where these words were part of the basic provision. Unfortunately, Peter Rush has now retired and folded the company. -- ******************************************************************** Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk> Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk> Mob: +44 (0)7811-639972 Tel: +44 (0)1235-510979 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-07-20 23:41 -0400 |
| Message-ID | <lqi24q$g92$1@dont-email.me> |
| In reply to | #32371 |
On 7/11/2014 11:32 PM, visualforth@rocketmail.com wrote: > On Thursday, July 10, 2014 9:45:47 PM UTC-4, Elizabeth D. Rather wrote: > >> Well, FORTH, Inc. has been supporting products and writing custom >> applications for embedded systems since 1974. Obviously the technology >> has changed dramatically, but we have successfully followed that >> evolution with evolving Forth systems aimed at professional programmers. > > I started ten years later, 1984, using RSC-Forth, but I can confirm, the technology obviously has changed dramatically: while Rockwell's 6511AQ only had a serial line and timers on chip, nowadays microcontrollers have all sorts of hardware I/O on chip. > > In my opinion it would be helpful, especially for people new to Forth, if there would be words like @ADC, !DAC, !PWM, !SPI, @SPI and so forth supported. Then a program probably would still run when changing to another microprocessor model. > > I am sorry, I never worked with Swift Forth. Does Swift Forth support these words - @ADC, !DAC, !PWM, !SPI, @SPI as example? > > I know this is a challenge. It would be great if there would be some kind of standard to make microcontroller Forth programs portable. I don't know that it would be such a challenge to create these words for each system. They are simple words to implement normally. But they are also of limited use. If you are programming a power supply monitor which needs to sample a battery voltage periodically then these words would be useful. But in any app which needs a data stream with accurate timing of the samples this is typically done using DMA and would not use these words at all. Rather blocks of data would be transferred. In fact, these words should be so simple to implement that you can easily do that yourself for each platform you intend to run on. Why is this a problem? Any platform you use will have unique hardware. It would be a lot of work to provide words for every function found in a modern MCU. I would not expect that to be part of a basic chip support package... but then that is just me. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-07-20 21:09 -1000 |
| Message-ID | <NP-dnVdQTJg2IVHOnZ2dnUVZ_rudnZ2d@supernews.com> |
| In reply to | #32505 |
On 7/20/14 5:41 PM, rickman wrote: > On 7/11/2014 11:32 PM, visualforth@rocketmail.com wrote: >> On Thursday, July 10, 2014 9:45:47 PM UTC-4, Elizabeth D. Rather wrote: ... >> I am sorry, I never worked with Swift Forth. Does Swift Forth support >> these words - @ADC, !DAC, !PWM, !SPI, @SPI as example? >> >> I know this is a challenge. It would be great if there would be some >> kind of standard to make microcontroller Forth programs portable. The problem is, the devices are all different. Do you have to request a conversion before you can do a @ADC? Is it interrupt driven? What timing issues does your application you have? In my experience, these are usually trivial definitions (e.g. one line in assembler, plus a one-line interrupt handler in some cases), and all different with different hardware and different application requirements. Much better to write them the way you need them. > I don't know that it would be such a challenge to create these words for > each system. They are simple words to implement normally. But they are > also of limited use. If you are programming a power supply monitor > which needs to sample a battery voltage periodically then these words > would be useful. But in any app which needs a data stream with accurate > timing of the samples this is typically done using DMA and would not use > these words at all. Rather blocks of data would be transferred. Exactly. If you're doing high-speed data acquisition, you may need to set up a circular buffer for the input with an asynchronous task writing the data to mass storage, with or without calibration, etc. All these situations are very different. > In fact, these words should be so simple to implement that you can > easily do that yourself for each platform you intend to run on. Why is > this a problem? Any platform you use will have unique hardware. It > would be a lot of work to provide words for every function found in a > modern MCU. I would not expect that to be part of a basic chip support > package... but then that is just me. > I agree. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-07-11 00:59 -0700 |
| Message-ID | <c46057c7-fd0c-42eb-a33e-d291380a9700@googlegroups.com> |
| In reply to | #32309 |
On Thursday, 10 July 2014 16:41:00 UTC+1, Raimond Dragomir wrote: > From those words you listed, I feel that the <# # #S #> >NUMBER should have been in CORE EXT, the rest in the double number word set. But a single cell versions of these should or may be present, not necessarly in the core, could be in the core ext also. Fully agree. As you pointed out, it does make sense that in 16-bit systems, <# #S #> and friends are 32-bit. I fully agree that it is overkill in the 32-bit world. The committee shouldn't be afraid to deviate from previous standards on this issue.
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-10 09:06 -0700 |
| Message-ID | <b2a08704-fa4d-493b-b94d-558ae9cbf6a1@googlegroups.com> |
| In reply to | #32301 |
On Thursday, July 10, 2014 5:35:12 AM UTC-4, Raimond Dragomir wrote: > Hi all, > Here are two sensible areas: > > 1. picture numeric output. > > It imposes the usage of double numbers. For a 16bit system it is about ok. You're likely to need it, and if you really want, you can add a 16bit numeric output version for where the absolute performance is needed. > > But for a 32bit system it requires 64bit numbers and maths. That's huge. I never needed 64bit in my 20years of embedded, being C or forth or anything else. Also, just think that the 32bit system is not a Cortex-M, maybe it is an 8051! (I have an 8051 system which I made 32bit because it's just plain simpler to work with). > > So, for picture numeric output, a "single cell" version is in fact the most usefull for embedded, and the double cell version might be an otional feature. > > Why is it a problem for 32bit and not for 16 bit? Because for 16bit the single cell variant can be optional and you are ANS compliant, but for the 32bitters you can do a single cell variant but you MUST carry the double cell variant to be ANS compliant. But you can include the single cell version ~ say they are called ## ##S and ##> ~ in the binary, and provide source for # #S and #> and still be compliant. So the issue is more of reserving a standard name for the single cell versions of # #S and #> > 2. FM/MOD, SM/REM and mixed precision math. > Mixed precision has the same problem as the picture numeric output above. Again, I never needed 64 bit numbers even for scaling. And I have done a lot of applications that needed scaling, including for 32bit microcontrollers. In fact, I don't have a single application done with floating point stuff. Well, you can fake a */ like this: : */ * / ; for a 32bit system, but that's not the point. I wouldn't personally have any trouble with changing "producing the intermediate double-cell result d." to "producing the intermediate result d with a size of at least 32 bits." But reducing programmer entitlements under the existing standard is always an issue, and while there may not be much need in embedded applications for an intermediate precision in excess of 32 bits, it would be less surprising if there were desktop applications that relied on it. The most direct solution is to standardize a version of */ under a new name that has the "producing the intermediate result d with a size of at least 32 bits." behavior, and systems that wish to include that in the binary and leave */ to a source file may do so. It seems that W*/ or L*/ would be evocative names for that. Or else a version which would also be faster on 16 bit implementations on a processor with hardware 16 bit multiple with carry, "single-cell times divide": ``S*/ ( n1 n2 n3 -- n4 ) CORE EXT Multiply n1 by n2 producing the intermediate single-cell result d. ...'' > 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. A system that is based on SM/REM including source for an FM/MOD does not seem to me like its a big ask, since its a definition that can be found by hunting around online. > Both have symmetric division, and I really not care about it in fact, because I never had a need for dividing negative numbers until now Many of the scientific applications where SM/REM is broken and FM/MOD has to be defined if its not available are unlikely to be required in an embedded applications, but in unit conversions for data logging, it matters, as SM/REM introduces an over-representation of 0's, resulting in false results when regressing the numbers. It also biases the the slope of a regression function most strongly precisely when regressing over a limited range of data, so getting the poorest fit precisely when getting an unbiased fit is most important to distinguish statistically significant from statistically not significant results. Typically in long term remote site data logging, getting the right number logged is more important than getting the wrong number logged faster. > - I have now a cortex-m 32bit system (it's "almost" standalone, but it doesn't have the compiler. But everything else is in, including dictionary headers). > > I made it like the 8051 and avr systems above, without any double numbers math. I don't need 64bit numbers on the cortex even that it is not quite an overkill for these mcu's. Besides, without the 64bit numbers these systems are in fact 100% compatible which is quite nice. > > So, this is the context. I care only of embedded systems. I really don't care about the "host". > > A "Forth16e" standard for 16bit embedded systems is quite close to the ANS if not almost it. I think not much is to discuss about it. 200x standard even had done a good step in recognizing that double cells of any kind may not even be found in severely constrained 16bit systems. > > A "Forth32e" standard for 32bit embedded systems has some problems with the ANS standard. It may be already 90-95% of the ANS, maybe. It's the most interesting one to talk about. > Once again, this talking is not about the forth ANS standard. I never wanted to be compliant with the standard, because I'm not selling anything. My forths are for me solely. 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. But quite often, Forth compliance is a matter of simply using different names when you want to do something different to what the standard specifies. The main exceptions are when Forth94 specifies a minimum buffer or length requirement that is unsuitable for an implementation, in which case one can always say an implementation is "Forth aligned, except the text input buffer is 63 bytes, the maximum word size is 15 chars and, and PAD is simply the space available two cells above HERE, which is not guaranteed to provide 84 characters of space". But I was inspired by the ANS in some of my implementation decisions over time. If you ask me, I think ANS in the 200x form is maybe 90% of what it should have to be. My personal view is that the standard has (or had?) a chance to encourage new programming and new applications, and not maintaining legacy code all over again. But that's my personal view. > > > > All that I want to discuss here, is something like "de facto" standards for embedded. The ANS is here in the discussion as a point of reference. > > For example, a "Forth32e" de-facto standard goal is to provide good compatibility between 32bit systems for: > > - 8051 > > - AVR > > - PIC16, PIC24 > > - PIC32 > > - ARM of any kind > > - you name it
[toc] | [prev] | [next] | [standalone]
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web