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 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-25 23:01 -0700 |
| Message-ID | <ff8e834d-e93b-4c78-a4d9-8ffa109702dd@googlegroups.com> |
| In reply to | #32649 |
I'm not British, so I have no personal experience with any of this. I just read about it years ago, and I can't find the book in storage --- so I'm not going to argue the point. I'm hardly an expert on British history, and I don't really care anyway --- the discussion of the Acorn is way off topic. On Friday, July 25, 2014 8:11:50 AM UTC-7, Mark Wills wrote: > (at that time they were making kit machines and possibly the Atom (or were working on it)) got wind of the BBC effort and managed to get an audience with the BBC. They put together a machine, from scratch, to meet the specification. They eventually won the contract and the rest is history. > ... > Acorn and BBC had no commercial connection with each other that I'm aware of. I don't think Acorn even paid a royalty to use the BBC name. It seems incredibly naive to believe that the brave little start-up Acorn just came out of nowhere and won the contract Horatio-Alger-style. They even used the BBC name! It seems abundantly obvious that the management of BBC were shadow owners of Acorn. If they were so strictly honest as to pass up such an obvious way to make heaps of cash, then they are candidates for sainthood. I don't know why being a "conspiracy theorist" is so derided --- people always conspire as described above --- I would be amazed to find any case in human history in which the people involved didn't conspire behind the scenes. > The machines were very well engineered and rather expensive. Out of the reach of the average family. They were around twice the price of the Sinclair Spectrum and Commodore 64. They were ubiquitous in UK shops from around 1983. There must have been a lot of average families buying the Acorn machines if they were ubiquitous in the shops. For the most part, people believe what their television tells them to believe --- that is true in America, and I suspect in Britain too. From what I've read, the Acorn had better software than the C64 (the C64 only came with a line-number BASIC, so it had pretty much nothing), but the C64 had better support for graphics and (especially) sound. They were both just educational though --- no business software either way. That was a long time ago --- hardly matters now.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-07-26 04:13 -0700 |
| Message-ID | <311aa2f7-13d9-4e69-b414-d17e845ec8f0@googlegroups.com> |
| In reply to | #32649 |
My bad. In my post above I said the BBC machines were ubiquitous in UK shops. That was a brain fart. I meant to say ubiquitous in UK *schools*. The reason? Schools got a grant from the UK government to buy BBC computers which meant they got a hefty discount on them. My school in 1983 probably had more than 10 of them all fitted out with disk drives and colour monitors. I know it sounds like a stretch to imagine that the BBC made nothing out of it, but as far as I know that really is the case. Acorn was wholly owned by Chris Curry and his Austrian partner (name escapes me at the moment). It wasn't until much later that they took the company public (which proved to be a disaster). The botched release of the Acorn Electron (which was a cut down "affordable" BBC B with fewer video modes and a slower overall performance) effectively finished the company off and they were bought for pennies on the pound by Olivetti. They were not alone. Just about every other British computer manufacturer went out of business during that time. The only survivor was Anstrad, who got their prices down and margins up by leveraging their far-east manufacturing expertise. The 8-bit era was a relatively short-lived era in the UK from around 1981 (when it started to really pick up steam) to approximately 1985/86 when the 16-bitters (Atari St and Amiga) began taking their lunch.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-07-26 08:02 -0400 |
| Message-ID | <op.xjls2y0w6zenlw@localhost> |
| In reply to | #32688 |
On Sat, 26 Jul 2014 07:13:57 -0400, Mark Wills <markwills1970@gmail.com> wrote: > My bad. In my post above I said the BBC machines were ubiquitous in UK > shops. That was a brain fart. I meant to say ubiquitous in UK *schools*. > [...] My school in 1983 probably had more than 10 of them all fitted > out with disk drives and colour monitors. Apple II's were the equivalent for many US schools in the 1980's. I'm not sure how widespread computers were in US schools in the 1980's. This might've been nationwide, or just certain states, or just some counties. Home users bought a variety of machines, with the Commodore C64 and Vic 20 being very popular. But, I recall friends families with everything from TRS-80's to IBM PC's to Timex Sinclair 1000's to Amiga 1000's to Atari ST's, everything, and anything, or nothing. I don't recall anyone owning a Apple Macintosh. Universities seemed to like them. The great thing about the Macintosh was the software look and feel, GUI based, user responsiveness. It was decades ahead in terms of software, but the hardware was so restricted. E.g., sometimes you needed two floppies ... The IBM PC with it's ability to change and adapt was the future. In hindsight, I'd say that if the look and feel of Macintosh software ran on a more powerful machine like the Amiga 1000, and had the flexibility of installing extra cards, devices, and hardware like the IBM PC, then that machine would likely have been a phenomenal success. Instead, it took over a decade for IBM PCs to catch up in terms of software and hardware. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-07-25 13:10 -0400 |
| Message-ID | <EPSdnTQ9QvsAEk_OnZ2dnUVZ_gOdnZ2d@supernews.com> |
| In reply to | #32638 |
On 7/25/14 4:51 AM, Andrew Haley wrote: > I am amazed that you persist with this nonsense, as the truth is a > matter of record which anyone can verify from a number of public > sources. For the same reason he doesn't benchmark his code or evaluate alternative algorithms. 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 | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-25 23:09 -0700 |
| Message-ID | <345f98cd-38d9-4d68-a635-bf3a8ef57cd6@googlegroups.com> |
| In reply to | #32652 |
On Friday, July 25, 2014 10:10:53 AM UTC-7, Elizabeth D. Rather wrote: > For the same reason he doesn't benchmark his code or evaluate > alternative algorithms. Are you a "leading expert" on algorithms too? Forth Inc. has never provided software for any data-structure --- and you don't know how to implement a general-purpose data-structure because you don't know what a quotation is. Provide a link to any thread in C.L.F. in which you described any algorithm whatsoever. There is none! You know exactly nothing about algorithms or data-structures. You're a fake --- you have never written a computer program in your life.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-07-22 03:45 -0400 |
| Message-ID | <op.xjd2iezk6zenlw@localhost> |
| In reply to | #32527 |
On Tue, 22 Jul 2014 00:35:58 -0400, <hughaguilar96@yahoo.com> wrote: > On Sunday, July 20, 2014 10:47:55 PM UTC-7, Raimond Dragomir wrote: >> > 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. > > I should clarify. I know C as well as anybody (it is a pretty simple > language), and I have worked as a C/C++ programmer. > > I'm not familiar with any C compiler, in the sense that I know how it > passes data into functions internally. I used to be familiar with Turbo > C, back in MS-DOS days. Turbo C just passed everything in a stack-frame > --- pretty simple. Bingo! Not much has changed. We discussed C calling conventions in 2011 in c.l.f. and 2012 c.l.a.x. and ... cdecl http://en.wikipedia.org/wiki/X86_calling_conventions#cdecl Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-07-21 01:59 -0400 |
| Message-ID | <op.xjb2xoo16zenlw@localhost> |
| In reply to | #32507 |
On Mon, 21 Jul 2014 01:11:39 -0400, <hughaguilar96@yahoo.com> wrote: > 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. Yeah, you probably shouldn't be implementing locals either without experience in how C does it. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-07-21 12:41 +0000 |
| Message-ID | <53cd0a97$0$15825$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #32507 |
In article <ae27569e-5998-431e-b60e-ebb5ed9ad254@googlegroups.com>, <hughaguilar96@yahoo.com> wrote: >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. Sounds interesting. Can you flesh that out by an (approximate) glossary? I've been thinking along those lines but I didn't get very far. 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-21 08:42 +0000 |
| Message-ID | <2014Jul21.104218@mips.complang.tuwien.ac.at> |
| In reply to | #32500 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>> > In my language, locals produce an address that can then be accessed wit=
>h =20
>>=20
>> > @ and ! like any variable (I don't support TO at all).
>>=20
>Hug's right. More often than not you need to pas a reference to a local var=
>iable to another regular function for processing.
Not in my experience. I expected significant need for references to
locals and implemented variable-flavoured locals in Gforth (along with
the regular value-flavoured locals), but found that I used them
extremely rarely, maybe 1-2 uses in 20 years.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2014-07-20 09:28 -0700 |
| Message-ID | <571d1c1c-d3a1-4721-a0d8-99339b300159@googlegroups.com> |
| In reply to | #32496 |
On Saturday, July 19, 2014 9:36:25 PM UTC-4, Rod Pemberton wrote: > On Sat, 19 Jul 2014 19:36:18 -0400, <hughaguilar96@yahoo.com> wrote: > > 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? The space is allocated on call and emptied on return. In common language, Hugh is saying that his language implements local variables rather than either local values or both. That's pretty much implied by "I don't support TO at all", since no TO, no values; no values, no local values.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-07-21 02:01 -0400 |
| Message-ID | <op.xjb20gs26zenlw@localhost> |
| In reply to | #32503 |
On Sun, 20 Jul 2014 12:28:32 -0400, BruceMcF <agila61@netscape.net> wrote: > On Saturday, July 19, 2014 9:36:25 PM UTC-4, Rod Pemberton wrote: >> On Sat, 19 Jul 2014 19:36:18 -0400, <hughaguilar96@yahoo.com> wrote: >> > 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? > > The space is allocated on call and emptied on return. In common > language, Hugh is saying that his language implements local variables > rather than either local values or both. That's pretty much implied by > "I don't support TO at all", since no TO, no values; no values, no > local values. So, he's reinventing C in Forth, which is something he hostilely decries when Anton does it ... or when others reject his non-C compatible memory allocator. Maybe, he should learn C first so he doesn't actually recreate C in Forth. At least Anton is aware of what he's doing. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> |
|---|---|
| Date | 2014-09-19 20:05 -0400 |
| Message-ID | <op.xmgk6sdcmk81un@localhost> |
| In reply to | #32510 |
On Mon, 21 Jul 2014 02:01:18 -0400, Rod Pemberton <dont_use_email@xnothavet.cqm> wrote: > On Sun, 20 Jul 2014 12:28:32 -0400, BruceMcF <agila61@netscape.net> > wrote: >> On Saturday, July 19, 2014 9:36:25 PM UTC-4, Rod Pemberton wrote: >>> On Sat, 19 Jul 2014 19:36:18 -0400, <hughaguilar96@yahoo.com> wrote: >>> > 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? >> >> The space is allocated on call and emptied on return. In common >> language, Hugh is saying that his language implements local variables >> rather than either local values or both. That's pretty much implied by >> "I don't support TO at all", since no TO, no values; no values, no >> local values. > > So, he's reinventing C in Forth, which is something he hostilely > decries when Anton does it ... or when others reject his non-C > compatible memory allocator. Maybe, he should learn C first so > he doesn't actually recreate C in Forth. At least Anton is aware > of what he's doing. I think this quote by Koopman is conclusive proof that Hugh is reinventing Forth in C: " For Forth users, the frame pointer can provide unexpected benefits. Many Forth programmers have advocated the use of local variables of some sort as a way of improving code organization and readability. A frame pointer mechanism makes an ideal implementation vehicle for a local variable stack, as well as providing a clean interface between C procedures and Forth subroutines." - Philipp Koopman The quote from "Design Tradeoffs in Stack Computers", Forth Dimensions, Volume 11 Number 6, March/April 1990. An article only pdf is available from Koopman: http://users.ece.cmu.edu/~koopman/forth/4thdim_11_6.pdf Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-20 04:30 -0400 |
| Message-ID | <lvje0b$k14$2@dont-email.me> |
| In reply to | #33449 |
On 9/19/2014 8:05 PM, Rod Pemberton wrote: > On Mon, 21 Jul 2014 02:01:18 -0400, Rod Pemberton > <dont_use_email@xnothavet.cqm> wrote: >> On Sun, 20 Jul 2014 12:28:32 -0400, BruceMcF <agila61@netscape.net> >> wrote: >>> On Saturday, July 19, 2014 9:36:25 PM UTC-4, Rod Pemberton wrote: >>>> On Sat, 19 Jul 2014 19:36:18 -0400, <hughaguilar96@yahoo.com> wrote: > >>>> > 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? >>> >>> The space is allocated on call and emptied on return. In common >>> language, Hugh is saying that his language implements local variables >>> rather than either local values or both. That's pretty much implied by >>> "I don't support TO at all", since no TO, no values; no values, no >>> local values. >> >> So, he's reinventing C in Forth, which is something he hostilely >> decries when Anton does it ... or when others reject his non-C >> compatible memory allocator. Maybe, he should learn C first so >> he doesn't actually recreate C in Forth. At least Anton is aware >> of what he's doing. > > I think this quote by Koopman is conclusive proof that Hugh is > reinventing Forth in C: > > " For Forth users, the frame pointer can provide unexpected > benefits. Many Forth programmers have advocated the use of > local variables of some sort as a way of improving code > organization and readability. A frame pointer mechanism > makes an ideal implementation vehicle for a local variable > stack, as well as providing a clean interface between C > procedures and Forth subroutines." > > - Philipp Koopman > > The quote from "Design Tradeoffs in Stack Computers", > Forth Dimensions, Volume 11 Number 6, March/April 1990. > > An article only pdf is available from Koopman: > http://users.ece.cmu.edu/~koopman/forth/4thdim_11_6.pdf > > > Rod Pemberton Did you say one of these backwards? "So, he's reinventing C in Forth" "Hugh is reinventing Forth in C" -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> |
|---|---|
| Date | 2014-09-20 18:15 -0400 |
| Message-ID | <op.xmiarzhrmk81un@localhost> |
| In reply to | #33454 |
On Sat, 20 Sep 2014 04:30:50 -0400, rickman <gnuarm@gmail.com> wrote: > On 9/19/2014 8:05 PM, Rod Pemberton wrote: >> On Mon, 21 Jul 2014 02:01:18 -0400, Rod Pemberton >> <dont_use_email@xnothavet.cqm> wrote: >>> On Sun, 20 Jul 2014 12:28:32 -0400, BruceMcF <agila61@netscape.net> >>> wrote: >>>> On Saturday, July 19, 2014 9:36:25 PM UTC-4, Rod Pemberton wrote: >>>>> On Sat, 19 Jul 2014 19:36:18 -0400, <hughaguilar96@yahoo.com> wrote: >>>>> > 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? >>>> >>>> The space is allocated on call and emptied on return. In common >>>> language, Hugh is saying that his language implements local variables >>>> rather than either local values or both. That's pretty much implied by >>>> "I don't support TO at all", since no TO, no values; no values, no >>>> local values. >>> >>> So, he's reinventing C in Forth, which is something he hostilely >>> decries when Anton does it ... or when others reject his non-C >>> compatible memory allocator. Maybe, he should learn C first so >>> he doesn't actually recreate C in Forth. At least Anton is aware >>> of what he's doing. >> >> I think this quote by Koopman is conclusive proof that Hugh is >> reinventing Forth in C: >> >> " For Forth users, the frame pointer can provide unexpected >> benefits. Many Forth programmers have advocated the use of >> local variables of some sort as a way of improving code >> organization and readability. A frame pointer mechanism >> makes an ideal implementation vehicle for a local variable >> stack, as well as providing a clean interface between C >> procedures and Forth subroutines." >> >> - Philipp Koopman >> >> The quote from "Design Tradeoffs in Stack Computers", >> Forth Dimensions, Volume 11 Number 6, March/April 1990. >> >> An article only pdf is available from Koopman: >> http://users.ece.cmu.edu/~koopman/forth/4thdim_11_6.pdf >> > Did you say one of these backwards? > > "So, he's reinventing C in Forth" > > "Hugh is reinventing Forth in C" > Lol. Yes, the latter, more recent reply. Sorry about that. RP
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-09-21 06:48 -0700 |
| Message-ID | <2a8aef7c-dea9-4f68-a76e-a330bd72c30e@googlegroups.com> |
| In reply to | #33449 |
So, if I want to implement local variables in my personal Forth system, and I want to use a frame pointer internal mechanism for that, it means that I'm reinventing C in Forth? What if I want to invent my own new language, let's name it Omega, and again, I want locals based on a frame pointer, it also means that I'm reinventing C in Omega? > > > >>> > 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? > > >> > > >> The space is allocated on call and emptied on return. In common > > >> language, Hugh is saying that his language implements local variables > > >> rather than either local values or both. That's pretty much implied by > > >> "I don't support TO at all", since no TO, no values; no values, no > > >> local values. > > > > > > So, he's reinventing C in Forth, which is something he hostilely > > > decries when Anton does it ... or when others reject his non-C > > > compatible memory allocator. Maybe, he should learn C first so > > > he doesn't actually recreate C in Forth. At least Anton is aware > > > of what he's doing. > > > > I think this quote by Koopman is conclusive proof that Hugh is > > reinventing Forth in C: > > > > " For Forth users, the frame pointer can provide unexpected > > benefits. Many Forth programmers have advocated the use of > > local variables of some sort as a way of improving code > > organization and readability. A frame pointer mechanism > > makes an ideal implementation vehicle for a local variable > > stack, as well as providing a clean interface between C > > procedures and Forth subroutines." > > > > - Philipp Koopman > > > > The quote from "Design Tradeoffs in Stack Computers", > > Forth Dimensions, Volume 11 Number 6, March/April 1990. > > > > An article only pdf is available from Koopman: > > http://users.ece.cmu.edu/~koopman/forth/4thdim_11_6.pdf > > > > > > Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> |
|---|---|
| Date | 2014-09-21 20:50 -0400 |
| Message-ID | <op.xmkcltq2mk81un@localhost> |
| In reply to | #33493 |
On Sun, 21 Sep 2014 09:48:06 -0400, Raimond Dragomir <raimond.dragomir@gmail.com> wrote: > So, if I want to implement local variables in my personal Forth system, > and I want to use a frame pointer internal mechanism for that, it means > that I'm reinventing C in Forth? > > What if I want to invent my own new language, let's name it Omega, and > again, I want locals based on a frame pointer, it also means that I'm > reinventing C in Omega? > The answer to your question is: "No.", at least, not literally. You missed the point, though. This was about Hugh's psychology. Everything Hugh keeps doing to "improve" his Forth just adds functionality that C already has. Usually, C has had that functionality for a long, long time. Not only that, but Hugh adds the functionality to his Forth using the exact same techniques that C does. Hugh doesn't seem to recognize the irony or contradiction in that. Hugh constantly complains about Anton Ertl when Anton extends GForth in ways which are compatible with C or use C techniques. So, why is Hugh even using Forth, if what Hugh really desires is C? ... Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-09-21 20:38 -0700 |
| Message-ID | <777be3c6-f75a-48af-8d10-0b388bb1fc83@googlegroups.com> |
| In reply to | #33493 |
On Sunday, September 21, 2014 6:48:07 AM UTC-7, Raimond Dragomir wrote: > So, if I want to implement local variables in my personal Forth system, and I want to use a frame pointer internal mechanism for that, it means that I'm reinventing C in Forth? > > What if I want to invent my own new language, let's name it Omega, and again, I want locals based on a frame pointer, it also means that I'm reinventing C in Omega? If your "Omega" has quotations, then it is neither Forth nor C --- it is something entirely new to the micro-controller world, so you might as well just call it Omega --- actually, Omega isn't a very good name, because it implies that it is the last-word on the subject, but the language would definitely be higher in the alphabet than C. At this time, there is no language available for micro-controllers that supports quotations --- and that includes Java. Factor has quotations, but Factor is also dynamic-OOP so it is too slow (and the GC causes too much variance in the speed) for it to be used in micro-controllers. It is possible to have quotations without dynamic-OOP, but I that is very rare (Go is the only example that I know of). Slava told me that he hopes to have Factor replace Java in smart-phones --- but smart-phones aren't micro-controllers because they don't control anything (they aren't real-time) --- they are really just desktop-computers that fit in your pocket and have a touch-screen rather than a mouse. AFAIK, Slava is not interested in micro-controllers (his background is Lisp). I have actually never met a C programmer who knew what quotations are. There are also very few Forth programmers who know what quotations are --- mostly these are the handful who learned Factor because they had heard that Factor is based on Forth, but then gave up on Factor because they discovered that Factor is very different from Forth in spirit --- I myself am in this category.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-21 08:37 +0000 |
| Message-ID | <2014Jul21.103747@mips.complang.tuwien.ac.at> |
| In reply to | #32503 |
BruceMcF <agila61@netscape.net> writes:
>In common language, H=
>ugh is saying that his language implements local variables rather than eith=
>er local values or both. That's pretty much implied by "I don't support TO =
>at all", since no TO, no values; no values, no local values.
I usually use locals without TO (static single-assignment style). You
might call them local constants, but the value may be different from
instance to instance (and a new instance is created every time the
locals definition is performed), and you may still use TO on them
(which you cannot do for constants), so I still call them
value-flavoured locals.
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-07-20 11:45 +0000 |
| Message-ID | <53cbab3f.984361722@news.demon.co.uk> |
| In reply to | #32494 |
On Sat, 19 Jul 2014 16:36:18 -0700 (PDT), hughaguilar96@yahoo.com wrote: >One of the more stupid design decisions in ANS-Forth, was to make locals wo= >rk with TO. In my language, locals produce an address that can then be acce= >ssed with @ and ! like any variable (I don't support TO at all). You clearly do not understand code generation and optimisation for locals. >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 s= >olution is a non-standard declaration at compile-time to declare the data n= >on-mutable. That was a proposal. I realise that American and English have diverged, but ... 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 | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-20 19:55 -0700 |
| Message-ID | <dc926c67-1439-4b54-9764-a5ed4cfba92d@googlegroups.com> |
| In reply to | #32499 |
On Sunday, July 20, 2014 4:45:05 AM UTC-7, Stephen Pelc wrote: > On Sat, 19 Jul 2014 16:36:18 -0700 (PDT), hughaguilar96@yahoo.com > wrote: > > >One of the more stupid design decisions in ANS-Forth, was to make locals wo= > >rk with TO. In my language, locals produce an address that can then be acce= > >ssed with @ and ! like any variable (I don't support TO at all). > You clearly do not understand code generation and optimisation for > locals. In my compiler, if I have a local (that produces an address), followed by a @ or a ! or some other word that uses an address, that all gets optimized together to hold the address in a register rather than on the stack. Most of my optimizations involve producer/consumer pairs. A producer is a word that puts data on the stack, and a consumer is a word that removes data from the stack. Optimizing typically involves having the producer put the data in a register(s) rather than on the stack, and the consumer using those registers. This is just peephole optimization, but it works pretty well. I learned this technique from ISYS Forth. Peephole optimization doesn't work when the producer puts data on the stack, and the data sits there for some time while other unrelated operations are being done, and then the consumer finally removes the data from the stack. An analytic optimizer should be able to handle this (assuming that there are enough registers available), but I'm not doing that at this time. For the most part, I just recommend that the programmer juxtapose his producer/consumer pairs --- this not only helps optimization, but it makes the source-code more readable too. Anyway, I don't think that variable-flavored locals are any more difficult to optimize than value-flavored locals. I don't have VALUE and TO at all --- it is redundant to have two ways to define variables (variables and values) --- my language is simple and easy to learn, and it doesn't have unnecessary redundancy. I have also gotten rid of DO loops, and quite a lot of cruft. ANS-Forth is way too big and complicated, and this makes it difficult to learn --- I'm really aiming for simplicity in my language --- but Forth-200x is getting bigger and more complicated than ANS-Forth, so you are going in the wrong direction. Your Forth-200x project is dragging on for years, so the language just gets more and more bloated as people add new incremental changes but never take anything away. If you can't figure out a language standard in one year, it is because you aren't smart enough --- dragging it out for decades isn't going to improve that situation. ANS-Forth was still-born in 1994, and it never really been used. But if you leave a corpse out in the sun it will bloat --- and that is how Forth-200x came to be. Do you really expect to reanimate this corpse decades later? Start over!!! Charles Moore commented that ANS-Forth was 100 times more complicated than necessary, and shortly afterward the Forth-200x project was launched --- so him and Jeff Fox assumed that the name "Forth-200x" was a snarky rejoinder to Moore's comment and implied that the new standard would be 200 times more complicated than necessary. Seriously! That is what they thought for quite some time, before somebody finally told them that the "200x" referred to the decade that the standard was planned to be released in (and, btw, how well did that plan work out?). I think that VALUE was originally introduced for the benefit of recalcitrant C programmers who thought that the @ and ! cluttered up the source-code --- but I say: "To hell with them!" > >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 s= > >olution is a non-standard declaration at compile-time to declare the data n= > >on-mutable. > That was a proposal. I learned about this in this thread: https://groups.google.com/forum/#!searchin/comp.lang.forth/compile$20time$20declaration%7Csort:date/comp.lang.forth/TTvONOrHvI4/S4Il4-uIKDUJ In here, you argued that CREATE DOES> is more efficient than my :NAME as a definer. You showed the generated assembly-language, but did not show the source-code until I finally pressured you into doing so --- and as I suspected, it wasn't ANS-Forth compliant! --- it used a non-standard compile-time declaration! By comparison, my :NAME (actually, everything in the novice package) is fully ANS-Forth compliant --- I had to work hard to make it ANS-Forth, but I succeeded. I think that you like the fact that ANS-Forth has problems, because you can tell your customers: "Here is the solution!" But then they suffer vendor-lock-in, because your solution is non-standard. > I realise that American and English have diverged, but ... OMG! It is "realize" not "realise" --- you did that on purpose, didn't you?
[toc] | [prev] | [next] | [standalone]
Page 6 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