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 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-10 11:12 -0700 |
| Message-ID | <e170a9d6-f31c-4764-a171-3ef2b5edacfd@googlegroups.com> |
| In reply to | #32312 |
> The other reason to want to be compliant with the standard is because you are sharing something. In my mind, that is the more important reason, though those engaged in selling something could well disagree. > Yup, that comes to my mid too. The most annoying is the <# # #> thing. It looks like it is suppose to be working everywere, anytime, and it is, until the "0" that comes for doubling the otherwise single cell unsigned number... That zero makes my stuff not compatible with existing stuff. I did not like this even for a 16bit system. Why force 32bit operations for 8 bit microcontrollers, when you know that you have 16bit numeric output? You specifically put with your own hand the 0 to make it double. Here comes some forth paradoxes: on one hand, forth have different name for different types on operators, for unsigned, for floats, etc. On the other hand we want single words that should work on more than one type: this is the picture numeric output: have one for doubles, because it will work for singles too. Yes, but with BIG overheads.
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2014-07-10 11:30 -0700 |
| Message-ID | <ccb1d2d4-3f31-4f2c-bcc1-12b9afa55d67@googlegroups.com> |
| In reply to | #32314 |
On Thursday, July 10, 2014 2:12:18 PM UTC-4, Raimond Dragomir wrote: > On the other hand we want single words that should work on more than one type: this is the picture numeric output: have one for doubles, because it will work for singles too. Yes, but with BIG overheads. But an equally concise single celled version just rests on having a punctuation character you are willing to devote to the single cell equivalent of # ... if & then: <& & HOLD &S &> ... in the implementation and the problem is fixed ... and if there is <# # #S and #> defined in a source file somewhere, then you've "provided" those CORE words. Andrew's experience with motor control matches my experience with data logging ~ its the identical problem, the discontinuity around 0 ... ... and it seems like a part of the reason that SM/REM is fine for you is that you've have the range of values where the flaw with SM/REM comes up. There's a lot of people for whom the difference doesn't make a difference, but on the other hand *among* those for whom it makes a difference, more need the FM/MOD version than the SM/REM version ... so SM/REM provides a way to export a hardware symmetric divide under a standard name so that people who need an FM/MOD are able to make the conversion. Making FM/MOD CORE means that an implementer that doesn't include it in the binary of their system really ought to include source for the FM/MOD word for the use of those who need it.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2014-07-10 11:59 -0700 |
| Message-ID | <fb6046ef-72a1-45b2-9b08-8d9c6a8d364b@googlegroups.com> |
| In reply to | #32316 |
> ... in the implementation and the problem is fixed ... and if there is <# # #S and #> defined in a source file somewhere, then you've "provided" those CORE words. > Making FM/MOD CORE means that an implementer that doesn't include it in the binary of their system really ought to include source for the FM/MOD word for the use of those who need it. Personally, I have a big problems with this kind of solution: providing in source form anything that you don't provide. And this seems to be the solution for everything. To me this sounds like: "I really don't have this XXX word. But if you really want it, and you don't know how to write it in terms of the other words that I do have, or if you really tried hard to find an implementation over internet but didn't find anything, take this source, I wrote it for you". I will give you one single example: For a FM/MOD in source form, only the threading overhead (I have a token threading for the cortex, others may have ITC or DTC) is going to take longer than the whole routine written in assembly. Nevertheless, I could provide this kind of words in source form: \ these definitions will be inlined by the optimizing compiler : nop ( -- ) ; : 1+ ( x -- x ) 1 + ; : 1- ( x -- x ) -1 + ; : cell+ ( x -- x ) 4 + ; : cell- ( x -- x ) -4 + ; : cells ( x -- x ) 4 * ; : 2* ( x -- x ) 2 * ; : bl ( -- 32 ) 32 ; : false ( -- 0 ) 0 ; : true ( -- -1 ) -1 ; \ these definitions will take only dictionary space synonym char+ 1+ synonym chars nop synonym i r@ \ loops : ilim ( -- x ) 1 rpick ; : j ( -- x ) 2 rpick ; : jlim ( -- x ) 3 rpick ; : k ( -- x ) 4 rpick ; : klim ( -- x ) 5 rpick ; \ : erase ( addr u -- ) 0 fill ; \ terminal i/o : cr ( -- ) 13 emit 10 emit ; : space ( -- ) bl emit ; But double numbers math and <# # #> for doubles are a different story....
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2014-07-10 12:54 -0700 |
| Message-ID | <abfc7365-3d5e-4bc4-95a6-bdb107f1aadb@googlegroups.com> |
| In reply to | #32319 |
On Thursday, July 10, 2014 8:59:02 PM UTC+2, Raimond Dragomir wrote: > > Personally, I have a big problems with this kind of solution: providing in > source form anything that you don't provide. And this seems to be the > solution for everything. > > To me this sounds like: "I really don't have this XXX word. But if you really > want it, and you don't know how to write it in terms of the other words that > I do have, or if you really tried hard to find an implementation over > internet but didn't find anything, take this source, I wrote it for you". [..] When an implementer choses this way out he can be as system-specific as he likes. He can provide you with a bunch of CODE x $yy c, .. END-CODE definitions that will make you perfectly happen. -marcel
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-10 12:56 -0700 |
| Message-ID | <e3dca239-7694-4480-8466-dd3ad85882b7@googlegroups.com> |
| In reply to | #32319 |
On Thursday, July 10, 2014 2:59:02 PM UTC-4, Raimond Dragomir wrote: > To me this sounds like: "I really don't have this XXX word. But if you really want it, and you don't know how to write it in terms of the other words that I do have, or if you really tried hard to find an implementation over internet but didn't find anything, take this source, I wrote it for you". To me it sounds like, "in case you need FM/MOD, here is a working FM/MOD definition that is based on SM/REM." So no need to invest the time remembering how symmetric to modular signed division works, and no need to even be connected to the internet. > I will give you one single example: For a FM/MOD in source form, only the threading overhead (I have a token threading for the cortex, others may have ITC or DTC) is going to take longer than the whole routine written in assembly. So? If your SM/REM is that fast, I'd rather have an FM/MOD written based on that than a FM/MOD written from scratch. Andreas, one of the previous times this came up, had: : FM/MOD \ ( d m -- r q ) signed floored division DUP >R SM/REM 2DUP 0< AND IF 1- SWAP R> + SWAP ELSE R> DROP THEN ; ... if there is more threading overhead in there than processing time, then that would imply there is a reasonably fast SM/REM ... and leveraging that fast SM/REM is *precisely what someone who needs FM/MOD would want to do*. A two liner definition which is easy to get a corner case wrong is exactly sometime I would be happy to find if an implementation told me: ? FM/MOD > Nevertheless, I could provide this kind of words in source form: ... > But double numbers math and <# # #> for doubles are a different story.... To be sure they can be more like three or four line definitions, but since its for I/O, if the extra time for processing is not worth it, the source can be ported to use the single-cell words.
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-10 13:19 -0700 |
| Message-ID | <1ff0ce48-9226-4fa9-a4f0-353866ff9d13@googlegroups.com> |
| In reply to | #32323 |
On Thursday, July 10, 2014 3:56:49 PM UTC-4, bruce.m...@gmail.com wrote: > On Thursday, July 10, 2014 2:59:02 PM UTC-4, Raimond Dragomir wrote: > > But double numbers math and <# # #> for doubles are a different story.... > To be sure they can be more like three or four line definitions, but since its for I/O, if the extra time for processing is not worth it, the source can be ported to use the single-cell words. I meant, of course, definitions for UD/MOD based on smaller division ... obviously, given that: : # ( ud1 -- ud2 ) BASE @ UD/MOD ROT >digit HOLD ; : #S ( ud1 -- ud2 ) BEGIN # 2DUP OR 0= UNTIL ; ... are more one-liners.
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2014-07-10 23:01 +0200 |
| Message-ID | <165kupqqn7k3y.mzj8s2x1j2gj.dlg@40tude.net> |
| In reply to | #32327 |
Op Thu, 10 Jul 2014 13:19:07 -0700 (PDT) schreef bruce.mcfarling@gmail.com: > On Thursday, July 10, 2014 3:56:49 PM UTC-4, bruce.m...@gmail.com wrote: >> On Thursday, July 10, 2014 2:59:02 PM UTC-4, Raimond Dragomir wrote: >>> But double numbers math and <# # #> for doubles are a different story.... > >> To be sure they can be more like three or four line definitions, but since its for I/O, if the extra time for processing is not worth it, the source can be ported to use the single-cell words. > > I meant, of course, definitions for UD/MOD based on smaller division ... obviously, given that: > >: # ( ud1 -- ud2 ) BASE @ UD/MOD ROT >digit HOLD ; >: #S ( ud1 -- ud2 ) BEGIN # 2DUP OR 0= UNTIL ; > > ... are more one-liners. : # 0 BASE @ UM/MOD >R BASE @ UM/MOD SWAP >digit HOLD R> ; Somewhat longer, but no need to define UD/MOD which is used nowhere else. -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-10 16:29 -0700 |
| Message-ID | <04c46e11-aca2-4c6c-86a4-77df92e0878c@googlegroups.com> |
| In reply to | #32329 |
On Thursday, July 10, 2014 5:01:41 PM UTC-4, Coos Haak wrote: > BruceMcF: >> I meant, of course, definitions for UD/MOD based on smaller division ... obviously, given that: >>: # ( ud1 -- ud2 ) BASE @ UD/MOD ROT >digit HOLD ; >>: #S ( ud1 -- ud2 ) BEGIN # 2DUP OR 0= UNTIL ; >> ... are more one-liners. > : # 0 BASE @ UM/MOD >R BASE @ UM/MOD SWAP >digit HOLD R> ; > Somewhat longer, but no need to define UD/MOD which is used nowhere else. I should have cited the source ~ those were Brad Rodriguez's Camel Forth for 8086 ~ and yes, for illustrative purposes. Even if fitting into 63 char lines and including stack comment, that is only a two-liner. How to write a UM/MOD out of an ``U/MOD ( u1 u2 -- u3 u4 )'', I don't know off the top of my head, but I can't imagine it would be as hard as writing UM/MOD in assembler, so I guess if I was pressed, I'd work it out.
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2014-07-11 02:15 +0200 |
| Message-ID | <10zgyj2vtth7a.r18sv7lm4x09$.dlg@40tude.net> |
| In reply to | #32332 |
Op Thu, 10 Jul 2014 16:29:07 -0700 (PDT) schreef bruce.mcfarling@gmail.com: > On Thursday, July 10, 2014 5:01:41 PM UTC-4, Coos Haak wrote: >> BruceMcF: >>> I meant, of course, definitions for UD/MOD based on smaller division ... obviously, given that: > >>>: # ( ud1 -- ud2 ) BASE @ UD/MOD ROT >digit HOLD ; >>>: #S ( ud1 -- ud2 ) BEGIN # 2DUP OR 0= UNTIL ; > >>> ... are more one-liners. > >>: # 0 BASE @ UM/MOD >R BASE @ UM/MOD SWAP >digit HOLD R> ; > >> Somewhat longer, but no need to define UD/MOD which is used nowhere else. > > I should have cited the source ~ those were Brad Rodriguez's Camel Forth for 8086 ~ and yes, for illustrative purposes. Even if fitting into 63 char lines and including stack comment, that is only a two-liner. > > How to write a UM/MOD out of an ``U/MOD ( u1 u2 -- u3 u4 )'', I don't know off the top of my head, but I can't imagine it would be as hard as writing UM/MOD in assembler, so I guess if I was pressed, I'd work it out. Adding the single precision: : U# ( u1 -- u2 ) 0 BASE @ UM/MOD SWAP >digit HOLD ; Aside: Camel Forth for the 1802 used big endian for the data and the return stack, but little endian for the data stack. This way >R and @ etc. are faster. Both stack grow downwards. FigForth for the 1802 had stacks growing to each other with the terminal input buffer in the middle. All addresses were bigendian, but the data stack was slower than Camelforth, and was ITC instead of DTC. If it had existed in 1981, my ELF II would still be running... -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-10 20:00 -0700 |
| Message-ID | <b6b04a91-ff2f-468d-a768-c799f6105ec2@googlegroups.com> |
| In reply to | #32334 |
On Thursday, July 10, 2014 8:15:01 PM UTC-4, Coos Haak wrote: > Aside: Camel Forth for the 1802 used big endian for the data and the return > stack, but little endian for the data stack. This way >R and @ etc. are > faster. Both stack grow downwards. Big endian for return, little endian for data? I presume that is to make effective use of the indirect register with auto-increment address mode? I have never had the joy of coding the 1802 ... that is to say, the Wikipedia page makes it sound like a joy. > FigForth for the 1802 had stacks growing to each other with the terminal > input buffer in the middle. All addresses were bigendian, but the data > stack was slower than Camelforth, and was ITC instead of DTC. If it had > existed in 1981, my ELF II would still be running... I like having data and return stacks growing toward each other, but I've never thought to have the console input buffer in between the two.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-07-10 17:56 -1000 |
| Message-ID | <uNydnTHs1Mbj_SLOnZ2dnUVZ_qednZ2d@supernews.com> |
| In reply to | #32339 |
On 7/10/14 5:00 PM, bruce.mcfarling@gmail.com wrote: > On Thursday, July 10, 2014 8:15:01 PM UTC-4, Coos Haak wrote: >> Aside: Camel Forth for the 1802 used big endian for the data and the return >> stack, but little endian for the data stack. This way >R and @ etc. are >> faster. Both stack grow downwards. > > Big endian for return, little endian for data? > > I presume that is to make effective use of the indirect register with auto-increment address mode? I have never had the joy of coding the 1802 ... that is to say, the Wikipedia page makes it sound like a joy. > >> FigForth for the 1802 had stacks growing to each other with the terminal >> input buffer in the middle. All addresses were bigendian, but the data >> stack was slower than Camelforth, and was ITC instead of DTC. If it had >> existed in 1981, my ELF II would still be running... > > I like having data and return stacks growing toward each other, but I've never thought to have the console input buffer in between the two. > Historically, FORTH, Inc. systems have the dictionary grow from low memory upward. The return stack is at the top, growing towards low memory. The data stack is lower and growing towards low memory, with TIB extending up from the bottom of the data stack towards the Return Stack (with some guard cells). This way the stacks have plenty of space, as they're growing towards memory that is likely to be available (typically, the terminal buffer is short when the Return Stack is deeper), with a modest amount of dedicated memory. Back in the day when there were block buffers, they were in high memory above the Return Stack. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-11 12:12 +0000 |
| Subject | Implementing UM/MOD (was: Forth16e, Forth32e, ...) |
| Message-ID | <2014Jul11.141257@mips.complang.tuwien.ac.at> |
| In reply to | #32332 |
bruce.mcfarling@gmail.com writes:
>How to write a UM/MOD out of an ``U/MOD ( u1 u2 -- u3 u4 )'', I don't know off the top of my head, but I can't imagine it would be as hard as writing UM/MOD in assembler, so I guess if I was pressed, I'd work it out.
I think it's harder. When I ported Gforth to the Alpha in 1995, our
first 64-bit port, we found out that GCC was buggy and did not
implement long long as documented (later they fixed the
documentation), so we had to do our own implementations of double and
mixed primitives. For UM/MOD I looked around and eventually settled
on implementing division with shifts and subtracts, the way I had
learned it on the 6502 (and FM/MOD and SM/REM are based on the UM/MOD
implementation).
Admittedly building on top of single-by-single division is not very
attractive on the Alpha, because the Alpha has no hardware division,
but my implementation was also intended and used for other 64-bit
platforms.
Much later (in 2006), we reworked the mixed division implementation
for more performance and looked at what various books said and what
others had programmed, and this all resulted in a huge piece of messy
code: Look at umdiv() ff. in
http://git.savannah.gnu.org/cgit/gforth.git/tree/engine/support.c
which uses macros defined in
http://git.savannah.gnu.org/cgit/gforth.git/tree/engine/longlong.h
(only 1356 lines of macros, used only for mixed division).
- 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 | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-11 07:41 -0700 |
| Subject | Re: Implementing UM/MOD (was: Forth16e, Forth32e, ...) |
| Message-ID | <4128fa42-32d9-4ee7-8a12-4921ecf35879@googlegroups.com> |
| In reply to | #32353 |
On Friday, July 11, 2014 8:12:57 AM UTC-4, Anton Ertl wrote: > BruceMcF writes: > >How to write a UM/MOD out of an ``U/MOD ( u1 u2 -- u3 u4 )'', I don't know off the top of my head, but I can't imagine it would be as hard as writing UM/MOD in assembler, so I guess if I was pressed, I'd work it out. > I think it's harder. ... > Admittedly building on top of single-by-single division is not very > attractive on the Alpha, because the Alpha has no hardware division, > but my implementation was also intended and used for other 64-bit > platforms. > Much later (in 2006), we reworked the mixed division implementation > for more performance ... But (1) you are rewriting for more performance and (2) in C ... for a portability layer to support <# # #> I/O, performance should be balanced against code size. A long division algorithm would have 4 ``M/MOD'' consuming the first three intermediate result mods as it goes to build the next dividend and reserving the intermediate quotients underneath to build into the final quotient.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-07-11 15:56 +0000 |
| Subject | Re: Implementing UM/MOD (was: Forth16e, Forth32e, ...) |
| Message-ID | <2014Jul11.175625@mips.complang.tuwien.ac.at> |
| In reply to | #32357 |
bruce.mcfarling@gmail.com writes:
>On Friday, July 11, 2014 8:12:57 AM UTC-4, Anton Ertl wrote:
>> BruceMcF writes:
>
>> >How to write a UM/MOD out of an ``U/MOD ( u1 u2 -- u3 u4 )'', I don't kn=
>ow off the top of my head, but I can't imagine it would be as hard as writi=
>ng UM/MOD in assembler, so I guess if I was pressed, I'd work it out.
>
>> I think it's harder. ...
>
>> Admittedly building on top of single-by-single division is not very=20
>> attractive on the Alpha, because the Alpha has no hardware division,
>> but my implementation was also intended and used for other 64-bit
>> platforms.
>
>> Much later (in 2006), we reworked the mixed division implementation=20
>> for more performance ...=20
>
>But (1) you are rewriting for more performance and (2) in C ...
The performance is in comparison with double-by-double division (what
we did before on platforms where long long was implemented correctly),
so that's not a very aggressive performance goal. And the original
poster also had performance in mind.
> A long division algorithm would have 4 ``M/MOD'' consuming the =
>first three intermediate result mods as it goes to build the next dividend =
>and reserving the intermediate quotients underneath to build into the final=
> quotient.
I am eagerly expecting your implementation. If I had found an
attractive mixed division algorithm that's based on single division, I
would have used it (instead of shift-and-subtract) on the first
implementation, and also on the reworking of mixed division. I don't
like the big mess that this stuff is now (with architecture-specific
ifdefs and lots of inline assembly language).
- 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 | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-11 09:26 -0700 |
| Subject | Re: Implementing UM/MOD (was: Forth16e, Forth32e, ...) |
| Message-ID | <57eb78da-0fd5-41b9-8220-0e332ac7bd56@googlegroups.com> |
| In reply to | #32361 |
On Friday, July 11, 2014 11:56:25 AM UTC-4, Anton Ertl wrote: > BruceMcF writes: > I am eagerly expecting your implementation. I can tell you in advance that, no, you aren't ^_^ ... a long division seems like it is almost always going to be slower than what you've got ... and in the rare case that its not, now you are just spilling the conditional compilation from C into Forth. But if I have time this weekend, I'll see if I can convert a 16/8=8:8 to 32/16=16:16 into a 32/16=16:16 to 64/32=32:32, since a flat 32/32=32:32 M/MOD on a 32 bit Forth can of course serve as a 32/16=16:16 (although for a 32 bit forth on a 16 bit processor in a space-constrained implementation, one might have a 32/16=16:16 primitive as its more compact, and for operations in its range, more efficient). > If I had found an attractive mixed division algorithm that's based on single > division, I would have used it (instead of shift-and-subtract) on the first > implementation, and also on the reworking of mixed division. I don't > like the big mess that this stuff is now (with architecture-specific > ifdefs and lots of inline assembly language). The key word there is "attractive". You wouldn't want to make that space/speed trade-off for the general division operation for gforth.
[toc] | [prev] | [next] | [standalone]
| From | AKK <akk@nospam.org> |
|---|---|
| Date | 2014-07-11 20:05 +0200 |
| Subject | Re: Implementing UM/MOD |
| Message-ID | <53c02761$0$6610$9b4e6d93@newsspool4.arcor-online.net> |
| In reply to | #32361 |
Am 11.07.2014 17:56, schrieb Anton Ertl:
> bruce.mcfarling@gmail.com writes:
>> On Friday, July 11, 2014 8:12:57 AM UTC-4, Anton Ertl wrote:
>>> BruceMcF writes:
>>
>>>> How to write a UM/MOD out of an ``U/MOD ( u1 u2 -- u3 u4 )'', I don't kn=
>> ow off the top of my head, but I can't imagine it would be as hard as writi=
>> ng UM/MOD in assembler, so I guess if I was pressed, I'd work it out.
>>
>>> I think it's harder. ...
>>
>>> Admittedly building on top of single-by-single division is not very=20
>>> attractive on the Alpha, because the Alpha has no hardware division,
>>> but my implementation was also intended and used for other 64-bit
>>> platforms.
>>
>>> Much later (in 2006), we reworked the mixed division implementation=20
>>> for more performance ...=20
>>
>> But (1) you are rewriting for more performance and (2) in C ...
>
> The performance is in comparison with double-by-double division (what
> we did before on platforms where long long was implemented correctly),
> so that's not a very aggressive performance goal. And the original
> poster also had performance in mind.
>
>> A long division algorithm would have 4 ``M/MOD'' consuming the =
>> first three intermediate result mods as it goes to build the next dividend =
>> and reserving the intermediate quotients underneath to build into the final=
>> quotient.
>
> I am eagerly expecting your implementation. If I had found an
> attractive mixed division algorithm that's based on single division, I
> would have used it (instead of shift-and-subtract) on the first
> implementation, and also on the reworking of mixed division. I don't
> like the big mess that this stuff is now (with architecture-specific
> ifdefs and lots of inline assembly language).
>
> - anton
>
I dug out the following ugly beast from some dusty archive. The
bit-shifting for-loop is only 32 bit wide because it can be cut short
when the divident has only 32 bit.
void mf_mudivmod(MF_ADDR* mfsp) // ( udl udh u -- qdl qdh r )
{
#if MF_ASM
__asm { push ebp
push ebx
mov ebp, [mfsp]
mov ebx, [ebp]
mov edx, [ebp-4]
mov eax, [ebp-8]
mov ecx, eax
mov eax, edx
xor edx, edx
div ebx
xchg eax, ecx
div ebx
mov [ebp], edx
mov [ebp-4], ecx
mov [ebp-8], eax
pop ebx
pop ebp }
#elif MF_MATH64
MF_DADDR *ud = (MF_DADDR*)(mfsp-2); MF_ADDR tos = MF_TOS;
MF_TOS = *ud % tos, *ud /= tos;
#else // partial radix 2
int i; MF_ADDR a,b,c,d;
b = MF_THIRD, c = MF_SECOND, d = MF_TOS;
if (c == 0)
MF_THIRD = b / d, MF_TOS = b % d;
else
{ a = c / d, c %= d;
for (i=0; i<32; i++)
{ d = ((MF_CELL)c < 0);
c = (c << 1) | ((MF_CELL)b < 0);
b = (b << 1) | ((MF_CELL)a < 0);
a = (a << 1);
if ((c >= MF_TOS) | d) c -= MF_TOS, a += 1; }
MF_THIRD = a, MF_SECOND = b, MF_TOS = c; }
#endif
}
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-12 01:38 -0700 |
| Subject | Re: Implementing UM/MOD (was: Forth16e, Forth32e, ...) |
| Message-ID | <69633f3f-6625-4a75-88a1-e11d47493deb@googlegroups.com> |
| In reply to | #32361 |
On Friday, July 11, 2014 11:56:25 AM UTC-4, Anton Ertl wrote:
> I am eagerly expecting your implementation.
I think its something along the lines below, though I'm sure there's a bug in there somewhere.
You'll see the problem with long division for the general case instantly ... since you have to work with a divisor half the width of a cell to ensure that the modulus will fit into the top half of the cell, doing it for a general mixed division routine is an interpolation ... if B is larger than half the cell width, then for n such that int(B/2^n) does fit in the lower half of the cell:
partial_quotient = int(A/(int(B/2^n)+1))/2^n)
NB. partial_quotient < quotient
increment = A - B*partial_quotient
Repeat:
B*2^n for n=1,2,.. until [B*2^n]>increment
partial' := partial+B*2^(n-1)
increment' := increment - B*2^(n-1)
until increment<B
Then mod = A - B*quotient
So for the general case, its normally reasonably well behaved, but when its badly behaved, its pretty bad.
However, for the applications at hand ... # and #S ... half a cell is plenty to divide by base. Hence Unsigned, Mixed, "Word" divide and modulus, UMW/MOD
I'm sure I've messed something up trying to simplify this, but I don't have any more time to work on this, I have to fight the closure of a railway corridor tomorrow.
\ UMWMOD.F
\ for testing purposes ~ in reality this would be primitive
\ for hardware 32/32=32:32 division operation.
: U/MOD ( u1 u2 -- u3 u4 ) 0 SWAP UM/MOD ;
\ for testing purposes ~ in reality this would be a hardware
\ cell-wide add with carry set/clear giving high cell 1/0
\ due to eForth ~ may sometimes be known as +'
: UM+ ( u1 u2 -- ud ) 0 SWAP M+ ;
HEX FFFFFFFF CONSTANT MAX-U32
: low16 ( u1 -- u2 ) FFFF AND ;
DECIMAL
: hi16 ( u1 -- u2 ) 16 RSHIFT ;
: lo>hi16 ( u1 -- u2 )
16 LSHIFT ( for testing on 64 bit systems: ) MAX-U32 AND ;
: ?quotient-error ( u -- ) ABORT" UMW/MOD quotient too large." ;
\ Divide 64 bit double in 32 bit system by 16 bit word
: UMW/MOD ( ud w1 -- w2 u )
2DUP < 0= ?quotient-error >R \ high cell must be smaller than divisor
lo>hi16 OVER hi16 OR R@ U/MOD DUP hi16 ?quotient-error ROT ROT
lo>hi16 SWAP low16 OR R> U/MOD ROT UM+ ?quotient-error ;
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-12 02:00 -0700 |
| Subject | Re: Implementing UM/MOD (was: Forth16e, Forth32e, ...) |
| Message-ID | <cca601cb-0969-489c-bd3f-0f5c6a10eaaa@googlegroups.com> |
| In reply to | #32375 |
On Saturday, July 12, 2014 4:38:00 AM UTC-4, bruce.m...@gmail.com wrote: Of course, that's quite wrong because the stack picture was written wrong as a factor for # ... it should be a double divided by a word for a word modulus and a double result \ UMW/MOD ( ud1 w1 -- ud2 w2 ) \ ud2 quotient, w2 remainder \ for testing purposes ~ in reality this would be primitive \ for hardware 32/32=32:32 division operation. : U/MOD ( u1 u2 -- u3 u4 ) 0 SWAP UM/MOD ; \ for testing purposes ~ in reality this would be a hardware \ cell-wide add with carry set/clear giving high cell 1/0 \ due to eForth ~ may sometimes be known as +' : UM+ ( u1 u2 -- ud ) 0 SWAP M+ ; \ must run on a 32 bit cell system HEX : low16 ( u1 -- u2 ) FFFF AND ; DECIMAL : hi16 ( u1 -- u2 ) 16 RSHIFT ; : lo>hi16 ( u1 -- u2 ) 16 LSHIFT ; \ Divide 64 bit double in 32 bit system by 16 bit word \ for 64 bit result and 16 bit or less modulus \ pre-alpha : UMW/MOD ( ud1 w1 -- ud2 w2 ) DUP >R U/MOD SWAP >R SWAP ( res1 ud1lo R: w1 mod1 ) DUP hi16 R> lo>hi16 OR R@ U/MOD SWAP >R SWAP ( res1 res2 ud1lo R: w1 mod2 ) lo16 R> lo>h116 OR R> U/MOD SWAP >R ( res1 res2 res3 R: mod3 ) OVER lo>hi16 UM+ ROT hi16 + ROT UM+ ABORT" UMW/MOD quotient too large" R> ;
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-07-13 09:31 +0000 |
| Message-ID | <53c25205$0$15831$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #32332 |
In article <04c46e11-aca2-4c6c-86a4-77df92e0878c@googlegroups.com>, <bruce.mcfarling@gmail.com> wrote: <SNIP> > >How to write a UM/MOD out of an ``U/MOD ( u1 u2 -- u3 u4 )'', I don't >know off the top of my head, but I can't imagine it would be as hard as >writing UM/MOD in assembler, so I guess if I was pressed, I'd work it >out. Doing UM/MOD in assembler is fairly straightforward, while the jumbling of U/MOD 's parameters makes your head spin. (Of course if you don't have any familiarity with the machine it is different. A Forth implementor probably has.) One emulates the long division. Dividing 2n bits by n bits giving a quotient and remainder of n bits is natural. The basic idea is to work on the m.s. word while shifting the l.s. word and m.s. word together. Then there is a mask, representing the bit to be set in the quotient. It starts at the m.s. bit, is shifted right and if it runs out, the loop is over. The remainder is at a variable place, but ends up in the m.s. word. You actually need one bit more for the unsigned subtracting, be it a carry or on the DEC Alpha an extra register. It doesn't play a role in the subtracting itself, only to decide whether to subtract. If you subtract, you also set the mask in the quotient. That's about it. With some help of m4, I find my DEC Alpha version quite readable. 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 | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-07-13 07:02 -0700 |
| Message-ID | <66df2648-48a1-4dc0-bd97-317fe24948c0@googlegroups.com> |
| In reply to | #32402 |
On Sunday, July 13, 2014 5:31:49 AM UTC-4, Albert van der Horst wrote: > In article <04c46e11-aca2-4c6c-86a4-77df92e0878c@googlegroups.com>, > BruceMcF wrote: > <SNIP> > > > >How to write a UM/MOD out of an ``U/MOD ( u1 u2 -- u3 u4 )'', I don't > >know off the top of my head, but I can't imagine it would be as hard as > >writing UM/MOD in assembler, so I guess if I was pressed, I'd work it > >out. > > Doing UM/MOD in assembler is fairly straightforward, while the > jumbling of U/MOD 's parameters makes your head spin. > (Of course if you don't have any familiarity with the machine it is > different. A Forth implementor probably has.) But the context of the comment was an implementor *not* including UM/MOD *in any form*, with the user left to their own devices to implement it. When I am writing in the first person there, it is with respect to a Forth user who emphatically has no familiarity with any of these machines at assembly language level. The last assembly language I learned was the Z80, when I got my Geneva to take with me to Grenada to teach secondary school Maths. If I was pressed to adapt for a source base that used UM/MOD, and an eForth style division was not sufficiently fast, having to learn the processor's Forth-style assembler and adapting some existing routine from the standard assembler to Forth-style assembler would typically mean I would put that implementation in the "too hard to use" pile.
[toc] | [prev] | [next] | [standalone]
Page 2 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