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 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-13 09:35 -0700 |
| Message-ID | <0353d5b0-addd-4270-8029-ff6cc57a871f@googlegroups.com> |
| In reply to | #32406 |
> But the context of the comment was an implementor *not* including UM/MOD *in any form*, with the user left to their own devices to implement it. When I am writing in the first person there, it is with respect to a Forth user who emphatically has no familiarity with any of these machines at assembly language level. The last assembly language I learned was the Z80, when I got my Geneva to take with me to Grenada to teach secondary school Maths. > > I'm talking about a 32bit system not providing doubles in any form, and a user not needing them either. Think of an 32bit system on an 8bit microcontroller. AVR can do it resonably well, some newer 8051's also. But no 64bit math (or mixed 32/64). If the user finds that it needs the 64bit operations, it's the wrong microcontroller choice in the first place. Go back and take an usual cortex-m mcu and you are done.
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-13 10:02 -0700 |
| Message-ID | <4aef9c8c-6472-4076-aa67-329bb9a8341c@googlegroups.com> |
| In reply to | #32407 |
On Sunday, July 13, 2014 12:35:42 PM UTC-4, Raimond Dragomir wrote: > I'm talking about a 32bit system not providing doubles in any form, and a user not needing them either. There is likely to be more unpredictability about what a future user may or may not need when laying out a set of words to be assumed in shared source than when an implementer is also the sole user of the system.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-07-13 12:18 -0500 |
| Message-ID | <_ZWdnTVknL3GIl_OnZ2dnUVZ_qudnZ2d@supernews.com> |
| In reply to | #32407 |
Raimond Dragomir <raimond.dragomir@gmail.com> wrote: >> > I'm talking about a 32bit system not providing doubles in any form, > and a user not needing them either. Think of an 32bit system on an > 8bit microcontroller. AVR can do it resonably well, some newer > 8051's also. I don't really understand this. What is a 32-bit Forth on an 8051 for? Even addition is going to be painful 8 bits at a time, and there's no need for 64-bit addressing. A 16-bit Forth with mixed- precision arithmetic is surely a better fit. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-13 10:45 -0700 |
| Message-ID | <7469b1de-8a4f-4605-9163-234ed345af57@googlegroups.com> |
| In reply to | #32410 |
duminică, 13 iulie 2014, 20:18:19 UTC+3, Andrew Haley a scris: > Raimond Dragomir <raimond.dragomir@gmail.com> wrote: > > >> > > > I'm talking about a 32bit system not providing doubles in any form, > > > and a user not needing them either. Think of an 32bit system on an > > > 8bit microcontroller. AVR can do it resonably well, some newer > > > 8051's also. > > > > I don't really understand this. What is a 32-bit Forth on an 8051 > > for? Even addition is going to be painful 8 bits at a time, and > > there's no need for 64-bit addressing. A 16-bit Forth with mixed- > > precision arithmetic is surely a better fit. > > > > Andrew. For me is a simpler, cleaner system, with fewer words. For 16bit addresses I have PUSH and POP if I wanted the addresses on the return stack. >R and the like cannot be used when you really want the return addresses. The 32bit forth system is for big applications, which you still can do with an 8051. For small applications you may find even the 16bit system be an overkill. I had done many small aplications on the 8051 that barely had one or two 16bit variables. The rest were all 8bits. An 8bit forth system with 16bit double numbers would had been just perfect!
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-07-13 08:06 -1000 |
| Message-ID | <2vudnVsYnfI_V1_OnZ2dnUVZ_r6dnZ2d@supernews.com> |
| In reply to | #32411 |
On 7/13/14 7:45 AM, Raimond Dragomir wrote: > duminică, 13 iulie 2014, 20:18:19 UTC+3, Andrew Haley a scris: >> Raimond Dragomir <raimond.dragomir@gmail.com> wrote: >> >>>> >> >>> I'm talking about a 32bit system not providing doubles in any form, >> >>> and a user not needing them either. Think of an 32bit system on an >> >>> 8bit microcontroller. AVR can do it resonably well, some newer >> >>> 8051's also. >> >> >> >> I don't really understand this. What is a 32-bit Forth on an 8051 >> >> for? Even addition is going to be painful 8 bits at a time, and >> >> there's no need for 64-bit addressing. A 16-bit Forth with mixed- >> >> precision arithmetic is surely a better fit. >> >> >> >> Andrew. > > For me is a simpler, cleaner system, with fewer words. For 16bit addresses I have PUSH and POP if I wanted the addresses on the return stack. >R and the like cannot be used when you really want the return addresses. > The 32bit forth system is for big applications, which you still can do with an 8051. > For small applications you may find even the 16bit system be an overkill. I had done many small aplications on the 8051 that barely had one or two 16bit variables. The rest were all 8bits. An 8bit forth system with 16bit double numbers would had been just perfect! > An 8-bit Forth has severe limitations for things like loop indices, and it's a royal pain to treat addresses (2 bytes) differently from other stack items. Yes, 8-bit variables are good, which is why we use CVARIANLE, C@, C! etc. But for the rest of your computing needs, a simple 16-bit implementation works great with minimal overhead. 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-07-13 08:02 -1000 |
| Message-ID | <u_SdnXkGM8YkVF_OnZ2dnUVZ_vadnZ2d@supernews.com> |
| In reply to | #32410 |
On 7/13/14 7:18 AM, Andrew Haley wrote: > Raimond Dragomir <raimond.dragomir@gmail.com> wrote: >>> >> I'm talking about a 32bit system not providing doubles in any form, >> and a user not needing them either. Think of an 32bit system on an >> 8bit microcontroller. AVR can do it resonably well, some newer >> 8051's also. > > I don't really understand this. What is a 32-bit Forth on an 8051 > for? Even addition is going to be painful 8 bits at a time, and > there's no need for 64-bit addressing. A 16-bit Forth with mixed- > precision arithmetic is surely a better fit. Having actually worked on a 32-bit Forth on 8051's (for a special project) I completely agree with Andrew. Why penalize absolutely everything you do (most of which doesn't require 32 bits)? If you write sensible application code (using the CELL words for address manipulation as appropriate, etc.) there is very little difficulty in porting application code between 16-bit and 32-bit Forths. 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 | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2014-07-11 10:28 +0100 |
| Message-ID | <lpoaoa$ovt$1@dont-email.me> |
| In reply to | #32323 |
On 10/07/2014 20:56, bruce.mcfarling@gmail.com wrote:
> So? If your SM/REM is that fast, I'd rather have an FM/MOD written based on that than a FM/MOD written from scratch. Andreas, one of the previous times this came up, had:
>
> : FM/MOD \ ( d m -- r q ) signed floored division
> DUP >R SM/REM 2DUP 0< AND IF 1- SWAP R> + SWAP ELSE R> DROP THEN ;
>
> .... if there is more threading overhead in there than processing time, then that would imply there is a reasonably fast SM/REM ... and leveraging that fast SM/REM is*precisely what someone who needs FM/MOD would want to do*.
>
> A two liner definition which is easy to get a corner case wrong is exactly sometime I would be happy to find if an implementation told me:
> ? FM/MOD
Well in that case I wouldn't use the above definition, it is flawed
(pardon the pun) e.g.
~~~~~~~~~~
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
: FM/MOD \ ( d m -- r q ) signed floored division compiled
DUP >R SM/REM 2DUP 0< AND IF 1- SWAP R> + SWAP ELSE R> DROP THEN ;
redefined fm/mod with FM/MOD ok
-10. 15 fm/mod .s <2> -10 0 ok
~~~~~~~~~~
but the correct answer is ( 5 -1 )
I think this has been pointed out before.
This seems to work but there ought to be a better solution
: fm/mod dup >r 2dup xor 0< >r sm/rem
over r> and if 1- swap r> + swap else r> drop then
;
--
Gerry
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-11 06:28 -0700 |
| Message-ID | <c57cbafc-d3c1-4555-8fb7-e0e37f39d959@googlegroups.com> |
| In reply to | #32349 |
On Friday, July 11, 2014 5:28:55 AM UTC-4, Gerry wrote: > Well in that case I wouldn't use the above definition, it is flawed > (pardon the pun) e.g. See the benefit of having a tested solution in source as opposed to expecting people to Google for a definition? Not all definitions that one googles for are the correct definition.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-07-10 20:18 +0000 |
| Message-ID | <53bef506$0$15881$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #32319 |
In article <fb6046ef-72a1-45b2-9b08-8d9c6a8d364b@googlegroups.com>, Raimond Dragomir <raimond.dragomir@gmail.com> wrote: >> ... in the implementation and the problem is fixed ... and if there is ><# # #S and #> defined in a source file somewhere, then you've >"provided" those CORE words. > >> Making FM/MOD CORE means that an implementer that doesn't include it >in the binary of their system really ought to include source for the >FM/MOD word for the use of those who need it. > >Personally, I have a big problems with this kind of solution: providing >in source form anything that you don't provide. And this seems to be the >solution for everything. > >To me this sounds like: "I really don't have this XXX word. But if you >really want it, and you don't know how to write it in terms of the other >words that I do have, or if you really tried hard to find an >implementation over internet but didn't find anything, take this source, >I wrote it for you". > >I will give you one single example: For a FM/MOD in source form, only >the threading overhead (I have a token threading for the cortex, others >may have ITC or DTC) is going to take longer than the whole routine >written in assembly. Since when is source equivalent to no assembly allowed? Or even CODE FM/MOD 5A C, 5B C, 58 C, ... NEXT, END-CODE 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 | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-12 19:01 -0700 |
| Message-ID | <62cc3792-e246-4f0b-b671-c09908d5f3b0@googlegroups.com> |
| In reply to | #32319 |
On Thursday, July 10, 2014 11:59:02 AM UTC-7, Raimond Dragomir wrote: > I will give you one single example: For a FM/MOD in source form, only the threading overhead (I have a token threading for the cortex, others may have ITC or DTC) is going to take longer than the whole routine written in assembly. I have D/ in the novice package, written in ANS-Forth. D/ should be in the standard so that it would be written in assembly-language by the compiler-writer. Writing such a low-level word in high-level Forth results in abysmal performance. It can be in an optional word-set so it can be ignored by those who don't need it --- but it should be in the standard so everybody provides it in the same way --- when such things don't get put in the standard, they end up being implemented differently by everybody, and this doesn't allow programs to port from one system to another (which is the point of having a standard). What I have (everything in the CF.4TH file) was written by Nathaniel Grosman in an FD article in the 1980s for 16-bit Forth-83 --- all I did was upgrade it to work on a 32-bit ANS-Forth system --- this was a trivial upgrade. D/ was provided in CF.4TH for use in continued fractions, which are typically calculated at compile-time, so speed isn't an issue in this case. I wouldn't recommend using my D/ on any speed-critical program --- it would be best to write it in assembly-language and abandon ANS-Forth compliance.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-15 22:18 -0700 |
| Message-ID | <b84a41d6-21a1-4378-9d4a-0587d9799ae6@googlegroups.com> |
| In reply to | #32396 |
On Saturday, July 12, 2014 7:01:31 PM UTC-7, hughag...@yahoo.com wrote: > On Thursday, July 10, 2014 11:59:02 AM UTC-7, Raimond Dragomir wrote: > > > I will give you one single example: For a FM/MOD in source form, only the threading overhead (I have a token threading for the cortex, others may have ITC or DTC) is going to take longer than the whole routine written in assembly. > > I have D/ in the novice package, written in ANS-Forth. D/ should be in the standard so that it would be written in assembly-language by the compiler-writer. Writing such a low-level word in high-level Forth results in abysmal performance. It can be in an optional word-set so it can be ignored by those who don't need it --- but it should be in the standard so everybody provides it in the same way --- when such things don't get put in the standard, they end up being implemented differently by everybody, and this doesn't allow programs to port from one system to another (which is the point of having a standard). > > What I have (everything in the CF.4TH file) was written by Nathaniel Grosman in an FD article in the 1980s for 16-bit Forth-83 --- all I did was upgrade it to work on a 32-bit ANS-Forth system --- this was a trivial upgrade. > > D/ was provided in CF.4TH for use in continued fractions, which are typically calculated at compile-time, so speed isn't an issue in this case. I wouldn't recommend using my D/ on any speed-critical program --- it would be best to write it in assembly-language and abandon ANS-Forth compliance. This was discussed way back in 2009 when I was implementing the continued fraction code: https://groups.google.com/forum/#!topic/comp.lang.forth/BcWvGxFFuzA%5B1-25-false%5D This thread was actually my very first contact with the dynamic duo of Elizabeth Rather and John Passaniti (I didn't know that Passaniti was homosexual at the time, but he would burst out of the closet later on in this thread). Elizabeth Rather and I had this exchange: On Friday, November 20, 2009 12:07:12 AM UTC-7, Elizabeth D Rather wrote: > Hugh Aguilar wrote: > ... > > The problem is the ANS-Forth standard. Really, how obvious was the > > need for double-precision arithmetic? This could have been an > > extension to the language similar to floating-point. Compiler-writers > > working on small microprocessors could decline to implement it if they > > didn't want to. > > > > I am frustrated with the ANS-Forth standard because I believe that the > > bad design of the standard is the #1 reason for the failure of Forth > > to become an important language. Forth was doing pretty well in the > > 1980s, but we needed a standard. What we got was Forth-83, and then > > ANS-Forth-94, both of which were badly designed. With some more > > thoughtful leadership we could have succeeded. > There are D+, D-, M*, M/, and M*/ (and the unsigned operators). These > were adequate in a very wide variety of projects over a 30 year period, > many of which were extremely computation-intensive and running on slow > 16-bit processors. > > Forth's design is pragmatic: it has functions that have been needed and > that have proven their usefulness *in Forth*, not necessarily those that > have been required in other languages. Generally speaking, Forth has > the most flexible set of *integer* arithmetic operators of any language. > In particular, M*/ was one of Chuck's most brilliant innovations. I'm > sure if Chuck were trying to do your continued fractions that is what he > would rely on. Yes, that sometimes requires thinking differently, like > many other things in Forth. > > Cheers, > Elizabeth I think that it is pretty obvious that the reason why ANS-Forth doesn't have D/ is because nobody at Forth Inc. could figure out how to implement it. Note that Elizabeth Rather doesn't tell me how to implement my continued fraction program using M*/ --- she just says that Chuck Moore is brilliant and would be able to do so somehow --- in all likelihood, she doesn't know what continued fractions are. I ended up implementing D/ myself in high-level Forth in order to get the continued fraction program to work --- I haven't the slightest idea how to get this program to work with M*/ --- I'm not brilliant at all!
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-16 00:01 -0700 |
| Message-ID | <b2665081-48ec-4c99-951e-e82e1558e340@googlegroups.com> |
| In reply to | #32428 |
> > > The problem is the ANS-Forth standard. Really, how obvious was the > > > > need for double-precision arithmetic? This could have been an > > > > extension to the language similar to floating-point. Compiler-writers > > > > working on small microprocessors could decline to implement it if they > > > > didn't want to. > Exactly. I will concentrate on cortex-m microcontrollers (m0, m3, m4) but even so I don't like the 64bit math, because I just don't need it. But a 32bit system is usefull for smaller microcontrollers also. Even that noone seems to agree this for an 8051 or avr (avr is quite decent though) I can think of elegant implementations for MSP430 or PIC24 which are 16bitters. Anyway, forth has this single cell/double cell "compatibility" kind of view, which is nice, but not all the time. C had, and still has the same kind of thing regarding the "int". The "int" may be 16bit or 32bit, depending on the cpu architecture. The compiler writer choose this by design, in an obvious way. But C does recognize the need of specifying the size of objects directly. That's why it has int8_t, int16_t, int32_t, int64_t and the unsigned uint... etc, even that this is done with some defines or typedefs. However, almost all c programmers have personal preferences and don't use the <std> types... They instead use u16, u32, U08, BYTE, WORD or god knows what else... The idea is: sometimes you need an "int", a forth "cell". You don't care what the size is because you really know it is enough (a small index, or other variable) and you want it to be the most easy thing the system can deal with. But many times you need specific sizes. For example, I have an application with large tables of 16bit values. I choose the 16bit value despite the cpu being 32bit, because it saved me lot of ram. That brings me the real need of having half cells in my 32bit forth, H@, H!. The point is: Using (only) the terms "single" and "double" "cell" for portability is not enough in itself without the direct size specifiers. Now I'm having H@ H! for my 32bit forth, but these are just not possible in a 16bit forth. Also, for "doubles", if I use doubles in a 16bit systems, those will compile as 64bit objects in a 32bit forth system. People using doubles in the 16bit forths are using them because they need 32bits. Why forcing them to use 64bits in a 32bit forth system? People do not need "doubles". They need specific sizes that cover their needs, and use the double because this is what they have at hand. It is used with care anyway. Well, long story for quite a short subject. CELL compatibility is needed, and a good to have. For forth is almost a must because of the stacks. But it must stop here. "Doubles" shouldn't exist. Along with CELL, it must exists byte/char/int8, in16, int32, int64 or any better names you can find for forth. They will use N CELLS of stack each and this is a problem of documenting the system (ENVIRONMENT? queries)
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-16 18:25 -0700 |
| Message-ID | <9f8a7188-7ef0-4ae4-8341-e27a41f9a44b@googlegroups.com> |
| In reply to | #32429 |
On Wednesday, July 16, 2014 12:01:50 AM UTC-7, Raimond Dragomir wrote: > The idea is: sometimes you need an "int", a forth "cell". You don't care what the size is because you really know it is enough (a small index, or other variable) and you want it to be the most easy thing the system can deal with. Agreed. You may need "at least" 16-bits for an index or whatever. This doesn't mean that you necessarily want a 16-bit though --- on most 32-bit processors, using a 16-bit register is slower than using a 32-bit register --- for stuff like this, you are best off to use the "natural" size. > But many times you need specific sizes. For example, I have an application with large tables of 16bit values. I choose the 16bit value despite the cpu being 32bit, because it saved me lot of ram. That brings me the real need of having half cells in my 32bit forth, H@, H!. Agreed. The size of the data is inherent in the data --- it is irrelevant whether the processor is 16-bit or 32-bit. You should be able to port a program from a 16-bit processor to a 32-bit processor without your memory usage doubling for no point. This can be an issue when you have a huge amount of data. With my language, I have abandoned the ANS-Forth idea of the language running on any size of processor. I require a 64-bit processor. I actually have two languages. HostForth is 64-bit and runs on desktop computers. TargForth is a cross-compiler written in HostForth that targets micro-controllers. These may be 16-bit or 32-bit. HostForth and TargForth are not compatible --- it is unrealistic to expect the same language to run on a big desktop computer and a little micro-controller --- the environments are just too different. I will give some thought to your suggestions in regard to TargForth so that programs can easily be ported between 16-bit and 32-bit micro-controllers. This discussion isn't relevant to HostForth however, because it is fixed at 64-bit.
[toc] | [prev] | [next] | [standalone]
| From | Alexander Skobelev <al.skobelev@gmail.com> |
|---|---|
| Date | 2014-07-17 10:21 +0400 |
| Message-ID | <m2oawo1p4z.fsf@gmail.com> |
| In reply to | #32436 |
hughaguilar96@yahoo.com writes: > [...] > With my language, I have abandoned the ANS-Forth idea of the language > running on any size of processor. I require a 64-bit processor. > > I actually have two languages. HostForth is 64-bit and runs on desktop > computers. TargForth is a cross-compiler written in HostForth that > targets micro-controllers. These may be 16-bit or 32-bit. HostForth > and TargForth are not compatible --- it is unrealistic to expect the > same language to run on a big desktop computer and a little > micro-controller --- the environments are just too different. > > I will give some thought to your suggestions in regard to TargForth so > that programs can easily be ported between 16-bit and 32-bit > micro-controllers. This discussion isn't relevant to HostForth > however, because it is fixed at 64-bit. I don't understand and just wonder if your language supposed to be used for writing programs for PCs or only for micro-controllers? And if so, do I've got it properly that in this case one can do it with only HostForth without TargForth? (Or how to write programs for 64-bit platforms?) I ask you about this because, if my memory serves me well, somewhere earlier you wrote that HostForth is sort of low-lewel language intended to host languages for the target platforms.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-17 15:56 -0700 |
| Message-ID | <22c8fa6d-fe0a-4de2-bfe5-61390a28db91@googlegroups.com> |
| In reply to | #32438 |
On Wednesday, July 16, 2014 11:21:48 PM UTC-7, Alexander Skobelev wrote: > hughaguilar96@yahoo.com writes: > > With my language, I have abandoned the ANS-Forth idea of the language > > running on any size of processor. I require a 64-bit processor. > > > I actually have two languages. HostForth is 64-bit and runs on desktop > > computers. TargForth is a cross-compiler written in HostForth that > > targets micro-controllers. These may be 16-bit or 32-bit. HostForth > > and TargForth are not compatible --- it is unrealistic to expect the > > same language to run on a big desktop computer and a little > > micro-controller --- the environments are just too different. > I don't understand and just wonder if your language supposed to be used > for writing programs for PCs or only for micro-controllers? And if so, > do I've got it properly that in this case one can do it with only > HostForth without TargForth? (Or how to write programs for 64-bit > platforms?) I ask you about this because, if my memory serves me well, > somewhere earlier you wrote that HostForth is sort of low-lewel language > intended to host languages for the target platforms. My language is primarily for micro-controllers. The user writes his program in TargForth, which is a cross-compiler targeting whatever micro-controller he is using. TargForth is written in HostForth, and HostForth is a pretty-much-traditional stand-alone Forth system. Novice-level users don't have to learn HostForth at all; they can write applications in TargForth without knowing how TargForth is implemented (it is written in HostForth). Intermediate-level users (those who write meta-compiling code) will have to learn enough HostForth to write their compile-time code. Advanced-level users (those who want to upgrade TargForth to a new micro-controller) will have to learn HostForth thoroughly so they can upgrade TargForth for a new target (TargForth is a large program written in HostForth). For the most part, I'm not planning on supporting development of desktop-computer software. It is possible to write desktop-computer software in HostForth however. I myself will write a CAM program in HostForth (CAM means: Computer-Aided-Manufacture; this is generating gcode for CNC machines). I have no interest in internet server stuff, which is what most of the world uses desktop-computers for --- and there are already myriad dynamic-OOP languages available for this. I will most likely have a "sister language," which will be either Factor or one of the Scheme systems, and I will encourage people to write desktop-computer utility programs in it rather than HostForth, so I don't get bogged down writing wrappers for a lot of desktop-computer libraries that I don't understand very well and have little or no interest in. For my own part, I want to concentrate on writing TargForth versions in HostForth, and writing my own CAM software in HostForth --- the two subjects that I am reasonably knowledgeable in (unlike the typical Forth-200x committee member, I don't pretend to be an expert on everything).
[toc] | [prev] | [next] | [standalone]
| From | Alexander Skobelev <al.skobelev@gmail.com> |
|---|---|
| Date | 2014-07-18 09:35 +0400 |
| Message-ID | <m2silz1b6q.fsf@gmail.com> |
| In reply to | #32461 |
hughaguilar96@yahoo.com writes: > On Wednesday, July 16, 2014 11:21:48 PM UTC-7, Alexander Skobelev wrote: >> hughaguilar96@yahoo.com writes: >> > With my language, I have abandoned the ANS-Forth idea of the language >> > running on any size of processor. I require a 64-bit processor. >> >> > I actually have two languages. HostForth is 64-bit and runs on desktop >> > computers. TargForth is a cross-compiler written in HostForth that >> > targets micro-controllers. These may be 16-bit or 32-bit. HostForth >> > and TargForth are not compatible --- it is unrealistic to expect the >> > same language to run on a big desktop computer and a little >> > micro-controller --- the environments are just too different. > >> I don't understand and just wonder if your language supposed to be used >> for writing programs for PCs or only for micro-controllers? And if so, >> do I've got it properly that in this case one can do it with only >> HostForth without TargForth? (Or how to write programs for 64-bit >> platforms?) I ask you about this because, if my memory serves me well, >> somewhere earlier you wrote that HostForth is sort of low-lewel language >> intended to host languages for the target platforms. > > My language is primarily for micro-controllers. The user writes his > program in TargForth, which is a cross-compiler targeting whatever > micro-controller he is using. TargForth is written in HostForth, and > HostForth is a pretty-much-traditional stand-alone Forth system. > > Novice-level users don't have to learn HostForth at all; they can > write applications in TargForth without knowing how TargForth is > implemented (it is written in HostForth). Intermediate-level users > (those who write meta-compiling code) will have to learn enough > HostForth to write their compile-time code. Advanced-level users > (those who want to upgrade TargForth to a new micro-controller) will > have to learn HostForth thoroughly so they can upgrade TargForth for a > new target (TargForth is a large program written in HostForth). > > For the most part, I'm not planning on supporting development of > desktop-computer software. It is possible to write desktop-computer > software in HostForth however. I myself will write a CAM program in > HostForth (CAM means: Computer-Aided-Manufacture; this is generating > gcode for CNC machines). I have no interest in internet server stuff, > which is what most of the world uses desktop-computers for --- and > there are already myriad dynamic-OOP languages available for this. I > will most likely have a "sister language," which will be either Factor > or one of the Scheme systems, and I will encourage people to write > desktop-computer utility programs in it rather than HostForth, so I > don't get bogged down writing wrappers for a lot of desktop-computer > libraries that I don't understand very well and have little or no > interest in. For my own part, I want to concentrate on writing > TargForth versions in HostForth, and writing my own CAM software in > HostForth --- the two subjects that I am reasonably knowledgeable in > (unlike the typical Forth-200x committee member, I don't pretend to be > an expert on everything). OK, I see your point. Thank you for the detailed response.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-17 00:32 -0700 |
| Message-ID | <836283a2-64a1-4811-b653-13a099fbbb46@googlegroups.com> |
| In reply to | #32436 |
> I will give some thought to your suggestions in regard to TargForth so that programs can easily be ported between 16-bit and 32-bit micro-controllers. This discussion isn't relevant to HostForth however, because it is fixed at 64-bit. Maybe you would be dissapointed. I gave up the idea long time ago. That's why I have 32bit forth systems in place of otherwise normal 16bit systems. Forth cannot hide the size for operators, do you cannot have a "+" that work on single cells or double cells. But I thought that at least the data size in declarations to be "portable". Also, in my "32bit forths that should be 16bit forths" some kind of optimized 16bit operators may be an idea. For example, having a "H+" for 16bit add will save some cycles on the 8bit/16bit cpu, and on a 32bit cpu will be just aliased to "+". But I'm afraid is a step back, because my elegant 32bit forth will become a mess of half-cell and cell operators, likewise the 16bit forths are a mess of single and double-cell operators. 16bit forths and 32bit forths compatibility in forth is a dream. In a 16bit forth even if you have a "portable" 32bit data variable, fetching it will take two cells instead of one for 32bit forth, and it's all over. By the way, why do you say your host should be 64bit? Do you require intel host processors that supports 64bit? And you kinda do what I'm doing for my embedded 32bit systems ? :) Meaning you just double it from the start, and don't want to support mixed sizes 32bit/64bit ?
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-17 00:36 -0700 |
| Message-ID | <dae4d672-4f25-4f99-a436-8797a1551df3@googlegroups.com> |
| In reply to | #32439 |
> By the way, why do you say your host should be 64bit? Do you require intel host processors that supports 64bit? And you kinda do what I'm doing for my embedded 32bit systems ? :) Meaning you just double it from the start, and don't want to support mixed sizes 32bit/64bit ? Or you want to support 128 bit doubles ? :-O
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-17 16:52 -0700 |
| Message-ID | <96178e1a-c1a6-4795-bb94-5c164f6dc42b@googlegroups.com> |
| In reply to | #32440 |
On Thursday, July 17, 2014 12:36:02 AM UTC-7, Raimond Dragomir wrote: > > By the way, why do you say your host should be 64bit? Do you require intel host processors that supports 64bit? And you kinda do what I'm doing for my embedded 32bit systems ? :) Meaning you just double it from the start, and don't want to support mixed sizes 32bit/64bit ? > > Or you want to support 128 bit doubles ? :-O I will have 128-bit doubles in HostForth. I doubt that anybody other than myself will ever use them. The primary use for 128-bit doubles, is my continued-fraction program. It is necessary to do the calculation in twice the precision that the end result will be provided in. To get 64-bit rational approximations, I need the program to do 128-bit arithmetic. The user needs 64-bit ratios (because he is programming a 64-bit system), so I have to support 128-bit arithmetic. If the user only needs 32-bit ratios however, then the continued-fraction program can be 64-bit. All in all, I think that making HostForth 64-bit will simplify a lot of issues --- it could be done in 32-bit, but why hamstring myself? --- WalMart has 64-bit computers for $300, so why should I break my back for the poor devil who doesn't even have the $300 entry fee?
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-07-16 22:55 -1000 |
| Message-ID | <S_ydnYAIfaAbElrOnZ2dnUVZ_tadnZ2d@supernews.com> |
| In reply to | #32439 |
On 7/16/14 9:32 PM, Raimond Dragomir wrote: >> I will give some thought to your suggestions in regard to TargForth so that programs can easily be ported between 16-bit and 32-bit micro-controllers. This discussion isn't relevant to HostForth however, because it is fixed at 64-bit. > > Maybe you would be dissapointed. I gave up the idea long time ago. That's why I have 32bit forth systems in place of otherwise normal 16bit systems. > Forth cannot hide the size for operators, do you cannot have a "+" that work on single cells or double cells. There was a time when, on 32-bit Forths, we had operators like H@/H! to access half-cells (in addition, of course, to B@/B! for bytes). However, we never really saw a need for different arithmetic operators other that the single-cell, double-cell, and mixed operators in the standards. > But I thought that at least the data size in declarations to be "portable". Also, in my "32bit forths that should be 16bit forths" some kind of optimized 16bit operators may be an idea. For example, having a "H+" for 16bit add will save some cycles on the 8bit/16bit cpu, and on a 32bit cpu will be just aliased to "+". But I'm afraid is a step back, because my elegant 32bit forth will become a mess of half-cell and cell operators, likewise the 16bit forths are a mess of single and double-cell operators. > > 16bit forths and 32bit forths compatibility in forth is a dream. In a 16bit forth even if you have a "portable" 32bit data variable, fetching it will take two cells instead of one for 32bit forth, and it's all over. Really, it is not a dream! It is entirely practical. We have worked that way for almost 30 years, through may versions of systems and many complex applications. > By the way, why do you say your host should be 64bit? Do you require intel host processors that supports 64bit? And you kinda do what I'm doing for my embedded 32bit systems ? :) Meaning you just double it from the start, and don't want to support mixed sizes 32bit/64bit ? > Good question. I really see no need for a 64-bit host. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
Page 3 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