Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #40779 > unrolled thread
| Started by | rickman <gnuarm@gmail.com> |
|---|---|
| First post | 2015-07-24 12:19 -0400 |
| Last post | 2015-11-30 02:55 -0500 |
| Articles | 20 on this page of 178 — 30 participants |
Back to article view | Back to comp.lang.forth
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-24 12:19 -0400
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-24 10:15 -0700
Re: Which scripting for embedded automation? foxaudioresearch@gmail.com - 2015-07-24 10:32 -0700
Re: Which scripting for embedded automation? "WJ" <w_a_x_man@yahoo.com> - 2015-07-24 23:06 +0000
Re: Which scripting for embedded automation? Don Y <this@is.not.me.com> - 2015-07-24 17:00 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-24 20:52 -0400
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-07-25 01:28 -0700
Re: Which scripting for embedded automation? josv@planet.nl - 2015-07-25 07:15 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-25 10:19 -0400
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-25 10:26 -0700
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-07-27 00:42 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 22:07 -1000
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-07-27 01:44 -0700
Re: Which scripting for embedded automation? foxaudioresearch@gmail.com - 2015-07-27 05:57 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 14:02 +0100
Re: Which scripting for embedded automation? foxaudioresearch@gmail.com - 2015-07-27 08:41 -0700
Re: Which scripting for embedded automation? Julian Fondren <julian.fondren@gmail.com> - 2015-07-27 08:36 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-25 10:20 -0400
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-26 04:01 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-26 18:53 +0100
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-26 11:18 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-26 20:25 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 07:36 +0000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-27 01:12 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 10:02 +0000
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 13:44 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 15:15 +0000
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-27 04:52 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 14:01 +0100
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-27 06:16 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 14:33 +0100
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 14:34 +0100
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-27 10:47 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 08:12 -1000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-27 11:24 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 08:41 -1000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-27 12:49 -0700
Re: Which scripting for embedded automation? Julian Fondren <julian.fondren@gmail.com> - 2015-07-27 14:38 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 12:02 -1000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-27 11:16 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 20:11 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 13:50 +0000
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-27 08:56 -0700
Re: Which scripting for embedded automation? Doug Hoffman <glidedog@gmail.com> - 2015-08-09 09:32 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-08-09 16:30 -1000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-09 22:56 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-10 08:53 +0000
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-08-10 08:28 -1000
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-11 15:17 +0000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-10 14:14 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-10 16:29 -0700
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-08-11 01:44 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-11 11:09 +0100
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-08-11 11:03 -0400
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-08-11 08:08 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-11 17:21 +0100
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-11 22:05 -0700
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-08-12 05:50 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-12 18:02 +0100
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-08-12 05:51 -0700
Re: Which scripting for embedded automation? mhx@iae.nl - 2015-08-12 10:18 -0700
Re: Which scripting for embedded automation? mhx@iae.nl - 2015-08-13 10:37 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-14 12:13 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-14 21:30 +0200
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-14 13:05 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-15 16:57 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-16 00:12 +0200
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-16 09:44 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-17 00:06 +0200
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-18 09:13 +0000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-18 09:02 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-19 00:02 +0100
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-08-18 14:20 -1000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-19 03:12 +0200
Re: Which scripting for embedded automation? mhx@iae.nl - 2015-08-14 13:09 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-14 13:43 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-15 17:10 +0000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-12 21:16 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-12 21:31 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-12 21:39 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-13 13:43 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-13 10:55 +0100
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-14 12:06 -0700
Re: Which scripting for embedded automation? Alex McDonald <blog@rivadpm.com> - 2015-08-14 18:33 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-15 19:33 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-23 16:59 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-13 15:52 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-10 08:43 +0000
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-27 06:04 -0700
Re: Which scripting for embedded automation? Julian Fondren <ayrnieu@gmail.com> - 2015-07-26 13:49 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 14:56 -1000
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-26 14:20 -0400
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-26 17:29 -0700
Re: Which scripting for embedded automation? "WJ" <w_a_x_man@yahoo.com> - 2015-08-10 22:52 +0000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-26 17:11 -0400
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-26 22:38 +0100
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 15:07 -1000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-26 21:26 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 16:49 -1000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 01:30 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 22:19 -1000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 19:31 -0400
Re: Which scripting for embedded automation? Julian Fondren <julian.fondren@gmail.com> - 2015-07-27 16:44 -0700
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 20:32 -0400
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-28 18:57 +0200
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 22:03 -1000
Re: Which scripting for embedded automation? stephen@mpeforth.com (Stephen Pelc) - 2015-07-27 09:12 +0000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-27 11:02 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-27 14:14 -0400
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 20:17 +0100
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 19:33 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 22:05 -1000
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-28 12:47 +0100
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-28 23:52 -0400
Re: Which scripting for embedded automation? awegel@arcor.de (Alexander Wegel) - 2015-07-29 12:24 +0200
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 19:32 -0400
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-28 19:22 +0200
Re: Which scripting for embedded automation? Walter Banks <walter@bytecraft.com> - 2015-07-28 15:46 -0400
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-28 23:47 -0400
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 07:22 +0000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-29 00:48 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 10:15 +0000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-31 11:34 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-04 09:21 +0000
Re: Which scripting for embedded automation? Walter Banks <walter@bytecraft.com> - 2015-07-29 13:27 -0400
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-29 18:53 -0400
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-30 12:40 +0000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-30 22:15 -0400
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-30 21:51 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-31 10:32 +0000
Re: Which scripting for embedded automation? David Thompson <dave.thompson2@verizon.net> - 2015-08-16 02:31 -0400
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-16 09:53 +0000
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-29 17:50 +0200
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-30 13:14 +0000
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 10:28 +0000
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-29 18:24 +0200
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 17:09 +0000
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-30 02:01 +0200
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-29 17:58 -0700
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-30 21:26 -0400
Re: Which scripting for embedded automation? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-31 00:06 -0700
Re: Which scripting for embedded automation? Hannu Vuolasaho <vuokkosetae@gmail.com> - 2015-07-31 13:35 +0300
Re: Which scripting for embedded automation? Mikael Nordman <oh2aun@gmail.com> - 2015-08-01 01:12 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-31 15:05 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-30 12:03 +0000
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-02 16:29 +0100
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-02 16:58 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 15:43 +0000
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-02 18:24 +0100
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-02 20:09 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-03 12:07 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-03 22:22 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 09:47 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-04 14:59 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 14:13 +0000
Re: Which scripting for embedded automation? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-02 20:29 +0000
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-05 12:02 +0100
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-05 15:57 +0100
Re: Which scripting for embedded automation? Walter Banks <walter@bytecraft.com> - 2015-07-28 15:32 -0400
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-29 16:35 -0700
Re: Which scripting for embedded automation? Walter Banks <walter@bytecraft.com> - 2015-08-01 22:50 -0400
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-01 20:06 -0700
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-26 22:56 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 07:32 +0000
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-27 01:46 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 07:54 +0000
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-27 22:42 -0700
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-28 02:38 -0700
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-28 05:28 -0700
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-28 05:41 -0700
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-28 05:49 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-28 14:14 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-28 07:38 -1000
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-28 13:37 -0700
Re: Which scripting for embedded automation? "WJ" <w_a_x_man@yahoo.com> - 2015-11-28 18:06 +0000
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-11-29 02:45 -0500
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-11-29 23:02 -0800
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-11-30 02:55 -0500
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-07-26 22:19 -1000 |
| Message-ID | <36adnY7PUqw6dCjInZ2dnUU7-KednZ2d@supernews.com> |
| In reply to | #40816 |
On 7/26/15 7:30 PM, Rod Pemberton wrote: > On Sun, 26 Jul 2015 22:49:50 -0400, Elizabeth D. Rather > <erather@forth.com> wrote: >> On 7/26/15 3:26 PM, Rod Pemberton wrote: >>> On Sun, 26 Jul 2015 21:07:21 -0400, Elizabeth D. Rather >>> <erather@forth.com> wrote: >>>> On 7/26/15 11:11 AM, Rod Pemberton wrote: >>>>> On Sun, 26 Jul 2015 13:53:14 -0400, Alex McDonald <blog@rivadpm.com> >>>>> wrote: >>>>>> on 26/07/2015 12:01:26, glidedog wrote: > >>>>>>> Mark's lament is understandable. Forth doesn't even have a built-in >>>>>>> cell-sized-element array wordset. >>>>>> >>>>>> The definition of a 1 dimensional array is trivial; perhaps that's >>>>>> why. >>>>>> >>>>>> : 1dim create cells allot does> swap cells + ; >>>>>> >>>>>> 10 1dim myarray >>>>>> 10 0 myarray ! >>>>>> 20 1 myarray ! >>>>>> 0 myarray @ 1 myarray @ + . >>>>>> >>>>> >>>>> Okay, don't blow a fuse for me butting in without reading most of >>>>> this, >>>>> but ... >>>>> >>>>> How is that on factoring? >>>>> >>>>> Shouldn't there be a separate word to do array indexing so the >>>>> indexing >>>>> functionality can be re-used? Then, it would be factored, correct? >>>>> ... >>>>> >>>>> E.g., >>>>> >>>>> : [] swap cells + ; >>>>> : 1dim create cells allot ; >>>>> >>>>> 10 1dim myarray >>>>> 10 0 myarray [] ! >>>>> 20 1 myarray [] ! >>>>> 0 myarray [] @ 1 myarray [] @ + . >>>> >>>> That is, in fact, very poor factoring, because it makes an extra >>>> definition that you don't need. As Alex points out, multiple arrays >>>> defined by 1dim will all share the same indexing code, so factoring >>>> that >>>> out introduces an extra call. >>> >>> If the "extra" call is such an issue, what is wrong with this? >>> >>> : [] swap cells + ; >>> : 1dim create cells allot does> [] ; >>> >>> 10 1dim myarray >>> 10 0 myarray ! >>> 20 1 myarray ! >>> 0 myarray @ 1 myarray @ + . >>> >>> >>> That preserves the functionality as a separate word and re-uses the same >>> code in the does> . >>> >>> BTW, I see the "extra" call as being no different that the use of ! or >>> @ above. I.e., they're extraneous too and can be hidden within long, >>> non-factored definitions. >> >> Offering the functionality as a separate word is advantageous >> when it is a common sequence that is being reused. > > Sure. [] can be used with any address to perform indexing interactively, > just like @ and ! can be used. > >> Such functions are worth factoring and being given a clear name. > > Exactly. [] is just like @ and ! in that regard. > >> The longer the phrase, the fewer instances it takes to justify >> being factored. This particular phrase is very short, > > Yes. It's very short just like @ and ! are very short. > They were factored. Are you saying they shouldn't have been? Yes. The difference is that @ and ! are ubiquitous, whereas this particular, very specific indexing sequence would normally be incorporated in the DOES> portion of a defining word, and never used independently. >> quite unlikely to be repeated beyond the use here, > > It can be used from the interpreted state with any address. > I.e., it's a generic addressing operation like @ ! +! TOGGLE > etc. So, why exactly would it be unlikely to be used? ... It wouldn't be used independent of the array defining word because there is no need for it except in that context. It has little value as an independent facility. >> and the >> name [] conveys absolutely nothing resembling its function >> (square brackets in Forth suggest immediacy). > > 1) Sure it does. [] are used as array indexing in most languages. > 2) If [] "suggests immediacy" in Forth, then you're implying Forth > *does* have some basic syntax rules ... It has mnemonic value, consistent with [ ... ], ['], [CHAR], etc. > I know you attempted to point out why you shouldn't do things > this way, but from my perspective (above) it seems you only > confirmed why you should. > > Isn't this really the fact that you hate attempts to make Forth > appear more C like and function that way too? I.e., coding in > Forth has a certain character and you'd like it to remain that way. > If so, doesn't that really go against the entire concept of Forth > being and adaptable and structureless or formless language? I.e., > you're attempting to impose a form on it or your form. Aren't you? I don't see a value in making a horse look more like a cow just to prove a point. Each is useful within its domain. > C captures the essence of all generic microprocessors. Forth, > instead, usually attempts to impose it's own virtual machine. > So, in that regard, it would actually suit Forth to be more > C like. Even Hugh is having difficulty adding functionality to > Forth without recreating C functionality. He's done so twice > with projects even though he riles against C-like memory allocation > for Forth. Anton doesn't even bother attempting to hide from C. People try to make Forth look like other languages either because the other is more familiar to them or to prove a point. I'm primarily interested in whether a potential functionality is directly applicable to the project at hand, and what value it adds to the solution. 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 | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-07-27 19:31 -0400 |
| Message-ID | <op.x2ggymnoyfako5@localhost> |
| In reply to | #40825 |
On Mon, 27 Jul 2015 04:19:50 -0400, Elizabeth D. Rather <erather@forth.com> wrote: > On 7/26/15 7:30 PM, Rod Pemberton wrote: >> On Sun, 26 Jul 2015 22:49:50 -0400, Elizabeth D. Rather >> <erather@forth.com> wrote: >>> The longer the phrase, the fewer instances it takes to justify >>> being factored. This particular phrase is very short, >> >> Yes. It's very short just like @ and ! are very short. >> They were factored. Are you saying they shouldn't have been? > > Yes. The difference is that @ and ! are ubiquitous, whereas this > particular, very specific indexing sequence would normally be > incorporated in the DOES> portion of a defining word, and never used > independently. So, it would never be used with PAD or to display a BIOS string which has no defining word for it's address? ... The user can enter an address directly on the stack, then use [] to index whatever is there. The big problem with Forth is there is no ability to know the size of the data the pointer points to. I.e., you'd need [] for cell size data and c[] for character sized data. >>> quite unlikely to be repeated beyond the use here, >> >> It can be used from the interpreted state with any address. >> I.e., it's a generic addressing operation like @ ! +! TOGGLE >> etc. So, why exactly would it be unlikely to be used? ... > > It wouldn't be used independent of the array defining word because > there is no need for it except in that context. It has little value > as an independent facility. C is a pointer based language where every object in C maps onto an array. It uses this functionality all the time for everything. The ANS Forth standard requires the same inherent layout. And, Forth deals with raw addresses too. I.e., I think you're strongly down-playing the usefulness here. Rod Pemberton -- Scientists now say we'll experience a mini-ice in 2030. So, I guess we need more global warming today ...
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2015-07-27 16:44 -0700 |
| Message-ID | <8ab63cb4-00f9-496e-ac86-68ab37c4c653@googlegroups.com> |
| In reply to | #40856 |
On Monday, July 27, 2015 at 6:31:14 PM UTC-5, Rod Pemberton wrote:
> The big problem with Forth is there is no ability to know
> the size of the data the pointer points to. I.e., you'd need []
> for cell size data and c[] for character sized data.
The big problem with C is that you have to know the size of the data
that a pointer points to. You can't just say [] and get it. You
have to say what size it is when you get it:
void example (float *fs) {
and you have to say what size variable you're fetching it to:
float c = *fs;
Just look at that last example again, next to the Forth:
float c = *fs;
fs f@
Isn't it just awful, that one of these examples requires you to know
*so* much more than the other does? Why can't that one language be
as smart, on your behalf, as the other?
-- Julian
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-07-27 20:32 -0400 |
| Message-ID | <op.x2gjscg2yfako5@localhost> |
| In reply to | #40859 |
On Mon, 27 Jul 2015 19:44:26 -0400, Julian Fondren <julian.fondren@gmail.com> wrote:
> On Monday, July 27, 2015 at 6:31:14 PM UTC-5, Rod Pemberton wrote:
>> The big problem with Forth is there is no ability to know
>> the size of the data the pointer points to. I.e., you'd need []
>> for cell size data and c[] for character sized data.
>
> The big problem with C is that you have to know the size of the
> data that a pointer points to.
No, you don't.
The subscript operator [] in C works with the size of the object the
pointer points to, as long as it's not a void pointer. For a[b]
either a or b must be a pointer and the other must be an offset or
index. If b is the offset, then a[b] is identical to:
*(*a)((a)+((b)x(sizeof(*a))))
That's index b multiplied by the size of the object the pointer
a points to, i.e., scale = index x size, plus the pointer a, the
sum of which is type cast to the same type as pointer a, then it's
dereferenced to fetch the appropriately sized value.
Please note that the index or offset is automatically scaled by the
size of the appropriate type.
This is usually represented in C standards in simplied form without
the scaling shown:
E1[E2] equivalent to *((E1)+(E2))
Although the subscript operator [] has the appearance of an array
index, it doesn't have to be used with just declared arrays. It
can be used with any pointer in C or any object type which "decays
into" a pointer such as declared arrays and parameters to functions.
The is also no specification on which element must be the offset
and which must be the pointer. E.g.,
/* c is set to the char at index 1, i.e., 'S' */
/* c indexing starts at zero */
/* "ASDF" is not a character constant but a name for a pointer to char */
/* ASDF\0 is the actual character constant which is stored elsewhere */
c = "ASDF"[1] /* pointer_to_char[index] */
> You can't just say [] and get it.
What? Sure you can.
int myint, myintarray*,myintsecond[5]={1,2,3,4,5};
char mychar, mychararray*,mycharsecond[]="Hello";
mychar=mycharsecond[3];
myint=myintsecond[4];
mychar will be set to the 4th char in the array "mychararray".
myint will be set to the 5th int in the array "myintarray".
You can do the same with pointers instead of arrays.
myintarray= ... ; /* assign pointer to something */
mychararray= ... ;
myint=myintarray[5];
mychar=mychararray[3];
I.e., the index is scaled by the appropriate object size
for both arrays and pointers. The C subscript operater
[] "knows" nothing about arrays. Except for declarations,
C doesn't actually have arrays. The behavior of arrays
is emulated purely by the subscript operator and the
addresses C uses to identify objects.
> You have to say what size it is when you get it:
>
> void example (float *fs) {
>
> and you have to say what size variable you're fetching it to:
>
> float c = *fs;
No, you don't. At least, not where you placed "float".
"float" would normally be used where "c" is declared, not
where it is assigned, unless you're using C++ or a C99 feature.
I.e., normal C code to dereference a pointer to an object:
float c; /* declare c to be type float */
/* bunch of code ... */
c=*fs; /* dereference fs to fetch float, store in c */
> Just look at that last example again, next to the Forth:
>
> float c = *fs;
> fs f@
>
> Isn't it just awful, that one of these examples requires you to know
> *so* much more than the other does? Why can't that one language be
> as smart, on your behalf, as the other?
I'm not sure about the use of floats in C, as I don't use them much.
But, you don't have to do what you did that way in C for other C
object types, structs, or unions. You can if you want though ...
Rod Pemberton
--
Scientists now say we'll experience a mini-ice in 2030.
So, I guess we need more global warming today ...
[toc] | [prev] | [next] | [standalone]
| From | Bernd Linsel <bl1@gmx.com> |
|---|---|
| Date | 2015-07-28 18:57 +0200 |
| Message-ID | <mp8cah$2od$1@newsreader4.netcologne.de> |
| In reply to | #40860 |
> On Mon, 27 Jul 2015 19:44:26 -0400, Julian Fondren
> <julian.fondren@gmail.com> wrote:
>> On Monday, July 27, 2015 at 6:31:14 PM UTC-5, Rod Pemberton wrote:
>
>>> The big problem with Forth is there is no ability to know
>>> the size of the data the pointer points to. I.e., you'd need []
>>> for cell size data and c[] for character sized data.
>>
>> The big problem with C is that you have to know the size of the
>> data that a pointer points to.
IN C you even may write
double foo(float* fp)
{
double z = 3.1415926536 * *fp; /* or fp[0] instead */
return z;
}
The compiler knows which size the object pointed to by fp is, you don't
have to indicate when dereferencing the pointer. THe above statement is
valid because of the implicit type promotion rules in C: A single/float
is silently promoted to double if invoked in operations with other
doubles (for a pure float expression, you should've written 3.14159f).
Am 28.07.2015 um 02:32 schrieb Rod Pemberton:
>
> No, you don't.
>
> The subscript operator [] in C works with the size of the object the
> pointer points to, as long as it's not a void pointer. For a[b]
> either a or b must be a pointer and the other must be an offset or
> index. If b is the offset, then a[b] is identical to:
>
> *(*a)((a)+((b)x(sizeof(*a))))
>
> That's index b multiplied by the size of the object the pointer
> a points to, i.e., scale = index x size, plus the pointer a, the
> sum of which is type cast to the same type as pointer a, then it's
> dereferenced to fetch the appropriately sized value.
>
> Please note that the index or offset is automatically scaled by the
> size of the appropriate type.
>
> This is usually represented in C standards in simplied form without
> the scaling shown:
>
> E1[E2] equivalent to *((E1)+(E2))
>
> Although the subscript operator [] has the appearance of an array
> index, it doesn't have to be used with just declared arrays. It
> can be used with any pointer in C or any object type which "decays
> into" a pointer such as declared arrays and parameters to functions.
> The is also no specification on which element must be the offset
> and which must be the pointer. E.g.,
>
> /* c is set to the char at index 1, i.e., 'S' */
> /* c indexing starts at zero */
> /* "ASDF" is not a character constant but a name for a pointer to char */
> /* ASDF\0 is the actual character constant which is stored elsewhere */
>
> c = "ASDF"[1] /* pointer_to_char[index] */
>
>> You can't just say [] and get it.
>
> What? Sure you can.
>
> int myint, myintarray*,myintsecond[5]={1,2,3,4,5};
> char mychar, mychararray*,mycharsecond[]="Hello";
>
> mychar=mycharsecond[3];
> myint=myintsecond[4];
>
> mychar will be set to the 4th char in the array "mychararray".
> myint will be set to the 5th int in the array "myintarray".
>
> You can do the same with pointers instead of arrays.
>
> myintarray= ... ; /* assign pointer to something */
> mychararray= ... ;
>
> myint=myintarray[5];
> mychar=mychararray[3];
>
> I.e., the index is scaled by the appropriate object size
> for both arrays and pointers. The C subscript operater
> [] "knows" nothing about arrays. Except for declarations,
> C doesn't actually have arrays. The behavior of arrays
> is emulated purely by the subscript operator and the
> addresses C uses to identify objects.
>
>> You have to say what size it is when you get it:
>>
>> void example (float *fs) {
>>
>> and you have to say what size variable you're fetching it to:
>>
>> float c = *fs;
>
> No, you don't. At least, not where you placed "float".
> "float" would normally be used where "c" is declared, not
> where it is assigned, unless you're using C++ or a C99 feature.
> I.e., normal C code to dereference a pointer to an object:
>
> float c; /* declare c to be type float */
>
> /* bunch of code ... */
>
> c=*fs; /* dereference fs to fetch float, store in c */
>
>> Just look at that last example again, next to the Forth:
>>
>> float c = *fs;
>> fs f@
>>
>> Isn't it just awful, that one of these examples requires you to know
>> *so* much more than the other does? Why can't that one language be
>> as smart, on your behalf, as the other?
>
> I'm not sure about the use of floats in C, as I don't use them much.
> But, you don't have to do what you did that way in C for other C
> object types, structs, or unions. You can if you want though ...
>
>
> Rod Pemberton
>
ACK
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-07-27 22:03 -1000 |
| Message-ID | <FeudndhGgITeqirInZ2dnUU7-bmdnZ2d@supernews.com> |
| In reply to | #40856 |
On 7/27/15 1:31 PM, Rod Pemberton wrote: > On Mon, 27 Jul 2015 04:19:50 -0400, Elizabeth D. Rather > <erather@forth.com> wrote: > >> On 7/26/15 7:30 PM, Rod Pemberton wrote: >>> On Sun, 26 Jul 2015 22:49:50 -0400, Elizabeth D. Rather >>> <erather@forth.com> wrote: > >>>> The longer the phrase, the fewer instances it takes to justify >>>> being factored. This particular phrase is very short, >>> >>> Yes. It's very short just like @ and ! are very short. >>> They were factored. Are you saying they shouldn't have been? >> >> Yes. The difference is that @ and ! are ubiquitous, whereas this >> particular, very specific indexing sequence would normally be >> incorporated in the DOES> portion of a defining word, and never used >> independently. > > So, it would never be used with PAD or to display a BIOS string > which has no defining word for it's address? ... The user can > enter an address directly on the stack, then use [] to index whatever > is there. The big problem with Forth is there is no ability to know > the size of the data the pointer points to. I.e., you'd need [] > for cell size data and c[] for character sized data. If the indexing is incorporated in the execution portion of a defining word, it's possible for the size of the array to be stored with it, so reasonable bounds checking can be performed if it's appropriate for the application. A generic word like [] cannot do this. >>>> quite unlikely to be repeated beyond the use here, >>> >>> It can be used from the interpreted state with any address. >>> I.e., it's a generic addressing operation like @ ! +! TOGGLE >>> etc. So, why exactly would it be unlikely to be used? ... >> >> It wouldn't be used independent of the array defining word because >> there is no need for it except in that context. It has little value >> as an independent facility. > > C is a pointer based language where every object in C maps onto > an array. It uses this functionality all the time for everything. > The ANS Forth standard requires the same inherent layout. And, > Forth deals with raw addresses too. I.e., I think you're strongly > down-playing the usefulness here. Well, I don't think that functionality is appropriate all the time for everything. I prefer to write exactly the functionality I need for every instance. Obviously that could be a pain in many languages, but if it costs you ~1 or 2 lines of code and 30 sec. thought, it's easier than searching for the right library. 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 | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-07-27 09:12 +0000 |
| Message-ID | <55b5f59a.543297693@news.eternal-september.org> |
| In reply to | #40816 |
On Mon, 27 Jul 2015 01:30:10 -0400, "Rod Pemberton" <boo@fasdfrewar.cdm> wrote: >C captures the essence of all generic microprocessors. Huh? Justify that, please. What is a generic microprocessor? 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 | 2015-07-27 11:02 -0700 |
| Message-ID | <40eef114-1b88-4c29-8937-f0a708a8e805@googlegroups.com> |
| In reply to | #40816 |
On Sunday, July 26, 2015 at 10:29:59 PM UTC-7, Rod Pemberton wrote: > C captures the essence of all generic microprocessors. Forth, > instead, usually attempts to impose it's own virtual machine. > So, in that regard, it would actually suit Forth to be more > C like. Even Hugh is having difficulty adding functionality to > Forth without recreating C functionality. He's done so twice > with projects even though he riles against C-like memory allocation > for Forth. Anton doesn't even bother attempting to hide from C. Nothing that Rod says is true --- he should be ignored. My FMITE processor and the associated LOTD language have quotations that have access to the parent function's local variables --- I am not "recreating C functionality" because C doesn't have this functionality --- the FMITE is intended to obsolete both C and ANS-Forth in the micro-controller world as both C and ANS-Forth are lacking quotations. Also, I didn't have any difficulty with designing the FMITE --- it was easy --- mostly just a matter of taking the time to do it. Another thing: most of the micro-processors of 20-30 years ago were CISC and had instructions provided specifically to support C (the 65c816 and MC6808 both had indexing addressing into the return-stack, for example) --- they weren't "generic microprocessors" but were in fact C-engines (as compared to processors such as the MiniForth or the Novix that were Forth-engines) --- nowadays we have RISC processors such as the ARM that are much more generic in design, and hence are reasonable targets for C or Forth or any other language. I think that it is uncool that people should talk about me in threads that I'm not involved in, especially if they make up stuff that isn't true. I wasn't even going to read this thread because I agree with Mark that Forth is a bad choice as a scripting language (the MiniForth was used in motion-control of a laser-etcher and competed well against the competitor's 68K system written in C, which is a lot different than trying to compete against Python as described in this thread) --- I only read the thread because I was bored, but then I find the usual cast of idiots talking about me and saying that I'm "recreating C functionality" (that's not true; I compared LOTD to C in my document showing how different they were; if anything, I'm recreating Factor functionality).
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-07-27 14:14 -0400 |
| Message-ID | <mp5sar$g4m$1@dont-email.me> |
| In reply to | #40845 |
On 7/27/2015 2:02 PM, hughaguilar96@gmail.com wrote: > > I think that it is uncool that people should talk about me in threads > that I'm not involved in Beetlejuice, Beetlejuice, Beetlejuice! ;-) -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-27 20:17 +0100 |
| Message-ID | <mp6018$vfm$1@dont-email.me> |
| In reply to | #40845 |
on 27/07/2015 19:02:21, hugher wrote: > I think that it is uncool that people should talk about me in threads > that I'm not involved in, especially if they make up stuff that isn't > true. Jeez, Hugh, John Passiniti hasn't posted here in years, yet you still keep calling out to him.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-07-27 19:33 -0400 |
| Message-ID | <op.x2gg2gekyfako5@localhost> |
| In reply to | #40852 |
On Mon, 27 Jul 2015 15:17:25 -0400, Alex McDonald <blog@rivadpm.com> wrote: > on 27/07/2015 19:02:21, hugher wrote: >> I think that it is uncool that people should talk about me in threads >> that I'm not involved in, especially if they make up stuff that isn't >> true. > > Jeez, Hugh, John Passiniti hasn't posted here in years, It's true he hasn't posted under his own name, but it's probably not true that he's not posting here. See Alex Wegel and/or WJ. > yet you still keep calling out to him. Well, you're one to talk. You keep mentioning me in threads I'm not involved in and usually haven't read. Rod Pemberton -- Scientists now say we'll experience a mini-ice in 2030. So, I guess we need more global warming today ...
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-07-27 22:05 -1000 |
| Message-ID | <FeudndtGgIR4qirInZ2dnUU7-bmdnZ2d@supernews.com> |
| In reply to | #40858 |
On 7/27/15 1:33 PM, Rod Pemberton wrote: > On Mon, 27 Jul 2015 15:17:25 -0400, Alex McDonald <blog@rivadpm.com> wrote: >> on 27/07/2015 19:02:21, hugher wrote: > >>> I think that it is uncool that people should talk about me in threads >>> that I'm not involved in, especially if they make up stuff that isn't >>> true. >> >> Jeez, Hugh, John Passiniti hasn't posted here in years, > > It's true he hasn't posted under his own name, but > it's probably not true that he's not posting here. > See Alex Wegel and/or WJ. LOL, Passiniti had a well-defined particular point of view and set of experiences on which he based his comments, which are poles apart from those of Alex Wegel and WJ. 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 | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-28 12:47 +0100 |
| Message-ID | <mp7q0s$o88$1@dont-email.me> |
| In reply to | #40864 |
on 28/07/2015 09:05:54, "Elizabeth D. Rather" wrote: > On 7/27/15 1:33 PM, Rod Pemberton wrote: >> On Mon, 27 Jul 2015 15:17:25 -0400, Alex McDonald <blog@rivadpm.com> wrote: >>> on 27/07/2015 19:02:21, hugher wrote: >> >>>> I think that it is uncool that people should talk about me in threads >>>> that I'm not involved in, especially if they make up stuff that isn't >>>> true. >>> >>> Jeez, Hugh, John Passiniti hasn't posted here in years, >> >> It's true he hasn't posted under his own name, but >> it's probably not true that he's not posting here. >> See Alex Wegel and/or WJ. > > LOL, Passiniti had a well-defined particular point of view and set of > experiences on which he based his comments, which are poles apart from > those of Alex Wegel and WJ. > > Cheers, > Elizabeth > There's tone deaf and then there's Rod. I enjoyed Passaniti's witty style and exposition. Andrew Haley (whom I mention even though he's not in this thread; please forgive me) wrote thoughtful & provocative posts too, but he seems to have given up on us.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-07-28 23:52 -0400 |
| Message-ID | <op.x2inozb5yfako5@localhost> |
| In reply to | #40864 |
On Tue, 28 Jul 2015 04:05:53 -0400, Elizabeth D. Rather <erather@forth.com> wrote: > On 7/27/15 1:33 PM, Rod Pemberton wrote: >> On Mon, 27 Jul 2015 15:17:25 -0400, Alex McDonald <blog@rivadpm.com> wrote: >>> on 27/07/2015 19:02:21, hugher wrote: >>>> I think that it is uncool that people should talk about me in threads >>>> that I'm not involved in, especially if they make up stuff that isn't >>>> true. >>> >>> Jeez, Hugh, John Passiniti hasn't posted here in years, >> >> It's true he hasn't posted under his own name, but >> it's probably not true that he's not posting here. >> See Alex Wegel and/or WJ. > > LOL, Passiniti had a well-defined particular point of view and set of > experiences on which he based his comments, which are poles apart from > those of Alex Wegel and WJ. Alex is emotionally distraught over past Passiniti conversations, conversations for which he wasn't even present, and is emotionally hurt over them in the manner you'd expect Passiniti to be. WJ codes anagrams in non-Forth languages the same way as Passiniti did. Rod Pemberton -- Scientists now say we'll experience a mini-ice in 2030. So, I guess we need more global warming today ...
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2015-07-29 12:24 +0200 |
| Message-ID | <1m8blgg.122do3e1ivsx7kN%awegel@arcor.de> |
| In reply to | #40885 |
Rod Pemberton <boo@fasdfrewar.cdm> wrote: > Alex is emotionally distraught over past Passiniti conversations, > conversations for which he wasn't even present, and is emotionally > hurt over them in the manner you'd expect Passiniti to be. No, i'm just pissed off by back-biting arseholes that can't (or just don't care to) check even the simplest facts (like you are demonstrating here). I hope you'll change for the better after your coming-out (albeit it probably wont make you smarter).
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-07-27 19:32 -0400 |
| Message-ID | <op.x2gg0hckyfako5@localhost> |
| In reply to | #40845 |
On Mon, 27 Jul 2015 14:02:23 -0400, <hughaguilar96@gmail.com> wrote: > On Sunday, July 26, 2015 at 10:29:59 PM UTC-7, Rod Pemberton wrote: >> C captures the essence of all generic microprocessors. Forth, >> instead, usually attempts to impose it's own virtual machine. >> So, in that regard, it would actually suit Forth to be more >> C like. Even Hugh is having difficulty adding functionality to >> Forth without recreating C functionality. He's done so twice >> with projects even though he riles against C-like memory allocation >> for Forth. Anton doesn't even bother attempting to hide from C. > > Nothing that Rod says is true --- he should be ignored. Everything I say is true. > My FMITE processor and the associated LOTD language have quotations > that have access to the parent function's local variables --- I am > not "recreating C functionality" because C doesn't have this > functionality --- the FMITE is intended to obsolete both C and > ANS-Forth in the micro-controller world as both C and ANS-Forth > are lacking quotations. Also, I didn't have any difficulty with > designing the FMITE --- it was easy --- mostly just a matter of > taking the time to do it. I have no idea what FMITE is ... Clearly, I wasn't criticizing it. > I think that it is uncool that people should talk about me in > threads that I'm not involved in, So, you never mentioned me in a thread I wasn't involved in? Whatever ... > saying that I'm "recreating C functionality" (that's not true; It is. You are. I've pointed it out a few times now. Simply denying this doesn't change reality. Rod Pemberton -- Scientists now say we'll experience a mini-ice in 2030. So, I guess we need more global warming today ...
[toc] | [prev] | [next] | [standalone]
| From | Bernd Linsel <bl1@gmx.com> |
|---|---|
| Date | 2015-07-28 19:22 +0200 |
| Message-ID | <mp8dp3$3qg$1@newsreader4.netcologne.de> |
| In reply to | #40845 |
Am 27.07.2015 um 20:02 schrieb hughaguilar96@gmail.com: > On Sunday, July 26, 2015 at 10:29:59 PM UTC-7, Rod Pemberton wrote: >> C captures the essence of all generic microprocessors. Nope. C works fine on machines with huge register sets, a hardware call stack, and a frame pointer. You're even better off if it supports indexed register-indirect addressing modes. I wouldn't call that a "generic microprocessor". Look at the (vain) efforts to implement C on the 1980's common processors (8080/5, 8086, ...). Motorolas 68K was the first part decently usable for C. >> Forth, >> instead, usually attempts to impose it's own virtual machine. Forth runs perfectly on stack machines, e.g. RTX 2000. You should read Philip J. Koopman, Jr's publications: http://users.ece.cmu.edu/~koopman/stack_computers/ >> So, >> in that regard, it would actually suit Forth to be more C like. >> Even Hugh is having difficulty adding functionality to Forth >> without recreating C functionality. He's done so twice with >> projects even though he riles against C-like memory allocation for >> Forth. Anton doesn't even bother attempting to hide from C. > > [snip] > > Another thing: most of the micro-processors of 20-30 years ago were > CISC and had instructions provided specifically to support C (the > 65c816 and MC6808 both had indexing addressing into the return-stack, > for example) --- they weren't "generic microprocessors" but were in > fact C-engines (as compared to processors such as the MiniForth or > the Novix that were Forth-engines) yep > --- nowadays we have RISC > processors such as the ARM that are much more generic in design, and > hence are reasonable targets for C or Forth or any other language. After having implemented several Forth VMs and native compilers on MIPS and ARM embedded systems, I may remark that Forth on RISC machines tends to be rather clumsy, regarding load delay slots, missing diplaced indirect addressing, and so on. You have to optimize very carefully if you want to have a stall-free running Forth on a RISC. (Not even to mention cache thrashing and similar effects that nowadays also CISC processors suffer from if you're mixing code and data). An optimizing native compiler gains of course performance of a large register set, if you analyze the data flow on the stack and map it on the registers, eliminating nearly all DUPs, SWAPs, DROPs etc (with the exception that the stack/register mapping must be consistent on all junction points). RISC is in my opinion just muscles without the brain; raw force without any sophistication. If directed (programmed) accurately, you may achieve great performance -- if not, you can fail epically. > > I think that it is uncool that people should talk about me in threads > that I'm not involved in, especially if they make up stuff that isn't > true. I wasn't even going to read this thread because I agree with > Mark that Forth is a bad choice as a scripting language (the > MiniForth was used in motion-control of a laser-etcher and competed > well against the competitor's 68K system written in C, which is a lot > different than trying to compete against Python as described in this > thread) --- I only read the thread because I was bored, but then I > find the usual cast of idiots talking about me and saying that I'm > "recreating C functionality" (that's not true; I compared LOTD to C > in my document showing how different they were; if anything, I'm > recreating Factor functionality). > -- Regards Bernd
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2015-07-28 15:46 -0400 |
| Message-ID | <mp8m6b$dul$1@speranza.aioe.org> |
| In reply to | #40875 |
On 28/07/2015 1:22 PM, Bernd Linsel wrote: > Am 27.07.2015 um 20:02 schrieb hughaguilar96@gmail.com: >> On Sunday, July 26, 2015 at 10:29:59 PM UTC-7, Rod Pemberton wrote: >>> C captures the essence of all generic microprocessors. > > Nope. C works fine on machines with huge register sets, a hardware call > stack, and a frame pointer. You're even better off if it supports > indexed register-indirect addressing modes. > > I wouldn't call that a "generic microprocessor". Look at the (vain) > efforts to implement C on the 1980's common processors (8080/5, 8086, > ...). Motorolas 68K was the first part decently usable for C. > You are correct that the M68k was the first really decent platform for C. But C can and has been implemented to create application code on a very wide variety of target processors. This has happened because that language itself is very flexible not requiring stacks or very many addressing modes and still can support reasonably effecient application implementations. We have targeted about 30 targets mostly for embedded systems for C including COP8 a bit serial processor, Microchip PIC a processor without a user accessible stack with as little as 512 instruction space and 32 bytes of ram. w..
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-07-28 23:47 -0400 |
| Message-ID | <op.x2inhy1eyfako5@localhost> |
| In reply to | #40875 |
On Tue, 28 Jul 2015 13:22:48 -0400, Bernd Linsel <bl1@gmx.com> wrote: > Am 27.07.2015 um 20:02 schrieb hughaguilar96@gmail.com: >> On Sunday, July 26, 2015 at 10:29:59 PM UTC-7, Rod Pemberton wrote: >>> C captures the essence of all generic microprocessors. > You've replied to both Hugh and I in the same post. That's likely to incite Hugh. Well, everything incites Hugh ... It's easier to follow if you keep replies to the last person, and reply to the other person on their post. >>> C captures the essence of all generic microprocessors. > > Nope. C works fine on machines with huge register sets, a hardware > call stack, and a frame pointer. You're even better off if it supports > indexed register-indirect addressing modes. Yes. Everything an 8-bit microprocessor can do, and the general purpose instructions of 16-bit processors, can be done directly in C without needing to use assembly. The only thing missing is a carry flag and an overflow flag. While it's much easier to implement C on a machine with a hardware stack, C was implemented on mainframes without them. That's why the C standards don't require a stack. However, IIRC, it was Dennis Ritchie who showed in one of his papers that a stack is the easiest and cleanest way to implement recursion in C, which is required. Also, C works fine on machines with few registers. C works best on microprocessors with addressable 8-bit bytes, contiguous memory, two's complement arithmetic, a hardware stack, the largest integer a multiple of the 8-bit byte, and pointers the same size as the largest integers. Forth generally likes these too, but needs two stacks to implement instead of one since it separates the data and control flow stack. Integers a multiple of the size of a byte is needed because C maps every object onto an array of bytes. Pointers the same size as the largest integer is convenient because of C's lossless type conversions, i.e., pointer to integer to pointer. C is difficult to implement on machines with a 16-bit word size, machines where the smallest addressable unit is much larger than a character in size, machines where the address pointer is greater in size than the largest integer. All of these situations require constructing special code, e.g., to save extra bits for pointer conversions or to extract characters packed into larger integers. > I wouldn't call that a "generic microprocessor". Look at the (vain) > efforts to implement C on the 1980's common processors (8080/5, 8086, > ...). Motorolas 68K was the first part decently usable for C. While it seems you're familiar with some stuff from the 1980's, it seems you forgot about Ron Cain's SmallC. It was originally written for the Intel 8080 and also ported to PDP-11. If it can run on 8080, it can run on all other 8-bits. IIRC, the code emitted by the 8086 port needed only *two* registers. I'd suspect it needed a few more on the 8080. >>> Forth, instead, usually attempts to impose it's own virtual machine. > > Forth runs perfectly on stack machines, e.g. RTX 2000. The RTX 2000 was a dedicated Forth processor. Why would you need to implement a virtual machine for it? ... More commonly, when Forth is implemented on a generic processor, Forth is implemented as an interpreter which uses a virtual machine. Specifically, it uses a virtual processor, generally with registers W, IP, PSP, RSP, UP, and/or X, and/or TOS. If you're interested in this, you can read Bradford J. Rodriguez's Forth code for various 8-bit processors: Bradford J. Rodriguez, PHD http://www.bradrodriguez.com/papers/ However, I'd assume that if you're familiar with Koopman then you're likely familiar with Rodriguez. > You should read Philip J. Koopman, Jr's publications: > http://users.ece.cmu.edu/~koopman/stack_computers/ I'm quite familiar with some of his work, including portions of his book, since I consulted it for my Forth interpreter, e.g., instruction set frequencies and similar papers by Anton Ertl's too. Rod Pemberton -- Scientists now say we'll experience a mini-ice in 2030. So, I guess we need more global warming today ...
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-29 07:22 +0000 |
| Message-ID | <2015Jul29.092237@mips.complang.tuwien.ac.at> |
| In reply to | #40884 |
"Rod Pemberton" <boo@fasdfrewar.cdm> writes:
>Yes. Everything an 8-bit microprocessor can do, and the general
>purpose instructions of 16-bit processors, can be done directly in
>C without needing to use assembly. The only thing missing is a
>carry flag and an overflow flag.
Yes, these are two things that you cannot express directly in C.
Another big restriction of C is that you are limited in the kind of
control-flow you can do. Threaded code? Not in standard C.
Tail-call optimization? Neither guaranteed nor commonplace (in
general, not possible). Coroutining? Nope. Prolog-like backtracking?
Nope.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web