Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #56164 > unrolled thread
| Started by | Richard Owlett <rowlett@cloud85.net> |
|---|---|
| First post | 2017-03-23 02:17 -0500 |
| Last post | 2017-05-11 20:59 -0700 |
| Articles | 20 on this page of 184 — 31 participants |
Back to article view | Back to comp.lang.forth
comp.lang.forth is THE PROBLEM Richard Owlett <rowlett@cloud85.net> - 2017-03-23 02:17 -0500
Re: comp.lang.forth is THE PROBLEM Julian Fondren <julian.fondren@gmail.com> - 2017-03-23 00:27 -0700
Re: comp.lang.forth is THE PROBLEM anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-23 11:50 +0000
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-03-23 12:34 -0500
Re: comp.lang.forth is THE PROBLEM Julian Fondren <julian.fondren@gmail.com> - 2017-03-23 10:56 -0700
Re: comp.lang.forth is THE PROBLEM mentificium@gmail.com - 2017-03-24 05:25 -0700
Re: comp.lang.forth is THE PROBLEM rickman <gnuarm@gmail.com> - 2017-03-24 19:23 -0400
Re: comp.lang.forth is THE PROBLEM john <anon@example.com> - 2017-05-03 10:54 +0100
Re: comp.lang.forth is THE PROBLEM mentificium@gmail.com - 2017-05-04 05:28 -0700
Re: comp.lang.forth is THE PROBLEM Dennis Ruffer <daruffer@gmail.com> - 2017-03-24 17:46 -0700
Re: comp.lang.forth is THE PROBLEM Julian Fondren <julian.fondren@gmail.com> - 2017-03-24 18:49 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-03-24 22:09 -0500
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-03-24 20:47 -0700
Re: comp.lang.forth is THE PROBLEM krishna.myneni@ccreweb.org - 2017-03-25 10:49 -0700
Re: comp.lang.forth is THE PROBLEM Brad Eckert <hwfwguy@gmail.com> - 2017-05-06 12:39 -0700
Re: comp.lang.forth is THE PROBLEM The Beez <the.beez.speaks@gmail.com> - 2017-05-10 02:07 -0700
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-10 11:23 +0200
Re: comp.lang.forth is THE PROBLEM "Elizabeth D. Rather" <erather@forth.com> - 2017-05-10 16:29 -1000
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-11 13:39 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-11 16:01 -0500
Re: comp.lang.forth is THE PROBLEM "Elizabeth D. Rather" <erather@forth.com> - 2017-05-11 21:41 -1000
Re: comp.lang.forth is THE PROBLEM JUERGEN <epldfpga@aol.com> - 2017-05-12 03:18 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-12 19:12 -0500
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-12 19:15 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 12:01 -0700
Re: comp.lang.forth is THE PROBLEM Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-05-16 17:59 -0400
Re: comp.lang.forth is THE PROBLEM rickman <gnuarm@gmail.com> - 2017-05-24 16:57 -0400
Re: comp.lang.forth is THE PROBLEM JUERGEN <epldfpga@aol.com> - 2017-05-26 02:28 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-12 17:44 -0700
Re: comp.lang.forth is THE PROBLEM JUERGEN <epldfpga@aol.com> - 2017-05-13 00:21 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 12:15 -0700
Re: comp.lang.forth is THE PROBLEM JUERGEN <epldfpga@aol.com> - 2017-05-13 00:30 -0700
Re: comp.lang.forth is THE PROBLEM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-13 04:43 -0500
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-13 12:51 +0100
Re: comp.lang.forth is THE PROBLEM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-13 08:47 -0500
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-13 09:57 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-13 18:26 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-13 10:59 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 12:36 -0700
Re: comp.lang.forth is THE PROBLEM JUERGEN <epldfpga@aol.com> - 2017-05-14 00:33 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-14 12:04 -0500
Re: comp.lang.forth is THE PROBLEM JUERGEN <epldfpga@aol.com> - 2017-05-14 11:45 -0700
Re: comp.lang.forth is THE PROBLEM Paul Rubin <no.email@nospam.invalid> - 2017-05-14 12:02 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-14 14:22 -0500
Re: comp.lang.forth is THE PROBLEM JUERGEN <epldfpga@aol.com> - 2017-05-14 23:08 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-14 14:12 -0500
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-14 12:25 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-14 14:48 -0500
Re: comp.lang.forth is THE PROBLEM Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-05-15 00:24 -0400
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 00:14 -0500
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 00:17 -0500
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 00:30 -0500
Re: comp.lang.forth is THE PROBLEM Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-15 09:54 +0100
Re: comp.lang.forth is THE PROBLEM Mark Wills <markwills1970@gmail.com> - 2017-05-15 02:27 -0700
Re: comp.lang.forth is THE PROBLEM Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-05-15 00:24 -0400
Re: comp.lang.forth is THE PROBLEM Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-15 09:53 +0100
Re: comp.lang.forth is THE PROBLEM Andreas Klimas <klimas@w3group.de> - 2017-05-15 16:31 +0200
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-15 11:43 -0700
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-15 15:47 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-15 20:06 -0700
Re: comp.lang.forth is THE PROBLEM Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-16 12:05 +0100
Re: comp.lang.forth is THE PROBLEM stephen@mpeforth.com (Stephen Pelc) - 2017-05-16 15:00 +0000
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-16 10:52 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-16 19:33 +0100
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-16 21:11 +0200
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-16 21:25 +0100
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-17 07:48 +0200
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-17 10:50 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-17 19:27 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-17 11:42 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-17 20:22 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-17 12:57 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-17 13:01 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-18 13:01 +0100
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-18 14:09 +0200
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-18 07:00 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-18 22:15 -0700
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-17 22:21 -0700
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-18 08:04 +0200
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-17 23:10 -0700
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-18 08:19 +0200
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-17 23:29 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-18 08:44 +0100
Re: comp.lang.forth is THE PROBLEM Mark Wills <markwills1970@gmail.com> - 2017-05-18 01:13 -0700
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-18 10:02 +0200
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-18 01:29 -0700
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-18 11:34 +0200
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-18 03:56 -0700
Re: comp.lang.forth is THE PROBLEM stephen@mpeforth.com (Stephen Pelc) - 2017-05-18 09:44 +0000
Re: comp.lang.forth is THE PROBLEM stephen@mpeforth.com (Stephen Pelc) - 2017-05-18 09:42 +0000
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-18 03:59 -0700
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-18 13:01 +0200
Re: comp.lang.forth is THE PROBLEM Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-18 08:26 +0100
Re: comp.lang.forth is THE PROBLEM stephen@mpeforth.com (Stephen Pelc) - 2017-05-18 09:37 +0000
Re: comp.lang.forth is THE PROBLEM Paul Rubin <no.email@nospam.invalid> - 2017-05-18 08:16 -0700
Re: comp.lang.forth is THE PROBLEM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 11:04 -0500
Re: comp.lang.forth is THE PROBLEM Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-16 19:41 +0100
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-16 21:05 +0200
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-16 11:21 -0700
Re: comp.lang.forth is THE PROBLEM Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-16 20:32 +0100
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-16 19:35 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-17 11:06 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-17 19:30 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-17 12:02 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-17 20:41 +0100
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-17 19:17 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-17 20:58 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-18 10:46 +0100
Re: comp.lang.forth is THE PROBLEM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 08:43 -0500
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-18 16:00 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-20 01:47 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-20 13:03 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-20 17:51 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-21 07:51 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-21 00:11 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-21 17:46 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-21 10:34 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-21 20:57 +0100
Re: comp.lang.forth is THE PROBLEM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 04:08 -0500
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-18 10:51 +0100
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-18 05:15 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-18 14:51 +0100
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-18 09:18 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-18 21:15 +0100
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-18 19:49 -0700
Re: comp.lang.forth is THE PROBLEM Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-19 07:10 +0200
Re: comp.lang.forth is THE PROBLEM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-19 07:42 -0500
Re: comp.lang.forth is THE PROBLEM Coos Haak <htrofhc@gmail.com> - 2017-05-19 09:59 +0200
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-19 18:48 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-19 12:40 +0100
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-19 20:57 -0700
Re: comp.lang.forth is THE PROBLEM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-20 03:42 -0500
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-20 02:00 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-20 10:15 +0100
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-20 13:34 +0100
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-20 02:01 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-20 13:18 +0100
Re: comp.lang.forth is THE PROBLEM albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-19 17:06 +0200
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-19 08:31 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-19 17:02 +0100
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-19 09:18 -0700
Re: comp.lang.forth is THE PROBLEM Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-19 09:34 -0700
Re: comp.lang.forth is THE PROBLEM Andreas Klimas <klimas@w3group.de> - 2017-05-18 16:40 +0200
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-18 08:12 -0700
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-19 02:30 -0700
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-19 18:57 -0700
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-20 14:01 -0700
Re: comp.lang.forth is THE PROBLEM albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-21 19:55 +0200
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-21 11:57 -0700
Re: comp.lang.forth is THE PROBLEM Julian Fondren <julian.fondren@gmail.com> - 2017-05-21 12:41 -0700
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-21 13:02 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-21 14:43 -0700
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-21 16:32 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-21 18:46 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-22 07:05 +0100
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-23 13:45 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-23 22:02 +0100
Re: comp.lang.forth is THE PROBLEM Mark Wills <markwills1970@gmail.com> - 2017-05-24 01:00 -0700
Re: comp.lang.forth is THE PROBLEM Alex <alex@rivadpm.com> - 2017-05-24 14:07 +0100
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-18 22:14 -0700
Re: comp.lang.forth is THE PROBLEM "Elizabeth D. Rather" <erather@forth.com> - 2017-05-16 18:48 -1000
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-21 15:06 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 12:16 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-15 12:18 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 11:58 -0700
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-12 03:32 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-12 19:29 -0500
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-13 08:25 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-13 13:25 -0500
Re: comp.lang.forth is THE PROBLEM "Robert L." <No_spamming@noWhere_7073.org> - 2017-05-15 05:45 +0000
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-15 06:54 -0700
Re: comp.lang.forth is THE PROBLEM Andreas Klimas <klimas@w3group.de> - 2017-05-15 16:30 +0200
Re: comp.lang.forth is THE PROBLEM Paul Rubin <no.email@nospam.invalid> - 2017-05-16 00:32 -0700
Re: comp.lang.forth is THE PROBLEM Joel Rees <joel.rees@gmail.com> - 2017-05-16 19:25 -0700
Re: comp.lang.forth is THE PROBLEM Paul Rubin <no.email@nospam.invalid> - 2017-05-16 21:15 -0700
Re: comp.lang.forth is THE PROBLEM Julian Fondren <julian.fondren@gmail.com> - 2017-05-16 21:34 -0700
Re: comp.lang.forth is THE PROBLEM Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-15 08:39 -0700
Re: comp.lang.forth is THE PROBLEM hughaguilar96@gmail.com - 2017-05-15 12:38 -0700
Re: comp.lang.forth is THE PROBLEM Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 17:32 -0500
Re: comp.lang.forth is THE PROBLEM Andreas Klimas <klimas@w3group.de> - 2017-05-16 10:06 +0200
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 11:51 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 11:50 -0700
Re: comp.lang.forth is THE PROBLEM gavino himself <jackvanc3@gmail.com> - 2017-05-16 11:47 -0700
Re: comp.lang.forth is THE PROBLEM Bill Zimmerly <billzimmerly@gmail.com> - 2017-05-11 20:59 -0700
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-05-16 12:05 +0100 |
| Message-ID | <ofem7d$5a8$1@dont-email.me> |
| In reply to | #59320 |
On 15/05/2017 19:43, hughaguilar96@gmail.com wrote: > On Monday, May 15, 2017 at 1:53:12 AM UTC-7, Gerry wrote: >> On 14/05/2017 20:25, hughaguilar96@gmail.com wrote: >>> ANS-Forth was purposely sabotaged to make it useless. >> >> In the unlikely event of that being the case, ISTM that the saboteurs >> were incompetent. e.g. > > That sounds like an argument for ignoring ANS-Forth --- it was written by incompetents --- press the flush lever! Heh, I should have worded that better. I meant, of course, incompetent as saboteurs. > >> > I think my STRING-STACK.4TH is pretty good Forth, and it is fully >> > ANS-Forth compliant. Why haven't the Forth-200x committee provided >> > something similar? >> >> Why should they? It's not the job of a standards committee to write >> libraries. It could be argued that they should specify the words such a >> library should contain but imagine the howls of outrage from you and HAA >> that would cause. > > I didn't say that they should declare their string-stack to be the standard. I don't want them to declare anything to be standard at this time because I have no intention at this time of being their follower --- they have never earned my respect, or made any effort to do so --- they really need to start out as my peer, and then work their way up, not just declare themselves to be the rulers of the world by fiat. > > What I am saying, is that if they are going to describe themselves as leaders of the Forth community, they should first write useful Forth code-libraries --- this would be a good start toward gaining the respect of Forthers such as myself --- this is actually the only way to gain credence as leaders. > Evidently they don't agree. I don't think they "declare themselves to be the rulers of the world" - only the world of ANS Forth and Forth 2012 and following standards. And as the Forth 200X Standard Committee that is their right and responsibility. > I am extremely offended by Elizabeth Rather who declares herself to be the "leading expert" of Forth, I just look on claims like that as marketing hype indulged in by all commercial organisations. British English has a phrase 'blowing your own trumpet' that covers such claims. Just ignore it and move on. > Stephen Pelc has admitted on comp.lang.forth that he doesn't know how to write a cross-compiler: > > On Tuesday, December 8, 2009 at 3:18:13 PM UTC-7, Stephen Pelc wrote: >> There are three types of compilation involved >> 1) Host compilation >> 2) Clone compilation (target CPU same as host and memory matches) >> 3) Cross compilation (target CPU is not host CPU) >> >> In the third case you have to simulate *everything* when dealing >> with both the definition and execution of defining words. It's not >> easy. You also have to extend the normal Forth compiler by at least >> two time frames. Forth cross compilers are much more complicated >> and much more subtle than they appear to be. I don't think you can draw the conclusion that "he doesn't know how to write a cross-compiler" from the above, after all he has been successfully selling them for a long time. But I do agree that the paragraph about the third case seems odd. ISTM that simulation of the target processor is only necessary if the cross compiler needs to actually execute target code - and why would you want to do that? The only reasons I can think of are: 1) to plug a software simulation into a target board because the target processor isn't available. I wouldn't regard that as part of the cross compiler itself. Or 2) to execute the CREATE part of CREATE ... DOES> words to build target data structures. This is unnecessary as the host can simply emulate the behaviour of the target system which is much simpler. Perhaps I'm missing something? >> Being on a standards committee is a thankless task and >> I, for one, am grateful for the time they spend on the task even if I >> don't always like the result. I am reminded of a statement in a Standard >> Pascal book: " ... is fed up with people who complain about the wording >> of the draft, and expect him or someone else to find a solution for them >> to criticise next time" > > If they are fed up with getting no respect, they could just spend less time braying about how they are the rulers of the world I must have missed those posts. --- this would free up about 12 hours per day --- they could put this time to good use by writing code-libraries in Forth that are useful, so that they would gradually gain respect. > > Writing code-libraries does take time --- this fact I know from experience! --- you know it too! > Yes, and probably the members of the Forth 200X committee don't have that time. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-05-16 15:00 +0000 |
| Message-ID | <591b08d5.524947545@news.eternal-september.org> |
| In reply to | #59364 |
On Tue, 16 May 2017 12:05:28 +0100, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote: >> On Tuesday, December 8, 2009 at 3:18:13 PM UTC-7, Stephen Pelc wrote: >>> There are three types of compilation involved >>> 1) Host compilation >>> 2) Clone compilation (target CPU same as host and memory matches) >>> 3) Cross compilation (target CPU is not host CPU) >>> >>> In the third case you have to simulate *everything* when dealing >>> with both the definition and execution of defining words. It's not >>> easy. You also have to extend the normal Forth compiler by at least >>> two time frames. Forth cross compilers are much more complicated >>> and much more subtle than they appear to be. I stand by this post and refer you to https://english.stackexchange.com/questions/111787/what-is-the-difference-between-simulate-and-emulate >2) to execute the CREATE part of CREATE ... DOES> words to build target >data structures. This is unnecessary as the host can simply emulate the >behaviour of the target system which is much simpler. You will hit this problem when you want the cross-compiler to execute a user-written defining word correctly. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-16 10:52 -0700 |
| Message-ID | <26e37c9d-6c2c-4375-b0c1-70ae6f023c78@googlegroups.com> |
| In reply to | #59376 |
On Tuesday, May 16, 2017 at 8:00:35 AM UTC-7, Stephen Pelc wrote: > On Tue, 16 May 2017 12:05:28 +0100, Gerry Jackson > <gerry@jackson9000.fsnet.co.uk> wrote: > > >> On Tuesday, December 8, 2009 at 3:18:13 PM UTC-7, Stephen Pelc wrote: > >>> There are three types of compilation involved > >>> 1) Host compilation > >>> 2) Clone compilation (target CPU same as host and memory matches) > >>> 3) Cross compilation (target CPU is not host CPU) > >>> > >>> In the third case you have to simulate *everything* when dealing > >>> with both the definition and execution of defining words. It's not > >>> easy. You also have to extend the normal Forth compiler by at least > >>> two time frames. Forth cross compilers are much more complicated > >>> and much more subtle than they appear to be. > > I stand by this post and refer you to > https://english.stackexchange.com/questions/111787/what-is-the-difference-between-simulate-and-emulate I don't care about the difference between a simulator and an emulator, because this is irrelevant. > >2) to execute the CREATE part of CREATE ... DOES> words to build target > >data structures. This is unnecessary as the host can simply emulate the > >behaviour of the target system which is much simpler. > > You will hit this problem when you want the cross-compiler to execute > a user-written defining word correctly. You don't have to simulate the target processor on the host computer. This is utter nonsense! I had <BUILDS DOES> in MFX and also immediate words, none of which required simulation of the target processor. I had these three modes: SYSTEM --- Code runs on the host processor and @ ! etc. access host memory. HOST --- Code runs on the host processor and @ ! etc. access target memory (the image that will be uploaded into the target processor). TARG --- Code runs on the target processor and @ ! etc. access target memory. This code does not have to be simulated on the host processor. A <BUILDS DOES> word would be written in HOST mode, but DOES> would switch to TARG mode and then ; would switch back to HOST mode. Immediate words were written in HOST mode. Run-time words were written in TARG mode. Almost nothing was written in SYSTEM mode (this was just out-of-the-box UR/Forth with the FORTH vocabulary in both CONTEXT and CURRENT). I figured out how to write a cross-compiler in 1994 while the ANS-Forth committee were busy braying about how they ruled the Forth world, but were unable to write a reference compiler for ANS-Forth to run on the 32-bit x86.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-16 19:33 +0100 |
| Message-ID | <offgfi$6rj$1@dont-email.me> |
| In reply to | #59387 |
On 5/16/2017 18:52, hughaguilar96@gmail.com wrote: > > I had these three modes: > > SYSTEM --- Code runs on the host processor and @ ! etc. access host > memory. > > HOST --- Code runs on the host processor and @ ! etc. access target > memory (the image that will be uploaded into the target processor). > > TARG --- Code runs on the target processor and @ ! etc. access target > memory. This code does not have to be simulated on the host > processor. > How does TARG work when building on system A for system A? Take a Forth for Windows as an example. If I'm running an EXE at address $40000 and want to build an EXE that will run at $40000... it's a bit of a catch 22. There are all sorts of solutions that you could suggest, but believe me, I've investigated just about all of them. Most times the facility you need doesn't exist. For example, run the cross compiler at another address (possible) and allocate memory at $40000 (nope, no such facility). The solution appears to be; build the system at some other (system allocate provided) address, and simulate things like CREATE and DOES> and so on. Or emulate, take your pick. TARG doesn't work. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-05-16 21:11 +0200 |
| Message-ID | <86h90kmxbv.fsf@molnjunk.nocrew.org> |
| In reply to | #59391 |
Alex wrote: > Hugh wrote: >> I had these three modes: >> >> SYSTEM --- Code runs on the host processor and @ ! etc. access host >> memory. >> >> HOST --- Code runs on the host processor and @ ! etc. access target >> memory (the image that will be uploaded into the target processor). >> >> TARG --- Code runs on the target processor and @ ! etc. access target >> memory. This code does not have to be simulated on the host >> processor. > > How does TARG work when building on system A for system A? Why would it matter what the target system is? I'm guessing Hugh's TARG mode works the same no matter if system A is building for system A or system B.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-16 21:25 +0100 |
| Message-ID | <offn1a$v9m$1@dont-email.me> |
| In reply to | #59400 |
On 5/16/2017 20:11, Lars Brinkhoff wrote: > Alex wrote: >> Hugh wrote: >>> I had these three modes: >>> >>> SYSTEM --- Code runs on the host processor and @ ! etc. access host >>> memory. >>> >>> HOST --- Code runs on the host processor and @ ! etc. access target >>> memory (the image that will be uploaded into the target processor). >>> >>> TARG --- Code runs on the target processor and @ ! etc. access target >>> memory. This code does not have to be simulated on the host >>> processor. >> >> How does TARG work when building on system A for system A? > > Why would it matter what the target system is? I'm guessing Hugh's TARG > mode works the same no matter if system A is building for system A or > system B. > No, it doesn't; since (for instance and only one example) statements such as building 10 VALUE X in the target and then executing the X cannot be done. Unless; you have position independent code: or system A building on an identical but separate system A'. Otherwise you're goosed. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-05-17 07:48 +0200 |
| Message-ID | <86a86cm3tm.fsf@molnjunk.nocrew.org> |
| In reply to | #59406 |
Alex wrote: >>> How does TARG work when building on system A for system A? >> >> Why would it matter what the target system is? I'm guessing Hugh's >> TARG mode works the same no matter if system A is building for system >> A or system B. > > No, it doesn't; since (for instance and only one example) statements > such as building 10 VALUE X in the target and then executing the X > cannot be done. My guess is that Hugh's compiler never executes target code, no matter if the target is the same as the host or not.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-17 10:50 -0700 |
| Message-ID | <9dc0c107-27f9-4667-a5b1-3d4841baf148@googlegroups.com> |
| In reply to | #59418 |
On Tuesday, May 16, 2017 at 10:48:22 PM UTC-7, Lars Brinkhoff wrote: > Alex wrote: > >>> How does TARG work when building on system A for system A? > >> > >> Why would it matter what the target system is? I'm guessing Hugh's > >> TARG mode works the same no matter if system A is building for system > >> A or system B. > > > > No, it doesn't; since (for instance and only one example) statements > > such as building 10 VALUE X in the target and then executing the X > > cannot be done. > > My guess is that Hugh's compiler never executes target code, no matter > if the target is the same as the host or not. There is no need to execute target code at compile-time. It is irrelevant whether the target processor is the same as the host processor or different. As I said before, immediate words are defined in HOST mode. Defining words, that use <BUILDS DOES> are also defined in HOST mode. <BUILDS switches to TARG mode and semicolon switches back to HOST mode, so the code after <BUILDS is actually code that will run on the target machine. Words written in TARG mode are the run-time application code. Every TARG definition actually meta-compiles a HOST definition automatically --- this is a short colon word that is immediate and, when executed, will generate target code to call the target word --- it has the same name as the TARG word but it is in a different vocabulary so there is no confusion between the two same-name words. I did have a simulator, but this was not used for compiling. It was used for testing application code. Throughout most of the project, the MiniForth didn't physically exist, so all of the code had to be tested in simulation. When we did finally have a MiniForth board available, there was already substantial amounts of code written, and all of that code ran flawlessly the first time that it was tried. If I had a board available, I wouldn't necessarily write a simulator, but I would just test the application code on the actual board. The way that I wrote my simulator, as to have the assembler not only generate target code but also generate Forth code that ran on the host machine and simulated the target code. I don't think it is a good idea to decode opcodes in a simulator, because this is complicated and slow. This is only necessary if you don't have the source-code, which is only true if you are reverse-engineering somebody else's program. We had all the source-code ourselves though, because we wrote it ourselves, so most of the work could be done at compile-time rather than run-time --- this makes the simulated program run quite fast.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-17 19:27 +0100 |
| Message-ID | <ofi4fv$ss5$1@dont-email.me> |
| In reply to | #59440 |
On 5/17/2017 18:50, hughaguilar96@gmail.com wrote: > On Tuesday, May 16, 2017 at 10:48:22 PM UTC-7, Lars Brinkhoff wrote: >> Alex wrote: >>>>> How does TARG work when building on system A for system A? >>>> Why would it matter what the target system is? I'm guessing >>>> Hugh's TARG mode works the same no matter if system A is >>>> building for system A or system B. >>> No, it doesn't; since (for instance and only one example) >>> statements such as building 10 VALUE X in the target and then >>> executing the X cannot be done. >> My guess is that Hugh's compiler never executes target code, no >> matter if the target is the same as the host or not. > There is no need to execute target code at compile-time. It is > irrelevant whether the target processor is the same as the host > processor or different. > > As I said before, immediate words are defined in HOST mode. Defining > words, that use <BUILDS DOES> are also defined in HOST mode. <BUILDS > switches to TARG mode and semicolon switches back to HOST mode, so > the code after <BUILDS is actually code that will run on the target > machine. Words written in TARG mode are the run-time application > code. Every TARG definition actually meta-compiles a HOST definition > automatically --- this is a short colon word that is immediate and, > when executed, will generate target code to call the target word --- > it has the same name as the TARG word but it is in a different > vocabulary so there is no confusion between the two same-name words. Let's try a real example. Here's the code I want to meta-compile. : dupdup dup dup ; : another dupdup ; That's pretty straightforward. DUP and DUPDUP are immediate words in TARG that compile a call. These words define stuff on the target (and also put DUPDUP and ANOTHER into the TARG dictionary). But nothing is executed there. variable x 10 x ! Now I require to execute 10 X ! *as though it is running on the target system*. X is in TARG (our HOST VARIABLE definition did that) and so is !, but I can't execute them; I have to simulate (or emulate) them on the host system. Other examples: : constant create , does> @ ; 10 constant $A Here we need to execute the CREATE part of the definition *as though it is running on the target system*. $A value dollarA requires us to run the DOES> part of CONSTANT *as though it is running on the target system*. They require simulated (or emulated, take your pick). -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-17 11:42 -0700 |
| Message-ID | <5f546e0c-268e-405f-a564-2f90264cf1a8@googlegroups.com> |
| In reply to | #59442 |
On Wednesday, May 17, 2017 at 11:27:23 AM UTC-7, Alex wrote:
> : constant create , does> @ ;
> 10 constant $A
>
> Here we need to execute the CREATE part of the definition *as though it
> is running on the target system*.
This is not how CONSTANT is written. I'll change the name to CONST though and show you how this would be written:
HOST
: CONST ( val -- )
<BUILDS , DOES> @ ;
CONST is defined in HOST mode not TARG mode --- the <BUILDS part is not running on the target system --- the <BUILDS part is running on the host system and only the DOES> code (the @ code) is target code.
> $A value dollarA
>
> requires us to run the DOES> part of CONSTANT *as though it is running
> on the target system*.
>
> They require simulated (or emulated, take your pick).
You really don't know anything about Forth cross-compilation.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-17 20:22 +0100 |
| Message-ID | <ofi7mo$9c0$1@dont-email.me> |
| In reply to | #59444 |
On 5/17/2017 19:42, hughaguilar96@gmail.com wrote: > On Wednesday, May 17, 2017 at 11:27:23 AM UTC-7, Alex wrote: >> : constant create , does> @ ; 10 constant $A >> >> Here we need to execute the CREATE part of the definition *as >> though it is running on the target system*. > > This is not how CONSTANT is written. I'll change the name to CONST > though and show you how this would be written: > > HOST > > : CONST ( val -- ) <BUILDS , DOES> @ ; > > CONST is defined in HOST mode not TARG mode --- the <BUILDS part is > not running on the target system --- the <BUILDS part is running on > the host system and only the DOES> code (the @ code) is target code. Call it what you will. This; : CONST ( val -- ) <BUILDS , DOES> @ ; 10 const $A still requires building (or creating; the name is neither here nor there) on the target (that, after all, is the whole point of the definition). The <BUILDS part (in this case , ) must be emulated on the host to build the constant on the target. Referring to $A outside of definition requires doing the DOES> part, so the @ must be emulated too. (Unless you don't allow that.) Or how about meta-compiling this? 20 cells allot here 0 , What does CELLS ALLOT or HERE or , do? Where are they defined? > >> $A value dollarA >> >> requires us to run the DOES> part of CONSTANT *as though it is >> running on the target system*. >> >> They require simulated (or emulated, take your pick). > > You really don't know anything about Forth cross-compilation. > You do? -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-17 12:57 -0700 |
| Message-ID | <8949cf8e-9805-4817-9262-773647939a5c@googlegroups.com> |
| In reply to | #59446 |
On Wednesday, May 17, 2017 at 12:22:11 PM UTC-7, Alex wrote: > On 5/17/2017 19:42, hughaguilar96@gmail.com wrote: > > On Wednesday, May 17, 2017 at 11:27:23 AM UTC-7, Alex wrote: > >> : constant create , does> @ ; 10 constant $A > >> > >> Here we need to execute the CREATE part of the definition *as > >> though it is running on the target system*. > > > > This is not how CONSTANT is written. I'll change the name to CONST > > though and show you how this would be written: > > > > HOST > > > > : CONST ( val -- ) <BUILDS , DOES> @ ; > > > > CONST is defined in HOST mode not TARG mode --- the <BUILDS part is > > not running on the target system --- the <BUILDS part is running on > > the host system and only the DOES> code (the @ code) is target code. > > Call it what you will. This; > > : CONST ( val -- ) <BUILDS , DOES> @ ; > > 10 const $A > > still requires building (or creating; the name is neither here nor > there) on the target (that, after all, is the whole point of the > definition). The <BUILDS part (in this case , ) must be emulated on the > host to build the constant on the target. This is what I said previously: On Tuesday, May 16, 2017 at 10:52:59 AM UTC-7, hughag...@gmail.com wrote: > I had these three modes: > > SYSTEM --- Code runs on the host processor and @ ! etc. access host memory. > > HOST --- Code runs on the host processor and @ ! etc. access target memory (the image that will be uploaded into the target processor). > > TARG --- Code runs on the target processor and @ ! etc. access target memory. This code does not have to be simulated on the host processor. The @ above is a HOST word which means that it runs on the host processor and accesses target memory (the image that will be uploaded into the target processor). I am not simulating or emulating target code on the host machine --- this is never needed. > Referring to $A outside of definition requires doing the DOES> part, so > the @ must be emulated too. (Unless you don't allow that.) I only allow referring to target code inside of target colon words --- this includes $A above --- I never simulate or emulate target code on the host machine. > Or how about meta-compiling this? > > 20 cells allot here 0 , > > What does CELLS ALLOT or HERE or , do? Where are they defined? That is not meta-compiling --- that is just ordinary Forth code being executed in interpretation mode --- assuming that we are in TARG mode, all of those words are HOST words and hence they access target memory (the image that will be uploaded into the target processor) > > You really don't know anything about Forth cross-compilation. > > You do? Yes --- I wrote MFX in 1994/1995 when I was employed at Testra --- I figured out Forth cross-compilation at that time. I had previously written (in 1989 or 1990) a Forth cross-compiler for the 65c02 --- it was somewhat awkward to use because I had not fully figured out Forth cross-compilation at that time --- it did work though (I wrote the symbolic math program using it, which could do derivatives). The 65c02 cross-compiler was awkward because I hadn't figured out HOST and TARG modes yet. All of my defining words had distinct names if they were to define target words --- for example: |: |CREATE etc. --- still though, I wasn't simulating the 65c02 on the MS-DOS computer, so even then I knew more about Forth cross-compilation than Stephen Pelc knows today.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-05-17 13:01 -0700 |
| Message-ID | <d74b7a50-843c-45b4-8b79-0a7b999e7488@googlegroups.com> |
| In reply to | #59446 |
On Wednesday, May 17, 2017 at 12:22:11 PM UTC-7, Alex wrote: > On 5/17/2017 19:42, hughaguilar96@gmail.com wrote: > > On Wednesday, May 17, 2017 at 11:27:23 AM UTC-7, Alex wrote: > >> : constant create , does> @ ; 10 constant $A > >> > >> Here we need to execute the CREATE part of the definition *as > >> though it is running on the target system*. > > > > This is not how CONSTANT is written. I'll change the name to CONST > > though and show you how this would be written: > > > > HOST > > > > : CONST ( val -- ) <BUILDS , DOES> @ ; > > > > CONST is defined in HOST mode not TARG mode --- the <BUILDS part is > > not running on the target system --- the <BUILDS part is running on > > the host system and only the DOES> code (the @ code) is target code. > > Call it what you will. This; > > : CONST ( val -- ) <BUILDS , DOES> @ ; > > 10 const $A > > still requires building (or creating; the name is neither here nor > there) on the target (that, after all, is the whole point of the > definition). The <BUILDS part (in this case , ) must be emulated on the > host to build the constant on the target. This is what I said previously: On Tuesday, May 16, 2017 at 10:52:59 AM UTC-7, hughag...@gmail.com wrote: > I had these three modes: > > SYSTEM --- Code runs on the host processor and @ ! etc. access host memory. > > HOST --- Code runs on the host processor and @ ! etc. access target memory (the image that will be uploaded into the target processor). > > TARG --- Code runs on the target processor and @ ! etc. access target memory. This code does not have to be simulated on the host processor. The comma above (in the <BUILDS part) is a HOST word which means that it runs on the host processor and accesses target memory (the image that will be uploaded into the target processor). Note: I posted this and then deleted it because there was a typo --- I had previously said: "the @ above" --- this post is correct though, as I meant: "the comma above." I am not simulating or emulating target code on the host machine --- this is never needed. > Referring to $A outside of definition requires doing the DOES> part, so > the @ must be emulated too. (Unless you don't allow that.) I only allow referring to target code inside of target colon words --- this includes $A above --- I never simulate or emulate target code on the host machine. > Or how about meta-compiling this? > > 20 cells allot here 0 , > > What does CELLS ALLOT or HERE or , do? Where are they defined? That is not meta-compiling --- that is just ordinary Forth code being executed in interpretation mode --- assuming that we are in TARG mode, all of those words are HOST words and hence they access target memory (the image that will be uploaded into the target processor) > > You really don't know anything about Forth cross-compilation. > > You do? Yes --- I wrote MFX in 1994/1995 when I was employed at Testra --- I figured out Forth cross-compilation at that time. I had previously written (in 1989 or 1990) a Forth cross-compiler for the 65c02 --- it was somewhat awkward to use because I had not fully figured out Forth cross-compilation at that time --- it did work though (I wrote the symbolic math program using it, which could do derivatives). The 65c02 cross-compiler was awkward because I hadn't figured out HOST and TARG modes yet. All of my defining words had distinct names if they were to define target words --- for example: |: |CREATE etc. --- still though, I wasn't simulating the 65c02 on the MS-DOS computer, so even then I knew more about Forth cross-compilation than Stephen Pelc knows today.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-18 13:01 +0100 |
| Message-ID | <ofk296$n3a$1@dont-email.me> |
| In reply to | #59449 |
On 5/17/2017 21:01, hughaguilar96@gmail.com wrote: > On Wednesday, May 17, 2017 at 12:22:11 PM UTC-7, Alex wrote: >> On 5/17/2017 19:42, hughaguilar96@gmail.com wrote: > > This is what I said previously: > > On Tuesday, May 16, 2017 at 10:52:59 AM UTC-7, hughag...@gmail.com > wrote: >> I had these three modes: >> >> SYSTEM --- Code runs on the host processor and @ ! etc. access host >> memory. >> >> HOST --- Code runs on the host processor and @ ! etc. access target >> memory (the image that will be uploaded into the target >> processor). >> >> TARG --- Code runs on the target processor and @ ! etc. access >> target memory. This code does not have to be simulated on the host >> processor. > > The comma above (in the <BUILDS part) is a HOST word which means that > it runs on the host processor and accesses target memory (the image > that will be uploaded into the target processor). > > Note: I posted this and then deleted it because there was a typo --- > I had previously said: "the @ above" --- this post is correct though, > as I meant: "the comma above." > > I am not simulating or emulating target code on the host machine --- > this is never needed. I'd be interested to understand how to metacompile this using your technique. : msgtype s" this is a message" type ; Specifically, how do you handle parsing words? > >> Referring to $A outside of definition requires doing the DOES> >> part, so the @ must be emulated too. (Unless you don't allow >> that.) > > I only allow referring to target code inside of target colon words > --- this includes $A above --- I never simulate or emulate target > code on the host machine. > >> Or how about meta-compiling this? >> >> 20 cells allot here 0 , >> >> What does CELLS ALLOT or HERE or , do? Where are they defined? > > That is not meta-compiling --- that is just ordinary Forth code being > executed in interpretation mode --- assuming that we are in TARG > mode, all of those words are HOST words and hence they access target > memory (the image that will be uploaded into the target processor) I'm mystified as to how you might reserve data space in the target in that case, since there appears to be no way of doing it. 0 , 0 , -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-05-18 14:09 +0200 |
| Message-ID | <868tlujrhn.fsf@molnjunk.nocrew.org> |
| In reply to | #59489 |
Alex wrote: >>> What does CELLS ALLOT or HERE or , do? Where are they defined? >> >> That is not meta-compiling --- that is just ordinary Forth code being >> executed in interpretation mode --- assuming that we are in TARG >> mode, all of those words are HOST words and hence they access target >> memory > > I'm mystified as to how you might reserve data space in the target in > that case, since there appears to be no way of doing it. > > 0 , 0 , I'll interject here, because I think I understand what Hugh means. Most likely, these HOST words refer to the target image. CELLS multiplies with the cell size of the target. ALLOT allocates space in the target image. HERE return the data pointer into the target image. etc The confusion may be that the MFX "HOST" mode consists of words that execute in the host Forth, but operate on the target image. Whereas most everyone else thinks that "host" refers to the Forth the compiler is running in.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-05-18 07:00 -0700 |
| Message-ID | <8463dccb-0139-46ae-8afb-16f279ef8862@googlegroups.com> |
| In reply to | #59490 |
joi, 18 mai 2017, 15:09:57 UTC+3, Lars Brinkhoff a scris: > Alex wrote: > >>> What does CELLS ALLOT or HERE or , do? Where are they defined? > >> > >> That is not meta-compiling --- that is just ordinary Forth code being > >> executed in interpretation mode --- assuming that we are in TARG > >> mode, all of those words are HOST words and hence they access target > >> memory > > > > I'm mystified as to how you might reserve data space in the target in > > that case, since there appears to be no way of doing it. > > > > 0 , 0 , > > I'll interject here, because I think I understand what Hugh means. Most > likely, these HOST words refer to the target image. > > CELLS multiplies with the cell size of the target. > ALLOT allocates space in the target image. > HERE return the data pointer into the target image. > etc > > The confusion may be that the MFX "HOST" mode consists of words that > execute in the host Forth, but operate on the target image. Whereas > most everyone else thinks that "host" refers to the Forth the compiler > is running in. My interest these days is to have a forth embedded in my applications as a simple scripting language. The idea is that the very low level and critical stuff is done in C, and the user application will be loaded from a file at startup. Complicated things will be mostly done in C and compiled in the kernel. This way I can script the application in a traditional forth way. I was investigating other scripting languages for this job, like lua or tcl (jim-tcl) but they are just too big. My forth system, which is quite a good one takes only 16K of flash itself and some K ram. It's true, it compiles in ram also, and everything in the user applications (code, dictionary and variable data) goes to ram too. But it's not intended for small chips. I suppose a 32K ram chip is a minimum practical thing. I don't have a real application done yet, but I already miss some things. For example a few days ago I implemented a BREAK for the FOR NEXT loops. And I'm investigating extending it to all BEGIN loops also. I also need a way to compile unnamed strings in an array of strings. Quite inefficient to name all the strings so that I can compile their addresses in a table... And finally I really want to make a host pre-processor for the target sources, something in a way that colorforth or AHA works. They work integrated with n editor, I know, but I'm ok with just a post processor for normal sources. In the target I would have an almost compiled form, with the real sources interparsed with control structures (the dictionary) directly and pre-parsed literals, etc. The compilation will be very fast this way, mostly copying the data in ram. Only that I have time for all my plans ... :)
[toc] | [prev] | [next] | [standalone]
| From | gavino himself <jackvanc3@gmail.com> |
|---|---|
| Date | 2017-05-18 22:15 -0700 |
| Message-ID | <e7a9b33e-ba18-4721-9632-b87306511dd7@googlegroups.com> |
| In reply to | #59496 |
On Thursday, May 18, 2017 at 10:00:59 AM UTC-4, Raimond Dragomir wrote: > joi, 18 mai 2017, 15:09:57 UTC+3, Lars Brinkhoff a scris: > > Alex wrote: > > >>> What does CELLS ALLOT or HERE or , do? Where are they defined? > > >> > > >> That is not meta-compiling --- that is just ordinary Forth code being > > >> executed in interpretation mode --- assuming that we are in TARG > > >> mode, all of those words are HOST words and hence they access target > > >> memory > > > > > > I'm mystified as to how you might reserve data space in the target in > > > that case, since there appears to be no way of doing it. > > > > > > 0 , 0 , > > > > I'll interject here, because I think I understand what Hugh means. Most > > likely, these HOST words refer to the target image. > > > > CELLS multiplies with the cell size of the target. > > ALLOT allocates space in the target image. > > HERE return the data pointer into the target image. > > etc > > > > The confusion may be that the MFX "HOST" mode consists of words that > > execute in the host Forth, but operate on the target image. Whereas > > most everyone else thinks that "host" refers to the Forth the compiler > > is running in. > > My interest these days is to have a forth embedded in my applications as > a simple scripting language. The idea is that the very low level and critical > stuff is done in C, and the user application will be loaded from a file > at startup. > Complicated things will be mostly done in C and compiled in the kernel. > This way I can script the application in a traditional forth way. > > I was investigating other scripting languages for this job, like lua or > tcl (jim-tcl) but they are just too big. My forth system, which is quite > a good one takes only 16K of flash itself and some K ram. It's true, it > compiles in ram also, and everything in the user applications (code, > dictionary and variable data) goes to ram too. But it's not intended > for small chips. I suppose a 32K ram chip is a minimum practical thing. > > I don't have a real application done yet, but I already miss some things. > For example a few days ago I implemented a BREAK for the FOR NEXT loops. > And I'm investigating extending it to all BEGIN loops also. I also need > a way to compile unnamed strings in an array of strings. Quite inefficient > to name all the strings so that I can compile their addresses in a table... > > And finally I really want to make a host pre-processor for the target > sources, something in a way that colorforth or AHA works. They work > integrated with n editor, I know, but I'm ok with just a post processor for > normal sources. In the target I would have an almost compiled form, > with the real sources interparsed with control structures (the dictionary) > directly and pre-parsed literals, etc. The compilation will be very fast > this way, mostly copying the data in ram. > > Only that I have time for all my plans ... :) great D&D last name!
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-05-17 22:21 -0700 |
| Message-ID | <82d4b16b-1520-4976-ad55-b4a26fb3e4a2@googlegroups.com> |
| In reply to | #59442 |
> variable x > 10 x ! Normally, in a cross-compiled application this should be impossible. The application is first compiled, the run. I can ask you: WHEN the 10 x ! is executed? A solution may exist: to emulate/simulate the behavior of the host forth (or just a "scripting" forth system - the traditional aproach) one would implement the following strategy: compile all this code which is normally interpreted in a hidden definition which is run just at the start (like compiling a hidden main() in C) and install this main to run at the boot. This way the interpreted code like 10 x ! will get executed at the target at its time. > : constant create , does> @ ; > 10 constant $A > Defining words in cross-compilers are nothing new. The host should have a variant of the target word that works on the target memory image in the host. And that's not that complicated. Here is an example: At some point, the target should execute a @ from its memory. Lets suppose this is part of a building word that gets executed on the host. What the host should do? Just execute the HOST @ but on the target image memory (which is on the host). This @ is just the host normal fetch. This is EMULATION. There is another possibility of course: the host can have a special @ which simulates every target instructions in the target @ word, for example, in an ARM target to load some Rn with the target address, then simulate a LDR instruction in the TOS simulated registers... Thats SIMULATION. Why would you do that? Remember, at this time we are not compiling anything for the target, just execute some code in host to obtain the desired result. And for the compiling part, you don't need simulation either. If you want to compile some very optimized code, you should know in the first place how the target works at the instruction/register level. Don't need to simulate it to see what happens.
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-05-18 08:04 +0200 |
| Message-ID | <86h90ilmyx.fsf@molnjunk.nocrew.org> |
| In reply to | #59458 |
Raimond Dragomir wrote: >> variable x >> 10 x ! > > Normally, in a cross-compiled application this should be impossible. > The application is first compiled, the run. Obviously, there are two different philosophies regarding this. Some don't allow target words to execute at compile time. Some do. My cross compiler don't, and I don't miss that feature. But if I had paying customers that requested this feature, I wouldn't be inclined to tell them "don't do that".
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-05-17 23:10 -0700 |
| Message-ID | <90327c68-b74e-4705-8829-462ddf281df3@googlegroups.com> |
| In reply to | #59459 |
joi, 18 mai 2017, 09:04:40 UTC+3, Lars Brinkhoff a scris: > Raimond Dragomir wrote: > >> variable x > >> 10 x ! > > > > Normally, in a cross-compiled application this should be impossible. > > The application is first compiled, the run. > > Obviously, there are two different philosophies regarding this. Some > don't allow target words to execute at compile time. Some do. > > My cross compiler don't, and I don't miss that feature. But if I had > paying customers that requested this feature, I wouldn't be inclined to > tell them "don't do that". I agree. But the question here is: how you would do that if you were to do that?
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web