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 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-17 16:34 -0700 |
| Message-ID | <0ade3c7c-d1c0-41f5-8f5e-055d66aaff6b@googlegroups.com> |
| In reply to | #32442 |
On Thursday, July 17, 2014 1:55:33 AM UTC-7, Elizabeth D. Rather wrote: > On 7/16/14 9:32 PM, 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 ? > > Good question. I really see no need for a 64-bit host. I considered making HostForth a 32-bit system. Over on CLAX said that my vision of the future was that 32-bit x86 (typically with multi-cores) would be standard, but that 64-bit x86 would always be an esoteric side-line. Everybody told me that I was wrong --- the future (actually, the present) involves 64-bit x86, and that the future mostly involves multi-core 64-bit systems --- 32-bit systems are largely obsolete. Everybody told me to focus on 64-bit x86 assembly-language and ignore 32-bit x86, even if my data is primarily 32-bit. So I decided, what the heck, I would just make HostForth a 64-bit system --- having 16 rather than 8 registers makes my life a lot easier --- why should I hamstring myself supporting 32-bit x86 when nobody in the real-world (or, at least nobody north of the Rio Grande) has a 32-bit x86 computer? Also, just by writing HostForth in 64-bit x86 assembly rather than 32-bit x86 assembly, I have taken a big step toward defeating Pelc who is mired in the obsolete 32-bit x86 world. Defeating Forth Inc. is too easy, as SwiftForth is slow as molasses --- defeating MPE is much more difficult --- but it should be possible, especially for programs that deal primarily in 64-bit data. How much fun would that be? A lot! ;-)
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-07-18 14:30 +0000 |
| Message-ID | <53c928c6.819888433@news.demon.co.uk> |
| In reply to | #32463 |
On Thu, 17 Jul 2014 16:34:46 -0700 (PDT), hughaguilar96@yahoo.com wrote: >Also, just by writing HostForth in 64-bit x86 assembly rather than 32-bit x= >86 assembly, I have taken a big step toward defeating Pelc who is mired in = >the obsolete 32-bit x86 world. Defeating Forth Inc. is too easy, as SwiftFo= >rth is slow as molasses --- defeating MPE is much more difficult --- but it= > should be possible, especially for programs that deal primarily in 64-bit = >data. How much fun would that be? A lot! ;-) It's difficult to argue against your vapourware. It's certainly true that 64 bit CPUs are good for applications that use a lot of 64 bit data. Outside the scientific domains there does not seem to be a great demand for 64 bit data. We only have one client who can show a need for much better processing of 64/128 bit data. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-18 14:40 +0000 |
| Message-ID | <2014Jul18.164010@mips.complang.tuwien.ac.at> |
| In reply to | #32468 |
stephenXXX@mpeforth.com (Stephen Pelc) writes:
>It's certainly true that 64 bit CPUs are good for applications
>that use a lot of 64 bit data. Outside the scientific domains
>there does not seem to be a great demand for 64 bit data.
64-bit CPUs and 64-bit Forth systems are good for applications that
use more data than can be addressed with 32 bits. On the usual OSs
the 32-bit limit is 2-3GB of data.
- 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 | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-07-18 17:05 +0200 |
| Message-ID | <lqbd3f$ssf$1@dont-email.me> |
| In reply to | #32469 |
on 18/07/2014 16:40:13, wrote: > stephenXXX@mpeforth.com (Stephen Pelc) writes: >>It's certainly true that 64 bit CPUs are good for applications >>that use a lot of 64 bit data. Outside the scientific domains >>there does not seem to be a great demand for 64 bit data. > > 64-bit CPUs and 64-bit Forth systems are good for applications that > use more data than can be addressed with 32 bits. On the usual OSs > the 32-bit limit is 2-3GB of data. > > - anton The default operand size on x64 in 64 bit mode is 32 bits. Your OS may use ths mode; Windows does. A long int is 32 bits. Linux and other Unices seem to be uniformly 64/64.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-18 17:26 +0000 |
| Message-ID | <2014Jul18.192602@mips.complang.tuwien.ac.at> |
| In reply to | #32470 |
"Alex McDonald" <blog@rivadpm.com> writes:
>on 18/07/2014 16:40:13, wrote:
>> stephenXXX@mpeforth.com (Stephen Pelc) writes:
>>>It's certainly true that 64 bit CPUs are good for applications
>>>that use a lot of 64 bit data. Outside the scientific domains
>>>there does not seem to be a great demand for 64 bit data.
>>
>> 64-bit CPUs and 64-bit Forth systems are good for applications that
>> use more data than can be addressed with 32 bits. On the usual OSs
>> the 32-bit limit is 2-3GB of data.
>>
>> - anton
>
>The default operand size on x64 in 64 bit mode is 32 bits. Your OS may
>use ths mode; Windows does. A long int is 32 bits. Linux and other Unices
>seem to be uniformly 64/64.
You seem to be conflating and confusing a number of things.
In the AMD64 architecture (called x64 in the Windows world) there are
8-bit, 16-bit, 32-bit, and 64-bit variants of many instructions (but
addresses are always 64-bit, so, e.g., LEA always produces 64-bit
results). The 16-bit and 64-bit variants of the instructions are
encoded by preprending a prefix to the 32-bit version of the
instruction (8-bit has a bit in the instruction). That is true
whichever OS you are using on AMD64. And while there are many modes
in AMD64, there is only one for 64-bit user-mode programs (the 64-bit
mode), and it has this property. 64-bit programs run in this mode on
any OS.
The other thing is that the C API/ABI for Win64 defines long int to be
32 bits. Apparently that allowed easier porting of Win32 programs to
Win64. That is independent of the architecture (e.g., it is also the
case on IA-64). In any case, this is C stuff and does not really
concern us in Forth (except when we interface to C).. In Forth cells
are as big as adresses, i.e., on Win64 you have 64-bit cells.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-07-19 22:31 +0200 |
| Message-ID | <lqekj5$ci$1@dont-email.me> |
| In reply to | #32474 |
on 18/07/2014 19:25:58, wrote: > "Alex McDonald" <blog@rivadpm.com> writes: >>on 18/07/2014 16:40:13, wrote: >>> stephenXXX@mpeforth.com (Stephen Pelc) writes: >>>>It's certainly true that 64 bit CPUs are good for applications >>>>that use a lot of 64 bit data. Outside the scientific domains >>>>there does not seem to be a great demand for 64 bit data. >>> >>> 64-bit CPUs and 64-bit Forth systems are good for applications that >>> use more data than can be addressed with 32 bits. On the usual OSs >>> the 32-bit limit is 2-3GB of data. >>> >>> - anton >> >>The default operand size on x64 in 64 bit mode is 32 bits. Your OS may >>use ths mode; Windows does. A long int is 32 bits. Linux and other Unices >>seem to be uniformly 64/64. > > You seem to be conflating and confusing a number of things. > > In the AMD64 architecture (called x64 in the Windows world) there are > 8-bit, 16-bit, 32-bit, and 64-bit variants of many instructions (but > addresses are always 64-bit, so, e.g., LEA always produces 64-bit > results). The 16-bit and 64-bit variants of the instructions are > encoded by preprending a prefix to the 32-bit version of the > instruction (8-bit has a bit in the instruction). That is true > whichever OS you are using on AMD64. And while there are many modes > in AMD64, there is only one for 64-bit user-mode programs (the 64-bit > mode), and it has this property. 64-bit programs run in this mode on > any OS. > > The other thing is that the C API/ABI for Win64 defines long int to be > 32 bits. Apparently that allowed easier porting of Win32 programs to > Win64. That is independent of the architecture (e.g., it is also the > case on IA-64). In any case, this is C stuff and does not really > concern us in Forth (except when we interface to C).. In Forth cells > are as big as adresses, i.e., on Win64 you have 64-bit cells. > > - anton I was quite clear that I was describing the default *operand* size, which is 32 bits. The default *address* size is 64 bits, but (at least in Windows) there's nothing stopping you from having a Win64 Forth that uses 32 bit addresses and hence 32 bit cells. The data address space is then 32 bit, RIP relative and is limited to 4GB; it's unlikely to be a limitation in all except a few cases. It's also possible in a 64 bit Windows (XP, 7 anf 8) to run a 32 bit executable that can execute code in 64 bit mode.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-21 15:14 +0000 |
| Message-ID | <2014Jul21.171454@mips.complang.tuwien.ac.at> |
| In reply to | #32492 |
"Alex McDonald" <blog@rivadpm.com> writes:
>The default *address* size is 64 bits, but (at least in Windows) there's
>nothing stopping you from having a Win64 Forth that uses 32 bit addresses
>and hence 32 bit cells.
Something like that was used for running 32-bit programs (that were
not ported to 64 bits, such as Netscape) on Digital Unix (on Alphas).
There is also the stillborn 32-bit ABI for 64-bit mode on Linux (x32).
These things typically need some OS support: The OS must not give
memory to the program outside the 4GB that the 32-bit addresses
address. nd all the system libraries you call have to be compatible
with this restriction.
>It's also possible in a 64 bit Windows (XP, 7 anf 8)
>to run a 32 bit executable that can execute code in 64 bit mode.
Right, and the same is true for Linux on AMD64, and that's why x32 is
stillborn.
Coming back to Forth, I have used more than 4GB of address space in
Forth programs. I see no point in doing x32-like stunts for Forth.
If you want to restrict yourself to 32 bits and 2-4GB, just use an
IA-32 implementation of Forth.
- 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-07-19 00:37 +0200 |
| Message-ID | <lqc7im$c5l$1@online.de> |
| In reply to | #32468 |
Stephen Pelc wrote: > It's certainly true that 64 bit CPUs are good for applications > that use a lot of 64 bit data. Outside the scientific domains > there does not seem to be a great demand for 64 bit data. > We only have one client who can show a need for much better > processing of 64/128 bit data. The most time consuming part in net2o is Keccak, which I use for symmetric encryption. It is designed so that it runs perfect on 64 bit CPUs, and still "good" in 32 bit mode. The speedup of Keccak in 64 bit is more than a factor 2. Partially, because there are more registers, partially because it simply can churn 2 times the data. The other critical operation is Ed25519, an elliptic curve, which is used for signing and diffie hellman key exchange. The speedup here is even bigger (would be a factor of more than 4, because Ed25519 is wide multiplication dominated, but thanks to SSE, it's less than that). This is all C code, which I access as library, so it's not related to Forth. This is by far the most time consuming part of net2o (the next biggest is the Linux kernel passing UDP packets around, which takes nearly as long as the entire encryption, and a lot longer than the net2o protocol overhead!). So apart from scientific domains, encryption wants 64 bits, too. So if I had to choose between Gforth and VFX from a performance point of view, VFX would accelerate the 20% that is actually spent in Forth code by a factor 2 or more. But of the rest, 50% would slow down by a factor >2, due to the 32 bit limitation. And we are already having smartphones with 64 bit CPUs out there: iPhone 5s. Android L supports 64 bits, too, so 64 bit Android phones will come, soon. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-07-18 16:30 -0700 |
| Message-ID | <7xmwc69rdv.fsf@ruckus.brouhaha.com> |
| In reply to | #32477 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > So apart from scientific domains, encryption wants 64 bits, too. Anything that shovels a lot of data around does better with 64 bits. I worked on a search engine for a while, and it was much faster on 64 bit machines than 32 bits. Also, most floating point computation (not just for scientific purposes) is probably best done with doubles unless there's reasonable justification that singles won't cause too much roundoff error etc. E.g. financial calculations generally use doubles if they use floating point. For many apps, 23 bits of single precision mantissa is too little resolution, so small errors can accumulate into noticable ones.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-07-19 01:40 +0200 |
| Message-ID | <lqcb9s$iou$1@online.de> |
| In reply to | #32479 |
Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> So apart from scientific domains, encryption wants 64 bits, too. > > Anything that shovels a lot of data around does better with 64 bits. I > worked on a search engine for a while, and it was much faster on 64 bit > machines than 32 bits. Also, most floating point computation (not just > for scientific purposes) is probably best done with doubles unless > there's reasonable justification that singles won't cause too much > roundoff error etc. E.g. financial calculations generally use doubles > if they use floating point. For many apps, 23 bits of single precision > mantissa is too little resolution, so small errors can accumulate into > noticable ones. The last is a non-issue here, floating points don't become bigger (or double calculations don't become faster) when you use the 64 bit mode of x86-64. You can argue that there is no SSE/AVX vectorizer in VFX, though. Programs with lots of pointers even become slower in 64 bit mode, because they need twice the memory. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-07-18 17:00 -0700 |
| Message-ID | <7xegxi9pzi.fsf@ruckus.brouhaha.com> |
| In reply to | #32480 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > The last is a non-issue here, floating points don't become bigger (or double > calculations don't become faster) when you use the 64 bit mode of x86-64. Well I thought this was also about the Forth cell size. It's nice if floats and ints fit in the same cells.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-19 16:36 -0700 |
| Message-ID | <7edd6024-75fc-4c09-a7a9-892cd8b2c176@googlegroups.com> |
| In reply to | #32484 |
On Friday, July 18, 2014 5:00:49 PM UTC-7, Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: > > The last is a non-issue here, floating points don't become bigger (or double > > calculations don't become faster) when you use the 64 bit mode of x86-64. > > Well I thought this was also about the Forth cell size. It's nice if > floats and ints fit in the same cells. One of the more stupid design decisions in ANS-Forth, was to make locals work with TO. In my language, locals produce an address that can then be accessed with @ and ! like any variable (I don't support TO at all). There are several advantages to this --- one of which is that floats can be stored in local variables so long as the local is at least 64-bits in size (which can be done on either a 32-bit or 64-bit Forth). In 1994 when ANS-Forth became the standard, Forth Inc. had not figured out how to implement local variables. When they came out with SwiftForth-v2 later on, (LOCAL) would crash the system, so they obviously never tested the use of locals even once before releasing it. At the time that ANS-Forth came out in 1994, nobody at Forth Inc. knew what locals were --- they wrote the ANS-Forth standard based on vague speculation and hearsay. I really believe that the only way for Forth to succeed, is to abandon ANS-Forth. I see no reason why there can't be two standards for a while --- ANS-Forth and my "Lambda Forth." Pelc could support both for a while. I predict that, after a while, Forth Inc. will be the only group supporting ANS-Forth and ANS-Forth will considered to be another name for SwiftForth (how I consider it now). If ANS-Forth has any value though, then other people will continue to use it, and they will ignore Lambda Forth --- may the best standard win! Pelc has already abandoned ANS-Forth compliance in many ways. For example, he understands the problem with CREATE code comma'ing non-mutable data but then the DOES> code at run-time having to treat it like mutable code. His solution is a non-standard declaration at compile-time to declare the data non-mutable. But if he is going to abandon ANS-Forth compliance, why not go all the way and abandon ANS-Forth totally? What is the point of a halfway abandonment?
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-07-19 21:36 -0400 |
| Message-ID | <op.xi9v2zi26zenlw@localhost> |
| In reply to | #32494 |
On Sat, 19 Jul 2014 19:36:18 -0400, <hughaguilar96@yahoo.com> wrote: > One of the more stupid design decisions in ANS-Forth, was to make locals > work with TO. This is another thread entirely: "Vote Hugh or vote NO on TO with locals" > In my language, locals produce an address that can then be accessed with > @ and ! like any variable (I don't support TO at all). Uh... How is that any different from just using a variable? > I really believe that the only way for Forth to succeed, is > to abandon ANS-Forth. Why? Please, back that up for once, like with a list. I didn't even attempt to do ANS, yet nearly everything I implemented passes (or did) Hayes ANS core tests. So, what is so terrible with ANS-Forth? It's clear to me that ANS is not all that different from pre-ANS Forth. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-19 21:05 -0700 |
| Message-ID | <29de697e-474a-4f99-95f8-23921c0eca28@googlegroups.com> |
| In reply to | #32496 |
On Saturday, July 19, 2014 6:36:25 PM UTC-7, Rod Pemberton wrote: > It's clear to me that ANS is not all that different from > pre-ANS Forth. Thank you very much, Captain Obvious!
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-07-21 02:01 -0400 |
| Message-ID | <op.xjb207yj6zenlw@localhost> |
| In reply to | #32498 |
On Sun, 20 Jul 2014 00:05:05 -0400, <hughaguilar96@yahoo.com> wrote: > On Saturday, July 19, 2014 6:36:25 PM UTC-7, Rod Pemberton wrote: >> It's clear to me that ANS is not all that different from >> pre-ANS Forth. > > Thank you very much, Captain Obvious! If that's the case, why did you just complain about ANS? ... HA> I really believe that the only way for Forth to succeed, HA> is to abandon ANS-Forth. How is anyone to believe anything you say when you contradict yourself in the next breath? How is anyone to believe what you say when you can't remember what you wrote and aren't willing to reread it to confirm? How is anyone to expect that you won't just recreate ANS-Forth with the supposed flaws you hate but somewhere else? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-20 06:09 -0700 |
| Message-ID | <0cedfdec-1922-4cc3-a339-2c5b292eb485@googlegroups.com> |
| In reply to | #32496 |
> > In my language, locals produce an address that can then be accessed with > > > @ and ! like any variable (I don't support TO at all). > Hug's right. More often than not you need to pas a reference to a local variable to another regular function for processing. You need the local's address. If the local is optimized in register, then, bad luck, you should de-optimized it back on stack, but that's life. I don't understand either why VALUEs exist in forth. @ and ! are the forth's way. VALUE system is the C way. Just different ways. Hugh, I like your healthy vision about the next era forth programming. I'm only an embedded engineer, and my interest is in the target only, but you seems to be also implicated in real life problems. Here are some things that I really like to see in the "lambda forth": - strong support for locals. I mean very strong. - strong support for structured data and arrays. At least comparable to C. - strong support for C (and ASM) interfacing. I have lately a special interest in C interfacing, because my newest applications for arm cortex-m boards include fatfs file systems on sd cards and uip/lwip protocols, which all are written in C. I already have all the infrastructure made in C, working very well, including a rtos of my own which is written in C but inspired from the forth philosophy. My solution for my newest cortex-m forth system is: - kernel written entirely in C (with very few asm, basically for accessing the return stack) - the kernel has the dictionary defined in C and burned in the kernel. - all C " library" functions (fatfs, uip, rtos, etc) have wrappers in C and they are presented as forth kernel words - the kernel has a full text interpreter (quite traditional) because it can do it because the dictionary headers are present. - the kernel doesn't have a compiler. - The compiler is a cross-compiler (written in C - working on windows host) - The host (cross)compiler has a very limited host forth dictionary for host interpreting. Basically for compile time calculations. - The host cross-compiler cannot compile code for itself. Only for target. - The application program for the target is not intended to do low level hardware drivers (it may be tokenized and slow) but it's nevertheless possible to do anything at the application level. At least with a native code compiler. I know that the limitation on the host compiling only for target will force me to do any host programming on the compiler in C. But that's it. On the other hand, the compiler is simpler, and on yet the other hand, when I'm programming an application for target, I want to program for the target, and not for the host.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-20 06:25 -0700 |
| Message-ID | <198d12af-a84c-4e51-bb6f-2517191ca48e@googlegroups.com> |
| In reply to | #32500 |
<continued>
- the forth kernel doesn't have a compiler and the final application doesn't have either. But the forth kernel is like a bootloader. It will act like a bootloader, being able to get the application binary compiled on the host on a serial protocol, and burn it in flash at a specified start address.
- the host compiler doesn't meed to access some map files or elf files or anything that is specific to some c compiler or assembler. The host compiler will be provided the forth kernel BINARY, and will retrieve all information that needs from the binary:
- the kernel dictionary headers - names, addresses, flags. It will be linked with the rest of the dictionary which will reside in the application binary of course.
- the application load start address
- the free ram address (this is just the C heap start)
- the application start address ("main")
All these are not vapourware, they are working right now. It's not finished yet because I'm in the middle of porting the crosscompiler from an avr one which is not the same thing. The compiler is able to generate new definitions and simple code.
Also, maybe a personal style: all variables, constants, strings are generated as inline literals. Not tightest, but fastest.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-20 22:11 -0700 |
| Message-ID | <ae27569e-5998-431e-b60e-ebb5ed9ad254@googlegroups.com> |
| In reply to | #32500 |
Thanks for your interest. :-) On Sunday, July 20, 2014 6:09:04 AM UTC-7, Raimond Dragomir wrote: > Here are some things that I really like to see in the "lambda forth": > > - strong support for locals. I mean very strong. I use locals for loops. I don't have DO loops (I and J were like locals, but now that we have actual locals none of this is needed anymore). I have words similar to WHILE that use locals as their index and limit. The user only has to learn BEGIN loops --- I think it is confusing in ANS-Forth to have iteration done by BEGIN loops and DO loops, that are totally different. Because I use locals, >R data can be used freely --- I think it is confusing in ANS-Forth for >R and DO to clash the way that they do. What did you have in mind regarding strong support for locals? > - strong support for structured data and arrays. At least comparable to C. I don't have any support for arrays built into the language --- I will just provide source-code for array definers, similar to what I have in the novice package. I do support lambda functions though. The idea is that the programmer writes a high-order word (similar to EACH in LIST.4TH in the novice package), and that word takes a quotation as a parameter. It traverses the data-structure and EXECUTEs the quotation for every node in the data-structure. This is how libraries of general-purpose data-structures are provided. C doesn't have lambda functions, so I was surprised that you said strong support for structured data should be comparable to C. What did you mean? > - strong support for C (and ASM) interfacing. I'm not familiar with any C compiler, so it is not clear to me how to write wrappers for C functions so they can be called from Forth. This is something that I will have to learn, and that I haven't given much thought to. Are you talking about TargForth on the micro-controller, or HostForth on the desktop computer? I wouldn't expect that there would be much C code that has to be interfaced to on a micro-controller --- I would have expected most micro-controller programs to be written from scratch and to not use any libraries of code. OTOH, using libraries of code is much more of an issue on desktop computers, for the GUI and so forth. > - the kernel has a full text interpreter (quite traditional) because it can do it because the dictionary headers are present. > > - the kernel doesn't have a compiler. Forth programming has to be interactive. You don't want to require the entire program to be cross-compiled and uploaded. You want to be able to compile single colon words and so forth at the REPL. MFX required the entire program to be cross-compiled and uploaded, like a traditional C cross-compiler. I think that interactive programming can be done however. I would have a stand-alone Forth system on the target that can compile, but it is getting help from the host computer, so it doesn't have to have a full compiler and dictionary on the target (there likely isn't enough memory on the target for that). > - The compiler is a cross-compiler (written in C - working on windows host) > > - The host (cross)compiler has a very limited host forth dictionary for host interpreting. Basically for compile time calculations. > > - The host cross-compiler cannot compile code for itself. Only for target. What you are doing, reminds me of STAAPL, except that you are using C and that guy was using Scheme. I have never written a Forth cross-compiler in any language other than Forth --- I'm not clear on why you would want to do this --- it seems like it would be much more difficult this way.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-20 22:47 -0700 |
| Message-ID | <26e2e926-3fd3-46a9-8876-42f1570795b6@googlegroups.com> |
| In reply to | #32507 |
> I use locals for loops. I don't have DO loops (I and J were like locals, but now that we have actual locals none of this is needed anymore). I have words similar to WHILE that use locals as their index and limit. The user only has to learn BEGIN loops --- I think it is confusing in ANS-Forth to have iteration done by BEGIN loops and DO loops, that are totally different. Because I use locals, >R data can be used freely --- I think it is confusing in ANS-Forth for >R and DO to clash the way that they do.
Something like that. Loops with local named indexes, no burned in stone I, J (I'm sure I have seen K too, but beyond that?), and at least another type along with the cell size locals: short strings, or character buffers on stack as locals.
>
>
>
> What did you have in mind regarding strong support for locals?
>
>
>
> > - strong support for structured data and arrays. At least comparable to C.
>
>
>
> I don't have any support for arrays built into the language --- I will just provide source-code for array definers, similar to what I have in the novice package.
>
>
>
> I do support lambda functions though. The idea is that the programmer writes a high-order word (similar to EACH in LIST.4TH in the novice package), and that word takes a quotation as a parameter. It traverses the data-structure and EXECUTEs the quotation for every node in the data-structure. This is how libraries of general-purpose data-structures are provided.
>
>
>
> C doesn't have lambda functions, so I was surprised that you said strong support for structured data should be comparable to C. What did you mean?
>
Just structs ad arrays (or vectors or any term you are using). Just simple things that makes your life easier in C, but in Forth it seems to be prohibited.
What's so hard about something like this:
typedef struct {
int x;
int y;
} PointT;
PointT p;
p.x p.y
This is C of course, and I don't want it to be exactly like that in a forth. But I think this is one of the most lacking feature in forth. If I have to invent a way of doing this, I'm almost sure it won't be compatible with other's people implementations. Also, if I have to port some other people code, I first have to figure it out the "syntax". This is just in the way of getting the job done.
I know forth gives you more freedom and lets you do whatever you like. But this is one thing. Being a "minimalist" system or language is another thing.
Personally I don't like programming the compiler. I like programming the application. I don't like programming the host when my job is to program the application for target.
This implies that the language is not that basic. It should provide some minimum of tols, but for me that includes basic structures like C.
>
>
> > - strong support for C (and ASM) interfacing.
>
>
>
> I'm not familiar with any C compiler, so it is not clear to me how to write wrappers for C functions so they can be called from Forth. This is something that I will have to learn, and that I haven't given much thought to.
>
>
>
> Are you talking about TargForth on the micro-controller, or HostForth on the desktop computer? I wouldn't expect that there would be much C code that has to be interfaced to on a micro-controller --- I would have expected most micro-controller programs to be written from scratch and to not use any libraries of code. OTOH, using libraries of code is much more of an issue on desktop computers, for the GUI and so forth.
>
You have some explanations later in the post. "Libraries" like ChaN's fatfs file system, TCP/IP stacks like uip or lwip...
I'm sure you don't want to write them in forth from scratch. I wouldn't write them from scratch in any language. I just use them, and they are quite good. Job done in a fraction of time.
C is almost like assembly these days, but much more portable. My forth kernel for a cortex-m0 is 7K though it has over 100 primitives and a full text interpreter along with dictionary headers. I have looked at the generated code all the time, and for the most code I really don't have anything to further optimize. All the short primitives like dup, drop, etc seems to be written by hand :)
And a cortex-m3 is more compact and faster.
Well, the idea is: embedded systems these days are hardly that simple that they used to be. There is more demand of higher level functionalities like communication stacks, GUI's etc.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-07-20 21:02 -1000 |
| Message-ID | <W5qdnTDWFe5kJ1HOnZ2dnUVZ_gednZ2d@supernews.com> |
| In reply to | #32508 |
On 7/20/14 7:47 PM, Raimond Dragomir wrote: >> I use locals for loops. I don't have DO loops (I and J were like locals, but now that we have actual locals none of this is needed anymore). I have words similar to WHILE that use locals as their index and limit. The user only has to learn BEGIN loops --- I think it is confusing in ANS-Forth to have iteration done by BEGIN loops and DO loops, that are totally different. Because I use locals, >R data can be used freely --- I think it is confusing in ANS-Forth for >R and DO to clash the way that they do. > > Something like that. Loops with local named indexes, no burned in stone I, J (I'm sure I have seen K too, but beyond that?), and at least another type along with the cell size locals: short strings, or character buffers on stack as locals. Yes, DO loops and BEGIN loops are designed for completely different situations. That's why there are two families of iteration structures, each adapted for the appropriate case: DO ... LOOP structures are for "finite" loops, where you know how many times (or the maximum number of times) you want to do stuff. BEGIN ... WHILE/UNTIL structures are for "indefinite" loops, when how long you want to do it depends on unpredictable circumstances. Two sets of structures, optimized for two different situations. If you use DO ... LOOP structures when appropriate, I (and, occasionally, J) are very useful. If you start synthesizing these with BEGIN, etc., and locals, you'll be far less efficient. 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 4 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