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 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-21 21:54 -0700 |
| Message-ID | <75a32142-6f65-4518-aa9d-3068bedd8899@googlegroups.com> |
| In reply to | #32512 |
On Monday, July 21, 2014 12:02:14 AM UTC-7, Elizabeth D. Rather wrote:
> 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.
This is baloney. DO loops can be used for situations in which you don't know how many times that you want to iterate. For example, in my novice package we have this for determining the length of a list:
: length ( head -- count )
0 0 do
dup 0= if I nip unloop exit then
.fore @ loop ;
If you do this with BEGIN, it will be less efficient because of the stack-juggling needed. This is true in SwiftForth where locals are grossly inefficient and the BEGIN version can't use locals for this reason. If locals are efficient however, then it is best to do all loops (both or your situations) with BEGIN loops.
DO loops really need to be trashed. They are a throw-back to the 1970s when Forth didn't have locals at all. Now that we have locals, there is no more need for DO loops at all --- BEGIN loops can be used for every situation. DO should have been discarded in ANS-Forth, because ANS-Forth had locals, and so there was no further need for DO.
I considered discarding >R etc., as they are also a throw-back to the 1970s when Forth didn't have locals. I'm keeping them to support situations in which there are a variable number of parameters on the stack (usually with a 0 sentinel underneath them) --- but I'm deprecating >R etc. for all other situations --- I encourage people to just use locals rather than >R.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-07-22 03:47 -0400 |
| Message-ID | <op.xjd2lh0n6zenlw@localhost> |
| In reply to | #32530 |
On Tue, 22 Jul 2014 00:54:53 -0400, <hughaguilar96@yahoo.com> wrote: > On Monday, July 21, 2014 12:02:14 AM UTC-7, Elizabeth D. Rather wrote: >> 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. > > This is baloney. DO loops can be used for situations in which you don't > know how many times that you want to iterate. Yes, you can use both as an infinite loop that is escaped. You've demonstrated this below for DO. But, why would you use DO for an infinite loop when BEGIN generally has far less overhead? > For example, in my novice > package we have this for determining the length of a list: > > : length ( head -- count ) > 0 0 do > dup 0= if I nip unloop exit then > .fore @ loop ; > > If you do this with BEGIN, it will be less efficient because > of the stack-juggling needed. From my experience, DO I and LOOP use a large amount of return stack juggling using two stacked values. Are you taking into account the stack operations performed by the loop constructs DO I LOOP BEGIN AGAIN UNTIL ? Could you post the equivalent code using BEGIN AGAIN, preferably, or perhaps BEGIN UNTIL ? I might be coding it wrongly or differently in my head ... > DO loops really need to be trashed. Most high-level languages have counter based loops. What do you suggest instead? I.e., it still needs a counter, and needs to work with ANS, Forth 83, fig-Forth, etc. > I considered discarding >R etc., as they are also a throw-back > to the 1970s when Forth didn't have locals. With a few temporaries, you shouldn't really need locals either ... Yet, you want to discard one and implement the other. Odd. I'm sure I've mentioned this once or twice before too. You seem to repeat conversations as much or more than J.P. did. I just hope you're aware of that ... Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-22 01:06 -0700 |
| Message-ID | <9f1f90ed-adf3-4fa8-8702-4f5984fc69b5@googlegroups.com> |
| In reply to | #32535 |
> Most high-level languages have counter based loops. > > What do you suggest instead? I.e., it still needs a > > counter, and needs to work with ANS, Forth 83, > > fig-Forth, etc. > C doen't have a real counting loop. FOR is just sintactic sugar for a while() loop. You can do almost whatever you like with FORs, for example doing for(;;) loops instead of while(1) loops, or using any kind of expression inside... Whatever Hugh is thinking, for me having named indexes (as locals) would be a step forward. > > > > I considered discarding >R etc., as they are also a throw-back > > > to the 1970s when Forth didn't have locals. > > > > With a few temporaries, you shouldn't really need locals either ... > > Yet, you want to discard one and implement the other. Odd. > >R and friends can work on top of a local stack. They won't disturb the real locals in this way. This can be just for cases when you just need a temporary and you don't want to declare a local only for that.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-22 01:12 -0700 |
| Message-ID | <4c2877b8-b16f-47d9-b81e-999e9ebb7306@googlegroups.com> |
| In reply to | #32537 |
> >R and friends can work on top of a local stack. They won't disturb the real locals in this way. This can be just for cases when you just need a temporary and you don't want to declare a local only for that. I wanted to say they can work on top of THE locals stack, if you have a distinct locals stack. This way they can be as any other locals, but created and destroyed by hand, at any place in the definition.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-07-22 04:25 -0400 |
| Message-ID | <op.xjd4crf16zenlw@localhost> |
| In reply to | #32537 |
On Tue, 22 Jul 2014 04:06:23 -0400, Raimond Dragomir <raimond.dragomir@gmail.com> wrote: > Rod Pemberton wrote >> Most high-level languages have counter based loops. >> >> What do you suggest instead? I.e., it still needs a >> counter, and needs to work with ANS, Forth 83, >> fig-Forth, etc. >> > C doen't have a real counting loop. FOR is just sintactic sugar for a > while() loop. You can do almost whatever you like with FORs, for example > doing for(;;) loops instead of while(1) loops, or using any kind of > expression inside... While true, that misses the point. By removing DO LOOP ?DO +LOOP , Hugh removes the syntactic "sugar" from Forth just like removing for() from C. You'd need to use BEGIN AGAIN UNTIL in Forth or while() or do-while() in C with counters. This can be done but it's more work. I'd expect that most coding in Forth would want looping words that work with counters. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-22 20:41 -0700 |
| Message-ID | <77c12571-1be2-43ea-a157-ece1c73df4cc@googlegroups.com> |
| In reply to | #32540 |
On Tuesday, July 22, 2014 4:25:29 AM UTC-4, Rod Pemberton wrote: > By removing DO LOOP ?DO +LOOP , Hugh removes the syntactic "sugar" > from Forth just like removing for() from C. But also removes the underlying looping primitives that are compiled by LOOP and +LOOP which, typically, increment the top of the return stack and exit the loop when it crosses the MAX-UNSIGNED / 0 boundary. It is that design of the typical do looping primitive that is responsible for the need for a distinct I and J to take the iterator and add back in the offset stored immediately above on the return stack to put it in terms of the original loop indices. When you assume you have cycles to burn, the underlying execution efficiency of the DO LOOP may not seem like much, but in situations where there are not a lot of cycles to spare, its got a substantial appeal.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-07-22 08:25 -1000 |
| Message-ID | <Bc-dne_9evgqMVPOnZ2dnUVZ_t-dnZ2d@supernews.com> |
| In reply to | #32535 |
On 7/21/14 9:47 PM, Rod Pemberton wrote: > On Tue, 22 Jul 2014 00:54:53 -0400, <hughaguilar96@yahoo.com> wrote: >> On Monday, July 21, 2014 12:02:14 AM UTC-7, Elizabeth D. Rather wrote: > >>> 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. >> >> This is baloney. DO loops can be used for situations in which you don't >> know how many times that you want to iterate. > > Yes, you can use both as an infinite loop that is escaped. > You've demonstrated this below for DO. But, why would you > use DO for an infinite loop when BEGIN generally has far > less overhead? Yes, when you have a structure optimized for a particular situation, it makes sense to use it and not try to cobble up something designed for a different purpose. ... > > From my experience, DO I and LOOP use a large amount of return > stack juggling using two stacked values. Are you taking into > account the stack operations performed by the loop constructs > DO I LOOP BEGIN AGAIN UNTIL ? Could you post the equivalent > code using BEGIN AGAIN, preferably, or perhaps BEGIN UNTIL ? > I might be coding it wrongly or differently in my head ... Maybe. In the versions I'm familiar with, there's no "return stack thrashing" at all, largely because we code primitives in (Forth) assembler. The runtime code for LOOP takes about 3 machine instructions, and +LOOP about 5. I can see that trying to do it in high level would be tortuous, but I can't imagine wanting to do that. 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-22 19:15 -0700 |
| Message-ID | <5c5d8042-d51c-4d6a-a830-a5538e7215fe@googlegroups.com> |
| In reply to | #32546 |
On Tuesday, July 22, 2014 11:25:58 AM UTC-7, Elizabeth D. Rather wrote: > On 7/21/14 9:47 PM, Rod Pemberton wrote: > > Yes, you can use both as an infinite loop that is escaped. > > You've demonstrated this below for DO. But, why would you > > use DO for an infinite loop when BEGIN generally has far > > less overhead? BEGIN loops have more overhead when locals aren't used. This is because the index and the loop are on the parameter stack, getting in the way of the other data on the parameter stack. This results in a lot of stack-juggling words, such as ROT or the dreaded ROLL. BEGIN loops only have less overhead when locals are used --- but this is what I'm arguing in favor of! > Yes, when you have a structure optimized for a particular situation, it > makes sense to use it and not try to cobble up something designed for a > different purpose. This is incredibly arrogant. My design, which you haven't seen, is "cobbled up," but ANS-Forth's DO loop is "designed for a purpose." The truth is that DO loops are a weird cobbled-up hack dating back to the 1970s when Forth didn't have local variables. Teaching novices how DO loops work is painful, because there is no good explanation for why DO and >R clash the way that they do --- explaining this involves explaining a lot of internal carnal stuff to a novice who isn't ready to learn it and has no reason to want to learn it. ANS-Forth is just full of bizarre restrictions that have no good explanation, but which have to be learned because they represent serious pitfalls that can result in really weird bugs (such as what happens when R@ is used in a DO loop by a programmer expecting to get data from a >R that was used prior to the DO loop). Another thing that is difficult for novices to learn, is why DO loops seem to behave differently going downwards as going upwards. I know what the rule is, but this is very counter-intuitive --- not something that anybody would expect --- I know that I really struggled with the concept when I was 18 and learning Forth. Also, implementing this requires that the processor has a overflow flag --- the MiniForth didn't --- implementing DO loops on a processor without an overflow flag is painful! Another thing that is difficult for novices to learn, is how nested DO loops work. Within the outer loop, the index is called I, but within the inner loop, that same index is called J and the inner loop index is now called I. That is incredibly confusing! With my system, using locals, each loop has an index with a name, and the name doesn't change. Another thing that is difficult for novices to learn, is that DO loops require an UNLOOP if they EXIT in middle, but BEGIN loops don't require anything. Also, I think that most novices are confused by the difference between UNLOOP and LEAVE --- and LEAVE works differently in ANS-Forth than it did in Forth-83, which is a source of yet more confusion (that tripped me up when I was learning ANS-Forth when I was writing the novice package). All in all, DO loops are just bizarre and very painful to explain --- this really looks like a 1970s-vintage hack, which is what it is --- DO loops should have been trashed in ANS-Forth after locals became available. But Elizabeth Rather had never seen locals work at the time that she wrote the ANS-Forth standard, which is why she didn't realize that locals obviated the need for DO loops. I know she had never seen locals work, because SwiftForth-v2 crashed whenever (LOCAL) was used --- implying that nobody at Forth Inc. had ever tested (LOCAL) even once before they began selling SwiftForth to foolish people like myself who were duped into throwing away $400 on that garbage. > > From my experience, DO I and LOOP use a large amount of return > > stack juggling using two stacked values. What the heck is "return stack juggling?" As usual, Rod is making no sense whatsoever. This kind of nonsense is not worth responding to at all. > Maybe. In the versions I'm familiar with, there's no "return stack > thrashing" at all, largely because we code primitives in (Forth) > assembler. The runtime code for LOOP takes about 3 machine instructions, > and +LOOP about 5. I can see that trying to do it in high level would be > tortuous, but I can't imagine wanting to do that. This is a straw-man argument --- I'm not advocating doing this. I clearly stated that I have special forms of WHILE that provide the ability to step through a loop using locals as the index and limit --- these are primitives coded in assembly-language --- the whole point of making this stuff part of the language definition, is to dump the work of implementing it on the compiler-writer.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-07-23 04:23 -0400 |
| Message-ID | <op.xjfyxlv36zenlw@localhost> |
| In reply to | #32557 |
On Tue, 22 Jul 2014 22:15:28 -0400, <hughaguilar96@yahoo.com> wrote: > On Tuesday, July 22, 2014 11:25:58 AM UTC-7, Elizabeth D. Rather wrote: >> On 7/21/14 9:47 PM, Rod Pemberton wrote: >> > Yes, you can use both as an infinite loop that is escaped. >> > You've demonstrated this below for DO. But, why would you >> > use DO for an infinite loop when BEGIN generally has far >> > less overhead? > > BEGIN loops have more overhead when locals aren't used. This is because > the index and the loop are on the parameter stack, getting in the way of > the other data on the parameter stack. This results in a lot of > stack-juggling words, such as ROT or the dreaded ROLL. > > BEGIN loops only have less overhead when locals are used --- but this is > what I'm arguing in favor of! > Is there a reason you replied to Ms. Rather, but responded to both mine and her comments in her post? That's not polite, and confusing. >> > From my experience, DO I and LOOP use a large amount of return >> > stack juggling using two stacked values. > > What the heck is "return stack juggling?" I'm sure you fully understand that interpreted Forths have two stacks. a) the data or parameter stack b) the return or control-flow stack. If you understand "data stack-juggling," why not the other? What's the hang-up on your end this time Hugh? > As usual, Rod is making no sense whatsoever. No, it seems you're just being an ass, like normal. E.g., replying to me within the reply to someone else so I won't see it, terminating with an insult, failing to reply to comments on your comments in other posts, replying to other things unrelated to what you posting, not listening to reason, not making sense, arguing to argue, repeating unfounded claims, not backing up claims, failing to remember you've discussed things three, four or more times, etc. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2014-07-23 12:48 +0200 |
| Message-ID | <85bnsgtkpr.fsf@junk.nocrew.org> |
| In reply to | #32566 |
Rod Pemberton writes: > I'm sure you fully understand that interpreted Forths have two stacks. > a) the data or parameter stack > b) the return or control-flow stack. The return stack is not (necessarily) the same as the control-flow stack. (The control-flow stack is more likely to be the same as the data stack.) See http://forth.sourceforge.net/std/dpans/dpans3.htm#3.2.3
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-21 21:35 -0700 |
| Message-ID | <7f8cc421-cfa5-4ff5-8c17-8cc3299101ad@googlegroups.com> |
| In reply to | #32508 |
On Sunday, July 20, 2014 10:47:55 PM UTC-7, Raimond Dragomir wrote:
> 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.
Locals are big enough to hold a double. Therefore, the following can be stored in a local:
1.) a single-precision number
2.) a double-precision number
3.) a ratio (single-precision numerator and denominator)
4.) a string (pointer and count)
5.) a 64-bit float
6.) an x86-style 80-bit float
7.) a 128-bit float (I never heard of this before Pelc mentioned it)
I plan on supporting #1, #2, #3 and #4 --- I'm undecided on #5.
> 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.
This is available in my novice package. See FIELD. What you are describing is pretty simple, as you didn't mention inheritance --- the novice package supports inheritance (but not polymorphism).
Several example programs use structs (especially the slide-rule program), so you can see how it is done in practice.
See ARY for arrays. Also, there is 1ARRAY, 2ARRAY, etc. (although I think ARY will be more to your liking).
> > 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.
Now parameters are passed in registers. Maybe this can be turned off and the compiler forced to use an old-fashioned stack-frame, which would make interfacing easy. Or, maybe I have to learn some complicated rule for how the parameters are passed. I'm not familiar with any of this, as I have never used C on a modern 32-bit or 64-bit processor --- I haven't used C or C++ outside of MS-DOS, and that was 20 years ago.
> > 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.
Okay, you are talking about TargForth. You have a good point in that nobody is going to write a TCP/IP stack from scratch, or a file-system for a mass-storage device.
My experience at Testra was with the MiniForth. It was used in the motion-control board for a laser etcher (and a CNC milling machine too). It did not have internet access, or a mass-storage device, or an OS --- the program ran on the "bare metal."
The MiniForth wasn't able to start itself up. It needed a "pony processor" to get it going. This was an 8032. The MiniForth didn't have a serial port. It communicated with the 8032 over a parallel port, and the 8032 communicated with the desktop computer over a UART. The 8032 would buffer data files that were uploaded into it from the desktop-computer (the 8032 had 64MB of RAM), and it would feed the data to the MiniForth as necessary --- the MiniForth had only 64KW of RAM (later upgraded to 128KW, I heard, although this was not used in the laser-etcher board). Because the MiniForth had only a little bit of RAM, it couldn't hold an entire data file in memory --- this is why it had to be fed the data by the 8032 as it did the etching.
Anyway, this is a completely different world from what you are describing. This is very low-level bare-metal programming. Your "micro-controller" is 32-bit and has desktop-computer-like I/O, such as internet and hard-disk. What you are describing is likely quite common these days --- I've never used anything like that --- but I would be interested in learning.
BTW: I never actually saw the motion-control program when I was at Testra. I just wrote MFX the development system, and the other programmer wrote the motion-control program in MFX.
> 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 :)
I very much doubt that your system would be fast enough to compete with the MiniForth, even though the MiniForth is 20 years old.
For good speed, you really need a processor that is customized for your application. Having NEXT in hardware rather than software makes Forth go fast. Your Forth written in C is really not in the same league, speed-wise.
BTW: Is it possible to write ISRs in C? In the kind of programs that I'm familiar with, ISRs make up a significant portion of the code, and they typically take up more than 50% of the time.
> And a cortex-m3 is more compact and faster.
What is more "compact?" I don't know what you are talking about here.
> 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.
As I said, this is the modern world --- something that I really should investigate. ;-)
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-21 23:53 -0700 |
| Message-ID | <f86e4c90-6096-4a08-bfd2-da0749f6384a@googlegroups.com> |
| In reply to | #32527 |
> Locals are big enough to hold a double. Therefore, the following can be stored in a local: > > 1.) a single-precision number > > 2.) a double-precision number > > 3.) a ratio (single-precision numerator and denominator) > > 4.) a string (pointer and count) > > 5.) a 64-bit float > > 6.) an x86-style 80-bit float > > 7.) a 128-bit float (I never heard of this before Pelc mentioned it) > > > > I plan on supporting #1, #2, #3 and #4 --- I'm undecided on #5. 8.) real local string, byte buffer, character array. For example, for a 32 byte local buffer allocate 4 64bit words, and make it work like any other global string, providing the address and count when used. Maybe this is not that common, but I'm using this very much lately, because I have to process short strings (containing names of users, files, etc) and I want to have local strings for intermediate processing. This comes also from the fact that I use a multitasking system. > This is available in my novice package. See FIELD. What you are describing is pretty simple, as you didn't mention inheritance --- the novice package supports inheritance (but not polymorphism). > > > > Several example programs use structs (especially the slide-rule program), so you can see how it is done in practice. > > > > See ARY for arrays. Also, there is 1ARRAY, 2ARRAY, etc. (although I think ARY will be more to your liking). > Your novice package is just great. I suppose you are making your life easier in getting a good novice package with your own compiler. > 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. > > > > Now parameters are passed in registers. Maybe this can be turned off and the compiler forced to use an old-fashioned stack-frame, which would make interfacing easy. Or, maybe I have to learn some complicated rule for how the parameters are passed. I'm not familiar with any of this, as I have never used C on a modern 32-bit or 64-bit processor --- I haven't used C or C++ outside of MS-DOS, and that was 20 years ago. For the target part, it depends on how nice the microcontroller/compiler is. For Cortex-M family it's realy simple. > Okay, you are talking about TargForth. You have a good point in that nobody is going to write a TCP/IP stack from scratch, or a file-system for a mass-storage device. > > > > My experience at Testra was with the MiniForth. It was used in the motion-control board for a laser etcher (and a CNC milling machine too). It did not have internet access, or a mass-storage device, or an OS --- the program ran on the "bare metal." > > > > The MiniForth wasn't able to start itself up. It needed a "pony processor" to get it going. This was an 8032. The MiniForth didn't have a serial port. It communicated with the 8032 over a parallel port, and the 8032 communicated with the desktop computer over a UART. The 8032 would buffer data files that were uploaded into it from the desktop-computer (the 8032 had 64MB of RAM), and it would feed the data to the MiniForth as necessary --- the MiniForth had only 64KW of RAM (later upgraded to 128KW, I heard, although this was not used in the laser-etcher board). Because the MiniForth had only a little bit of RAM, it couldn't hold an entire data file in memory --- this is why it had to be fed the data by the 8032 as it did the etching. > > > > Anyway, this is a completely different world from what you are describing. This is very low-level bare-metal programming. Your "micro-controller" is 32-bit and has desktop-computer-like I/O, such as internet and hard-disk. What you are describing is likely quite common these days --- I've never used anything like that --- but I would be interested in learning. I don't want to compete with custom hardware cpu, design for forth execution. But today you can use Cortex-M3/M4 at 100MHz+ (even 200MHz) and I'm sure that if they work with no wait states in internal RAm, they may keep the pace. My fastest system is an LPC4088 cortex-m4 at 120MHz. > > > > BTW: I never actually saw the motion-control program when I was at Testra. I just wrote MFX the development system, and the other programmer wrote the motion-control program in MFX. > > > > > 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 :) > > > > I very much doubt that your system would be fast enough to compete with the MiniForth, even though the MiniForth is 20 years old. > > > > For good speed, you really need a processor that is customized for your application. Having NEXT in hardware rather than software makes Forth go fast. Your Forth written in C is really not in the same league, speed-wise. > > > > BTW: Is it possible to write ISRs in C? In the kind of programs that I'm familiar with, ISRs make up a significant portion of the code, and they typically take up more than 50% of the time. > > > > > And a cortex-m3 is more compact and faster. > > > > What is more "compact?" I don't know what you are talking about here. Cortex-M3/M4 have more powerfull instruction set, able to do more work in less time, less code. That's why cortex-m3 is faster than cortex-m0 and compiles in less code. I have done speed tests in my newest tokenized system for both cortex-m0 and m3 (I have boards with both micros and I was curious). M3 ran about 25% faster. I don't know the code size ratio because I was adding the forth kernel on very different boards, with very different drivers and libraries loaded. For the moment though I let the tokenized system alone, and concentrate on native code generation. Native code on ARM is particularly nice because the top of return stack is cached on a register (LR) and if you have functions that do not call other functions (which most primitives do) there is no return stack involved, just the registers. This is faster than the traditional CALL/RET with the real pushing poping. C ISRs on cortex-m are a norm. Personally, for cortex, I haven't written any ISR in assembler, and I have big applications with tens of ISRs on many levels (4 levels). I even managed to design a fifo library completely in C, which works on ISRs and tasks whithout any interrupt disabling/disabling. I have looked in the generated asm for this fifo and decided that I have nothing to improve. Cortex-M architecture is particularly nice regarding interrupt processing. The hardware is really designed with this in mind. For example, in 12 cycles you have everything set up on stack, and your ISR code gets executing. This is really the application isr code not some other register pushing or anything else. In 12 cycles the cpu saves eight registers on stack (taking 32 stack bytes) and after that your code can execute like if it is any regular C function. That's why the cortex-m systems don't have special isr directives. Any C function can be an ISR just as is. Hugh, if you want me to help you with the target part, please let me know. My personal interest these days are Cortex-M systems. If you want to work on a TargForth for Cortex (for a start) I can help you with everything. I even have some experience in cross-compiling for it :)
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-22 18:11 -0700 |
| Message-ID | <69f20302-5bf7-443d-9f8b-c4ab078f6542@googlegroups.com> |
| In reply to | #32532 |
On Monday, July 21, 2014 11:53:55 PM UTC-7, Raimond Dragomir wrote: > > Locals are big enough to hold a double. Therefore, the following can be stored in a local: > > > 1.) a single-precision number > > > 2.) a double-precision number > > > 3.) a ratio (single-precision numerator and denominator) > > > 4.) a string (pointer and count) > > > 5.) a 64-bit float > > > 6.) an x86-style 80-bit float > > > 7.) a 128-bit float (I never heard of this before Pelc mentioned it) > > > I plan on supporting #1, #2, #3 and #4 --- I'm undecided on #5. > 8.) real local string, byte buffer, character array. For example, for a 32 byte local buffer allocate 4 64bit words, and make it work like any other global string, providing the address and count when used. I had been planning on having the user ALLOCATE memory on the heap and store the pointer in the local (or just hold the pointer on the parameter stack), and then FREE the memory at the end of the colon word just prior to the semicolon. This requires some manual work on the part of the programmer (and also leaves open the possibility that he will forget to FREE his buffers, resulting in a memory leak) --- but I think this is really the Forth-way. What you are describing would involve locals being different sizes, which means that any local couldn't hold any allowed data-type. This implies that each local has a data-type associated to it. This is totally against the Forth-way, as Forth has always been an untyped language --- having typed variables really opens up a can of worms! > Maybe this is not that common, but I'm using this very much lately, because I have to process short strings (containing names of users, files, etc) and I want to have local strings for intermediate processing. This comes also from the fact that I use a multitasking system. I have no idea why using a multitasking system implies that it is a good idea to have variable-sized typed locals. You mention "short strings" --- I also have no idea why the length of the string makes a difference in regard to whether it is stored in the heap or on the locals stack --- memory is memory. All in all, I think that you have a mild case of "Citis" (the desire to turn every programming language into C) --- Rod has a terminal case of Citis, and it has resulted in permanent brain damage --- don't let this happen to you! ;-) > Your novice package is just great. I suppose you are making your life easier in getting a good novice package with your own compiler. Thanks for the compliment! :-) Yes, with my language I will have a library of code that is not officially part of the language, but which everybody is encouraged to use. All languages except ANS-Forth have something like this. > > Anyway, this is a completely different world from what you are describing. This is very low-level bare-metal programming. Your "micro-controller" is 32-bit and has desktop-computer-like I/O, such as internet and hard-disk. What you are describing is likely quite common these days --- I've never used anything like that --- but I would be interested in learning. > > I don't want to compete with custom hardware cpu, design for forth execution. But today you can use Cortex-M3/M4 at 100MHz+ (even 200MHz) and I'm sure that if they work with no wait states in internal RAm, they may keep the pace. My fastest system is an LPC4088 cortex-m4 at 120MHz. I am still doubtful that your Cortex-m3/m4 can compete with the MiniForth in speed. Two decades ago, there was a 50Mhz version (used in the laser etcher) and an 80Mhz version (an overkill for most everybody) available. It is likely faster by now (also, they changed the name to RACE for reasons obscure). The MiniForth is Harvard Architecture --- it was accessing code memory and data memory simultaneously. Also, it could execute up to 5 instructions in a single clock cycle (only one could access data memory). My assembler would rearrange the instructions to minimize the number of NOP instructions that had to be inserted, while guaranteeing that the program would do the same thing with a lot of instructions executing in parallel as it would if the instructions were executed serially as the programmer wrote them (this was really the clever part of the whole development system). I don't think your Cortex is in the same league at all. But it is not my business to start a "my processor can beat up your processor argument." If your Cortex is fast enough for the applications that you are using it for, then you are good to go. Also, the Cortex is a 32-bit system (the MiniForth is 16-bit), so the Cortex has maybe two orders of magnitude more memory --- it can do things like have a TCP/IP stack and a hard-disk, that the MiniForth can't. These are completely different worlds, with different applications --- so just follow the money! --- if there is money to be made with big Cortex systems involving internet and hard-disk etc., then focus on that. Anyway, the argument of which processor is "better" is pointless, because the MiniForth is proprietary to Testra (it is single-source) and I don't own the thing --- so why should I be a salesman for it? > For the moment though I let the tokenized system alone, and concentrate on native code generation. Native code on ARM is particularly nice because the top of return stack is cached on a register (LR) and if you have functions that do not call other functions (which most primitives do) there is no return stack involved, just the registers. This is faster than the traditional CALL/RET with the real pushing poping. The PDP-11 did the same thing --- held the top return-value in a register. That was one of the coolest features of the PDP-11 --- I'm glad to see that this idea has finally been reintroduced. > > BTW: Is it possible to write ISRs in C? In the kind of programs that I'm familiar with, ISRs make up a significant portion of the code, and they typically take up more than 50% of the time. > C ISRs on cortex-m are a norm. Personally, for cortex, I haven't written any ISR in assembler, and I have big applications with tens of ISRs on many levels (4 levels). I even managed to design a fifo library completely in C, which works on ISRs and tasks whithout any interrupt disabling/disabling. I have looked in the generated asm for this fifo and decided that I have nothing to improve. > > Cortex-M architecture is particularly nice regarding interrupt processing. The hardware is really designed with this in mind. For example, in 12 cycles you have everything set up on stack, and your ISR code gets executing. This is really the application isr code not some other register pushing or anything else. In 12 cycles the cpu saves eight registers on stack (taking 32 stack bytes) and after that your code can execute like if it is any regular C function. That's why the cortex-m systems don't have special isr directives. Any C function can be an ISR just as is. Do you know the history of the ARM processor? Originally, there was an Acorn computer used for education in England. It was owned by the BBC (British Broadcasting Corporation) and was the basis for their educational shows involving computers. It used the 6502. The BBC wanted to upgrade to a more powerful processor. They experimented with the MC68000, but they decided that it had too much interrupt latency (the 6502 had extremely fast interrupts, mostly because it had only four 8-bit hardware registers to save and restore). The BBC considered using the W65816, but decided against it because it had an 8-bit data-bus, and they really wanted a 32-bit data-bus. So they decided to build their own micro-processor. The result was the ARM (Acorn Risc Machine) --- its primary feature was fast interrupt response --- the ARM had a bank of registers that could be swapped in for ISRs, rather than have to save and restore registers to memory. Later on, an American company bought the design, and they renamed it "Advanced Risc Machine" because it no longer was associated with the Acorn computer that no longer existed.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-22 22:08 -0700 |
| Message-ID | <5c200e23-2804-498d-bf47-5360b571f66e@googlegroups.com> |
| In reply to | #32555 |
> I have no idea why using a multitasking system implies that it is a good idea to have variable-sized typed locals. You mention "short strings" --- I also have no idea why the length of the string makes a difference in regard to whether it is stored in the heap or on the locals stack --- memory is memory. All in all, I think that you have a mild case of "Citis" (the desire to turn every programming language into C) --- Rod has a terminal case of Citis, and it has resulted in permanent brain damage --- don't let this happen to you! ;-) Multitasking may lead having multiple tasks using the same function on different data copies. The obvious way is having data on (task's) stack. Heap may work too however. I'm not advocating local typing system. It was just an idea. While I'm good at C, I don't want to have a "C like" forth. It's redundant :) > But it is not my business to start a "my processor can beat up your processor argument." If your Cortex is fast enough for the applications that you are using it for, then you are good to go. Also, the Cortex is a 32-bit system (the MiniForth is 16-bit), so the Cortex has maybe two orders of magnitude more memory --- it can do things like have a TCP/IP stack and a hard-disk, that the MiniForth can't. These are completely different worlds, with different applications --- so just follow the money! --- if there is money to be made with big Cortex systems involving internet and hard-disk etc., then focus on that. > Exactly. I have for example a communication gateway, between ethernet tcp/ip regular network and some 232 and 485 industrial networks. The cpu runs at 6%, at "only" 24MHz (can go up to 100). So I'm very happy. But these days there is another reason to use cortex chips: the price. I have done a new board with the lowest cost STM32 device (an M0) because was cheaper than anything I know. It may run at 0.5% in that application, but who cares? > Do you know the history of the ARM processor? Originally, there was an Acorn computer used for education in England. It was owned by the BBC (British Broadcasting Corporation) and was the basis for their educational shows involving computers. It used the 6502. The BBC wanted to upgrade to a more powerful processor. They experimented with the MC68000, but they decided that it had too much interrupt latency (the 6502 had extremely fast interrupts, mostly because it had only four 8-bit hardware registers to save and restore). The BBC considered using the W65816, but decided against it because it had an 8-bit data-bus, and they really wanted a 32-bit data-bus. So they decided to build their own micro-processor. The result was the ARM (Acorn Risc Machine) --- its primary feature was fast interrupt response --- the ARM had a bank of registers that could be swapped in for ISRs, rather than have to save and restore registers to memory. Later on, an American company bought the design, and they renamed it "Advanced Risc Machine" because it no longer was associated with the Acorn computer that no longer existed. Yup, I know. And the Cortex interrupt system is better than the first arm architectures.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-22 22:22 -0700 |
| Message-ID | <d94824a8-f89f-4e59-a068-61421f4d4346@googlegroups.com> |
| In reply to | #32555 |
to have variable-sized typed locals. You mention "short strings" --- I also have no idea why the length of the string makes a difference in regard to whether it is stored in the heap or on the locals stack --- memory is memory. Memory on the target is hardly unlimited, especially when you have only the internal ram. And the stacks can be more restricted. You don't want to have all your ram as stacks. That's why I stressed "short" strings. You have limited stack space, but with care you can have there some short strings for work. But that's the way I work in C. I never used heap. C use heap for malloc/free but I'm not using this in the embedded systems. I want to know that I have space for the maximum application needs, from the start. That's why when I need some kind of linked lists I fake the "dynamic" part of node allocation with a static array of known max size, and allocate the nodes within it.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-07-23 03:27 -0500 |
| Message-ID | <jfadnac97txj7FLOnZ2dnUVZ_tadnZ2d@supernews.com> |
| In reply to | #32555 |
hughaguilar96@yahoo.com wrote: > > Do you know the history of the ARM processor? Originally, there was > an Acorn computer used for education in England. It was owned by the > BBC (British Broadcasting Corporation) and was the basis for their > educational shows involving computers. It used the 6502. The BBC > wanted to upgrade to a more powerful processor. They experimented > with the MC68000, but they decided that it had too much interrupt > latency (the 6502 had extremely fast interrupts, mostly because it > had only four 8-bit hardware registers to save and restore). The BBC > considered using the W65816, but decided against it because it had > an 8-bit data-bus, and they really wanted a 32-bit data-bus. So they > decided to build their own micro-processor. The result was the ARM > (Acorn Risc Machine) --- its primary feature was fast interrupt > response --- the ARM had a bank of registers that could be swapped > in for ISRs, rather than have to save and restore registers to > memory. Later on, an American company bought the design, and they > renamed it "Advanced Risc Machine" because it no longer was > associated with the Acorn computer that no longer existed. What a load of rubbish. The BBC didn't own Acorn and didn't want to upgrade anything. An American company did not buy the design, which is still owned by ARM Holdings, a British company spun out from Acorn. For anyone who wants to know the actual history of ARM and Acorn, the Wikipedia page at http://en.wikipedia.org/wiki/Acorn_Computers looks pretty good. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-24 19:00 -0700 |
| Message-ID | <ae3a9d1c-9cc0-4dfe-98b7-aa9731653eed@googlegroups.com> |
| In reply to | #32567 |
On Wednesday, July 23, 2014 1:27:42 AM UTC-7, Andrew Haley wrote: > What a load of rubbish. The BBC didn't own Acorn... The BBC education program required the viewers to buy an Acorn; this was essentially a big advertising campaign by the BBC for the Acorn computer. The Acorn computer was never used for anything except the BBC educational program. Why would the BBC advertise a computer owned by somebody else? It seems obvious that Acorn Computers was a front for the BBC. Also obvious, is that this ownership has to be through intermediaries, because the BBC is a government agency and is not supposed to be in for-profit ventures --- it is called "insider trading" --- people buy stock in Acorn Computers because they know ahead of time that the BBC will advertise the heck out of the Acorn, and they know this because they are the BBC management. > and didn't want to > upgrade anything. Everybody building a 6502-based computer wanted to upgrade to something more powerful in the late 1980s. Like I said, Acorn considered the MC68000 (too slow on interrupt response) and the 65C816 (still 8-bit), and then decided to build a custom processor which was the ARM. By comparison, Apple upgraded to the 65c816 in their Apple-IIGS, but it was a big flop because it was still 8-bit and too slow. >An American company did not buy the design, which > is still owned by ARM Holdings, a British company spun out from Acorn. Advanced RISC Machines Ltd. was a joint venture between Apple and VLSI, both of which are American companies --- they bought the ARM design. Apple finally realized that the 65C816 was a dead-end, and so they bought the ARM --- they liked the ARM because it was low-power (like the 65C816) but a lot more powerful --- they bought the ARM primarily for use in their Newton, although that was a flop because handwriting-interpretation was a bad idea (it didn't work very well, it required the user to have a stylus, and it wasn't a big improvement over a paper notepad in what it could do). Later on Apple used the ARM in their iPhone --- this was a lot more successful.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-07-25 03:51 -0500 |
| Message-ID | <v_-dnYr-u6Pph0_OnZ2dnUVZ_gmdnZ2d@supernews.com> |
| In reply to | #32632 |
hughaguilar96@yahoo.com wrote: > On Wednesday, July 23, 2014 1:27:42 AM UTC-7, Andrew Haley wrote: >> What a load of rubbish. The BBC didn't own Acorn... > > The BBC education program required the viewers to buy an Acorn; this > was essentially a big advertising campaign by the BBC for the Acorn > computer. The Acorn computer was never used for anything except the > BBC educational program. No, it was used by many people for many things: it was a highly successful personal computer. > Why would the BBC advertise a computer owned by somebody else? It > seems obvious that Acorn Computers was a front for the BBC. It may seem obvious to you, but it is not true. Acorn won the competition for that contract. > Also obvious, is that this ownership has to be through > intermediaries, because the BBC is a government agency and is not > supposed to be in for-profit ventures --- it is called "insider > trading" --- people buy stock in Acorn Computers because they know > ahead of time that the BBC will advertise the heck out of the Acorn, > and they know this because they are the BBC management. BBC finances are a matter of public record. They didn't own Acorn. >> and didn't want to upgrade anything. > > Everybody building a 6502-based computer wanted to upgrade to > something more powerful in the late 1980s. Yes. But it was nothing to do with the BBC. >> An American company did not buy the design, which is still owned by >> ARM Holdings, a British company spun out from Acorn. > > Advanced RISC Machines Ltd. was a joint venture between Apple and > VLSI, both of which are American companies --- they bought the ARM > design. There is a grain of truth in what you say: ARM Ltd was originally a joint venture between Acorn, Apple, and VLSI. However, they didn't sell the ARM design: it is still owned by ARM Holdings, a British public company, as anyone can verify. 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. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | jkn_gg@nicorp.f9.co.uk |
|---|---|
| Date | 2014-07-25 04:50 -0700 |
| Message-ID | <d3e12e17-87d1-49d3-84cb-83358acd08cd@googlegroups.com> |
| In reply to | #32638 |
As someone who grew up with computers in the UK around the time of the BBC
Micro(*), who used to work in Cambridge, UK (home of ARM), and who has shares in
Arm Holdings, Ltd, I concur with Andrew - Hugh's idea of the history & background of the BBC Micro and the ARM is nonsense.
Jon N
(*) not 'The Acorn' - if anything that term would be use for the Acorn Electron,
the predecessor of the BBC Micro.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-07-25 08:11 -0700 |
| Message-ID | <f500137f-33ab-40a5-8d8f-fd11bae2bc42@googlegroups.com> |
| In reply to | #32639 |
Ahem. The Electron came out *after* the BBC model A and model B. You're thinking of the Atom. To put the record straight: The BBC A nameand B machines were commissioned by the BBC to support their efforts to launch an computing education programme, primarily for schools. A number of BBC TV series were commissioned to support the effort. An early problem for the BBC was to choose a machine which had the right feature set and capabilities. They wrote a specification and gave it to a number of UK based computer manufacturers. Sinclair was one of them. Acorn was not. Newbrain were an early favourite. Acorn (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. 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's an excellent BBC drama about it called Micro Men.
[toc] | [prev] | [next] | [standalone]
Page 5 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