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 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-08-13 13:43 -0700 |
| Message-ID | <f432e7c6-8237-4ce5-8aee-bf2bf4394222@googlegroups.com> |
| In reply to | #41305 |
On Wednesday, August 12, 2015 at 9:31:04 PM UTC-7, hughag...@gmail.com wrote: > This is why I say in the documentation that with 3ARRAY and ARY it is best to make the dimensions a power of 2 if possible for speed, even though this may waste some memory. > > Both xARRAY and ARY use LIT*, internally --- it is smart about what kind of literal value it is given, and will compile a shift rather than a multiply if the literal value is a power of two --- this is one of the reasons why the novice-package generates efficient code while yet retaining ANS-Forth compliance. The above post was late at night and I wasn't thinking clearly. Here is a more coherent explanation: xARRAY uses shift rather than multiply if the element-size is a power of two and the dimension-size is also a power of two. ARY uses shift rather than multiply if the element-size is a power of two, but it doesn't matter whether the dimension-size is a power of two or not. Because of this, I now recommend ARY rather than xARRAY for defining arrays. It is more efficient. Also, you can have any number of dimensions --- with the xARRAY words, you get only six dimensions (or four dimensions in Win32Forth). My first-ever Forth program was a port of a BASIC program from a TAB book on artificial-intelligence. This used a six-dimensional array (I was using HES Forth for the Vic-20, and wrote the array definer using <BUILDS DOES> similar to SLOW-3ARRAY above). The idea was that the environment for a creature could be described with six parameters. So, a six-dimensional array could contain every possible circumstance that the creature could find itself in. The creature moved around and it would make random decisions. If the decision worked, then it was stored in the array as a good idea, but otherwise it was stored as a bad idea. Before making a decision, the creature would check if it had any good ideas already in memory, and if so do that. If not, it would choose randomly, but only from untried ideas; it would not use any idea that had already been proven to be a bad idea. Over time, the creature became increasingly "intelligent" about its environment. This is the only use I've found for arrays with a lot of dimensions --- somewhat of a brute-force approach to artificial intelligence --- but it does work.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-08-13 10:55 +0100 |
| Message-ID | <mqhpei$nqp$1@dont-email.me> |
| In reply to | #41304 |
on 13/08/2015 05:16:56, hugh wrote:
>
> VFX seems to be similar to SwiftForth in that it does a CALL to the
> code af ter (;CODE) and then uses the return-address on the
> return-stack as the poi nter to the data after the CREATE.
It's actually the pointer to the DOES> *code*, not to the data.
> This was a
> clever technique in the late 1970s and early 1980s, but it is not so
> clever now. One problem, is that th is requires that code and data be
> intermixed which results in a lot of cach e-thrashing because modern
> machines have a separate data-cache and code-cac he, but when data and
> code are juxtaposed you end up with data in the code- cache and code
> in the data-cache. Another problem is that modern machines ( the x86
> anyway) do CALL prediction, meaning that when a CALL is done the re
> turn-address is held in a register internally in addition to being
> held on the return-stack, and the RET is faster because it gets the
> return-address from the register rather than from memory. This works
> to 16 levels deep IIR C. If the program pulls the return-address from
> the return-stack however, t hen the whole thing goes haywire and all
> that information is lost. This is what both VFX and SwiftForth do in
> the code after the (;CODE) because it is not a return-address and
> won't be given to RET but it is actually a pointe r to data.
It doesn't have to intermix data and code. Plus, you have to remember
that the bit before the DOES> is only executed when the word is defined.
It can in most cases be as inefficent as you like. The bit after the
DOES> is potentially done many times more frequently, and that's where
care is required to speed the execution.
Many Forths have an equivalent (;CODE) that's a factor of ;CODE. My
solution is
STC Experimental 32bit: 0.06.08 Build: 507
: foo create , does> @ ; ok
see foo
: foo ( ? -- ? )
\ foo is defined in (console)
\ call compiled
\ code=$41C278 len=26 type=130
( $0 ) call ' create \ E84A76FEFF
( $5 ) call ' , \ E84465FEFF
( $A ) call ' (;code) \ E85CADFEFF
( $F ) ret \ C3
( $10 ) mov dword { $-4 ebp } eax \ 8945FC
( $13 ) mov eax ecx \ 8BC1
( $15 ) sub ebp $4 \ 83ED04
( $18 ) mov eax dword { eax } \ 8B00
( $1A ) ret \ C3 ( end ) ok
10 foo bar ok
see bar
create bar ( addr $805328 ) ( ? -- ? )
\ bar is defined in (console)
\ call compiled
\ code=$41C298 len=10 type=145
( $0 ) mov ecx $805328 \ B928538000
( $5 ) jmp ' foo $10 + \ E9E6FFFFFF ( end ) ok
The address from the call/ret sequence is used by (;CODE) to build the
address of the jump in BAR. When (;CODE) is called, the address is R@ 1+
, that is, just past the RET in FOO at ' foo $10 + .
ECX is the address of the data, which as you can see is at $805328. The
code that operates on the data is at $41C298 and $41C288.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-08-14 12:06 -0700 |
| Message-ID | <06dc3ebe-0194-47b4-b438-01b0bbaadcb6@googlegroups.com> |
| In reply to | #41307 |
On Thursday, August 13, 2015 at 2:55:04 AM UTC-7, Alex McDonald wrote: > on 13/08/2015 05:16:56, hugh wrote: > > > > > VFX seems to be similar to SwiftForth in that it does a CALL to the > > code af ter (;CODE) and then uses the return-address on the > > return-stack as the poi nter to the data after the CREATE. > > It's actually the pointer to the DOES> *code*, not to the data. Alex McDonald is lying --- as usual. > > This was a > > clever technique in the late 1970s and early 1980s, but it is not so > > clever now. One problem, is that th is requires that code and data be > > intermixed which results in a lot of cach e-thrashing because modern > > machines have a separate data-cache and code-cac he, but when data and > > code are juxtaposed you end up with data in the code- cache and code > > in the data-cache. Another problem is that modern machines ( the x86 > > anyway) do CALL prediction, meaning that when a CALL is done the re > > turn-address is held in a register internally in addition to being > > held on the return-stack, and the RET is faster because it gets the > > return-address from the register rather than from memory. This works > > to 16 levels deep IIR C. If the program pulls the return-address from > > the return-stack however, t hen the whole thing goes haywire and all > > that information is lost. This is what both VFX and SwiftForth do in > > the code after the (;CODE) because it is not a return-address and > > won't be given to RET but it is actually a pointe r to data. > > It doesn't have to intermix data and code. Still lying... > Plus, you have to remember > that the bit before the DOES> is only executed when the word is defined. > It can in most cases be as inefficent as you like. The bit after the > DOES> is potentially done many times more frequently, and that's where > care is required to speed the execution. Now he is making an obvious elementary point trying to imply that I don't how CREATE DOES> works. This is typical cult behavior --- to tell such blatant lies in support of the cult leader --- I provided the disassembly in both SwithForth and VFX of CREATE DOES> code, so anybody can see that he is lying --- he doesn't care though, because so long as he supports Forth Inc. then the Forth-200x committee will support him.
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2015-08-14 18:33 -0700 |
| Message-ID | <d47e041a-dcf0-49db-899f-368f5932ab28@googlegroups.com> |
| In reply to | #41312 |
On Friday, 14 August 2015 20:06:10 UTC+1, hughag...@gmail.com wrote: > On Thursday, August 13, 2015 at 2:55:04 AM UTC-7, Alex McDonald wrote: > > on 13/08/2015 05:16:56, hugh wrote: > > > > > > > > VFX seems to be similar to SwiftForth in that it does a CALL to the > > > code af ter (;CODE) and then uses the return-address on the > > > return-stack as the poi nter to the data after the CREATE. > > > > It's actually the pointer to the DOES> *code*, not to the data. > > Alex McDonald is lying --- as usual. Read the code Hugh. ( 004DCB62 E8F1A9F6FF0ACB4D00 ) CALL 00447558 DOES_SIN 004DCB0A ( 004DCB6B E8B081F6FF ) CALL 00444D20 NO-COMPILER ( 004DCB70 E88F32F3FF ) CALL 0040FE04 (;CODE) ( 004DCB75 8B1424 ) MOV EDX, [ESP] What are these instructions doing do you think? No, you don't need to know what DOES_SIN NO_COMPILER or (;CODE) do in detail. > > > > This was a > > > clever technique in the late 1970s and early 1980s, but it is not so > > > clever now. One problem, is that th is requires that code and data be > > > intermixed which results in a lot of cach e-thrashing because modern > > > machines have a separate data-cache and code-cac he, but when data and > > > code are juxtaposed you end up with data in the code- cache and code > > > in the data-cache. Another problem is that modern machines ( the x86 > > > anyway) do CALL prediction, meaning that when a CALL is done the re > > > turn-address is held in a register internally in addition to being > > > held on the return-stack, and the RET is faster because it gets the > > > return-address from the register rather than from memory. This works > > > to 16 levels deep IIR C. If the program pulls the return-address from > > > the return-stack however, t hen the whole thing goes haywire and all > > > that information is lost. This is what both VFX and SwiftForth do in > > > the code after the (;CODE) because it is not a return-address and > > > won't be given to RET but it is actually a pointe r to data. > > > > It doesn't have to intermix data and code. > > Still lying... I showed code that doesn't need mixed code and data. Neither does VFX, but at least the data and the code are separated by a decent distance. Read the ode,and tell me where the data is, and where the code after DOES> is. > > > Plus, you have to remember > > that the bit before the DOES> is only executed when the word is defined. > > It can in most cases be as inefficent as you like. The bit after the > > DOES> is potentially done many times more frequently, and that's where > > care is required to speed the execution. > > Now he is making an obvious elementary point trying to imply that I don't how CREATE DOES> works. > > This is typical cult behavior --- to tell such blatant lies in support of the cult leader --- I provided the disassembly in both SwithForth and VFX of CREATE DOES> code, so anybody can see that he is lying --- he doesn't care though, because so long as he supports Forth Inc. then the Forth-200x committee will support him. I'm not implying anything at all. You really don't know how CREATE DOES> works.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-08-15 19:33 -0700 |
| Message-ID | <375398ec-76c9-4411-a2af-819ec13624ea@googlegroups.com> |
| In reply to | #41317 |
On Friday, August 14, 2015 at 6:33:44 PM UTC-7, Alex McDonald wrote: > On Friday, 14 August 2015 20:06:10 UTC+1, hughag...@gmail.com wrote: > > On Thursday, August 13, 2015 at 2:55:04 AM UTC-7, Alex McDonald wrote: > > > on 13/08/2015 05:16:56, hugh wrote: > > > > > > > > > > > VFX seems to be similar to SwiftForth in that it does a CALL to the > > > > code af ter (;CODE) and then uses the return-address on the > > > > return-stack as the poi nter to the data after the CREATE. > > > > > > It's actually the pointer to the DOES> *code*, not to the data. > > > > Alex McDonald is lying --- as usual. > > Read the code Hugh. > > ( 004DCB62 E8F1A9F6FF0ACB4D00 ) CALL 00447558 DOES_SIN 004DCB0A > ( 004DCB6B E8B081F6FF ) CALL 00444D20 NO-COMPILER > ( 004DCB70 E88F32F3FF ) CALL 0040FE04 (;CODE) > ( 004DCB75 8B1424 ) MOV EDX, [ESP] > > What are these instructions doing do you think? No, you don't need to know what DOES_SIN NO_COMPILER or (;CODE) do in detail. > > > > > > > This was a > > > > clever technique in the late 1970s and early 1980s, but it is not so > > > > clever now. One problem, is that th is requires that code and data be > > > > intermixed which results in a lot of cach e-thrashing because modern > > > > machines have a separate data-cache and code-cac he, but when data and > > > > code are juxtaposed you end up with data in the code- cache and code > > > > in the data-cache. Another problem is that modern machines ( the x86 > > > > anyway) do CALL prediction, meaning that when a CALL is done the re > > > > turn-address is held in a register internally in addition to being > > > > held on the return-stack, and the RET is faster because it gets the > > > > return-address from the register rather than from memory. This works > > > > to 16 levels deep IIR C. If the program pulls the return-address from > > > > the return-stack however, t hen the whole thing goes haywire and all > > > > that information is lost. This is what both VFX and SwiftForth do in > > > > the code after the (;CODE) because it is not a return-address and > > > > won't be given to RET but it is actually a pointe r to data. > > > > > > It doesn't have to intermix data and code. > > > > Still lying... > > I showed code that doesn't need mixed code and data. Neither does VFX, but at least the data and the code are separated by a decent distance. Read the code,and tell me where the data is, and where the code after DOES> is. 10 10 10 16 slow-3array sss ok hex ok ' sss u. 5178DB ok ' sss >body u. 5178E0 ok ' sss c@ . E8 ok The code for SSS is at 5178DB and the data for SSS is at 5178E0 --- notice that the data is 5 bytes ahead of the code. The code consists of a single CALL instruction (opcode E8) that goes to the code after the (;CODE) in SLOW-3ARRAY --- this code expects the address of the data to be on the return stack --- the first instruction ( MOV EDX, [ESP] ) moves this address to EDX where it is used as a pointer. This is done more than once, and eventually we have a POP EDX that removes the pointer from the return-stack. When the RET is eventually executed, it does not go back to SSS (there is no code after the CALL but instead there is data) --- the RET goes back to whatever code is was that called SSS. This is a very old trick for implementing CREATE DOES>. I independently invented this trick myself in 1985 when working on a Forth for the PDP-11 --- lots of people have independently invented this trick --- it is pretty obvious. This trick is a bad idea on the x86 because branch-prediction is a big deal on the x86. The return-address is held in a register internally and the RET destination is predicted from this register, so the micro-code at the destination can be generated ahead of time. When the return-stack is corrupted by popping the supposed return-address off the return-stack and using it as a data pointer, the whole system goes haywire. When RET executes it has to pop the return-address from the return-stack and only then can the micro-code be generated for the destination code --- this slows down RET significantly --- also, afaik, the whole 16-deep set of registers gets zonked and all the upper levels in the call-chain will also have their RET slowed down significantly. > > > Plus, you have to remember > > > that the bit before the DOES> is only executed when the word is defined. > > > It can in most cases be as inefficent as you like. The bit after the > > > DOES> is potentially done many times more frequently, and that's where > > > care is required to speed the execution. > > > > Now he is making an obvious elementary point trying to imply that I don't how CREATE DOES> works. > > > > This is typical cult behavior --- to tell such blatant lies in support of the cult leader --- I provided the disassembly in both SwithForth and VFX of CREATE DOES> code, so anybody can see that he is lying --- he doesn't care though, because so long as he supports Forth Inc. then the Forth-200x committee will support him. > > I'm not implying anything at all. You really don't know how CREATE DOES> works. Well, Bernd Paysan and Anton Ertl (both Forth-200x committee members), have read what Alex McDonald has said, and neither of them have contradicted him --- I take this as tacit approval for him to tell great big lies. Is Alex McDonald a member of the Forth-200x committee? If not, then what is the purpose of these loyalty demonstrations? There must be some pay-off for him --- most people are embarrassed to tell blatant lies in public and won't do it unless there is a pay-off.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-08-23 16:59 -0700 |
| Message-ID | <ebb246df-916e-49f8-ae7a-2c1190890eb7@googlegroups.com> |
| In reply to | #41304 |
Here, once again is SLOW-3ARRAY:
: slow-3array ( dim1 dim2 dim3 siz1 -- )
create
dup , \ -- dim1 dim2 dim3 siz1 --
>r rot r> * dup , \ -- dim2 dim3 siz2
rot * dup , \ -- dim3 siz3
* allot
does> \ x1 x2 x3 base-adr -- element-adr
>r \ -- x1 x2 x3 \r: -- base-adr
r@ 2 cells + @ * swap \ -- x1 x3*siz3 x2
r@ 1 cells + @ * + swap \ -- x3*siz3+x2*siz2 x1
r@ @ * + r> 3 cells + + ; \ -- x3*siz3+x2*siz2+x1*siz1+adr
In my language I will have the DOES> code start with the base address on the return-stack rather than the data-stack. I almost always start out my DOES> code with a >R as I did in SLOW-3ARRAY. It would be more convenient if the base address were already on the return-stack.
SLOW-3ARRAY would be written like this instead:
: slow-3array ( dim1 dim2 dim3 siz1 -- )
create
dup , \ -- dim1 dim2 dim3 siz1 --
>r rot r> * dup , \ -- dim2 dim3 siz2
rot * dup , \ -- dim3 siz3
* allot
does> \ x1 x2 x3 -- element-adr \r: -- base-adr
r@ 2 cells + @ * swap \ -- x1 x3*siz3 x2
r@ 1 cells + @ * + swap \ -- x3*siz3+x2*siz2 x1
r@ @ * + r> 3 cells + + ; \ -- x3*siz3+x2*siz2+x1*siz1+adr
A lot of implementations use CALL to get from the instance to the DOES> code, and the data is immediately after the CALL so the address that CALL pushes to the return-stack is not a return-address like normal but is instead a pointer to the base address. This means that the base address is already on the return-stack, so no code is needed to get it there.
Way back in 2009 when I joined the Forth-200x mailing list, the first thing I suggested was that we abandon CREATE DOES> and go back to <BUILDS DOES> --- and that we do what I said above, which is have the DOES> code start out with the base address on the return-stack rather than the data-stack. It was a good idea in 2009, and it is still a good idea --- but now it has to be my own language, as Forth-200x rejected it (and me).
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-08-13 15:52 -0700 |
| Message-ID | <b4f21244-88e3-4fa7-8d42-68c74d7f7d7f@googlegroups.com> |
| In reply to | #41247 |
On Sunday, August 9, 2015 at 7:30:10 PM UTC-7, Elizabeth D. Rather wrote: > Here's one presented in my Forth Application Techniques that I think is > far more useful than the FSL version: > > : ARRAY ( n -- ) CREATE DUP , CELLS ALLOT > DOES> ( n -- a) SWAP OVER @ OVER < OVER > 1 < OR ABORT" Out of Range" CELLS + ; I had said previously that every code snippet you had ever posted on comp.lang.forth was copied directly out of "Starting Forth." This code was not copied directly out of "Starting Forth" however --- this is the first time I have ever seen you post code that you actually wrote yourself. If this code were posted by a first-week novice who wanted to learn, then I would help the novice --- but you don't want to learn --- you want to teach! I can only imagine how many people have read your book, "Forth Application Techniques," and thought: "This is stupid! If this is how the leading expert in Forth programs, then Forth has nothing to offer --- I'm going back to C." > Virtually every Forth application needs some kind of array structures. > The reason that some general-purpose one might be "little used" is > because it's so easy to make a version that does *exactly* what the > application needs rather than some generic definition. If it is so easy, then why did you fail at it? > I think a lot of > contemporary Forths do include BUFFER: (which makes a bytewise array), > so it's not really correct that there are *no* arrays. BUFFER: is trivial and useless --- this is what Forth-200x is all about --- being trivial and useless. > Given a halfway decent manual (which anyone learning Forth should have) > learning to use CREATE ... DOES> is not difficult. Most of my students > can define a 2-dimensional cellwise array with error checking on the > fourth day of a course, although I'm not sure that's what I'd use in an > application myself. The objective is to master the toolset and be able > to think clearly about exactly what kind of arrays will be useful in > your application and then build exactly that kind. I really believe that the reason why Forth failed, is because everybody was told that they have to write everything from scratch. Nobody really has the time or patience for this, and no employer will pay for employees to implement customized data-structures --- if programmers are required to implement every data-structure from scratch, they don't write super-optimized code --- they write crappy code that they could slap together as quickly as possible because the boss didn't allocate any time for this low-level code, but only allocated time for writing the application code. You don't have to: "think clearly about exactly what kind of arrays will be useful in your application and then build exactly that kind." You don't have to: "make a version that does *exactly* what the application needs rather than some generic definition." The reason why I know that you are a non-programmer, is that you make programming seem much more difficult than it actually is. You imagine that data-structures are a mystifying concept, and that there are innumerable ways to implement them, and that it is necessary to pick the exact correct implementation for the application. You failed to implement an array, which is the simplest data-structure that there is --- you really know nothing about the subject. You have nothing positive to contribute to Forth --- just go away!
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-08-10 08:43 +0000 |
| Message-ID | <2015Aug10.104358@mips.complang.tuwien.ac.at> |
| In reply to | #41226 |
Doug Hoffman <glidedog@gmail.com> writes:
>The context of
>my original statement was *not* to propose an array word as standard or
>even condemn Forth. Instead I was using the lack of same as an
>illustration of the Forth Way, for better or worse, which I accept.
>That comment certainly generated the typical clf reaction: pounce on a
>small comment snippet rather than realize the context of the statement.
[I assume you mean the posting
<e2fc3d16-9abd-4328-8770-04454997aee0@googlegroups.com>]
Well, you did not get that across to me (and apparently not to others,
either) in your posting. In any case, there are technical reasons why
Forth has no more specific array words, it's not that Chuck came down
from the mountain with the commendment "Thou shalt not have built-in
array words" (not that we have followed him in the commendmends he
gave out in all cases, although some people do idolise him).
- 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]
| From | glidedog@gmail.com |
|---|---|
| Date | 2015-07-27 06:04 -0700 |
| Message-ID | <e86a6a50-0cc4-4b75-97ea-fa140cd2e11b@googlegroups.com> |
| In reply to | #40806 |
On 7/26/15 3:25 PM, Alex McDonald wrote: > on 26/07/2015 19:18:20, Paul Rubin wrote: >> "Alex McDonald" writes: >>> The definition of a 1 dimensional array is trivial; perhaps >>> that's why. : 1dim create cells allot does> swap cells + ; >> >> You're going to use arrays with no bounds checks to script >> potentially hostile internet devices? Sounds dangerous to me. > > That wasn't the original complaint; it was that there was not even a > cell sized array in Forth. No, the original complaint was from Mark Wills, partial quote follows: "Forth is next to useless for this sort of thing, unless you have a rack of libraries that you have personally built up over the years. Because, you know, this is Forth, right, and we don't use each other's libraries in the Forth world, because everyone else's code sucks, right? We can *all* do *much* better jobs by ourselves, re-inventing the wheel over and over and over again." I simply commented that I could understand his lament and chose the array as just one tiny example, perhaps not the best choice but sufficient I think. Thanks for the follow-up thoughts though. -Doug
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <ayrnieu@gmail.com> |
|---|---|
| Date | 2015-07-26 13:49 -0700 |
| Message-ID | <7b3a5a24-6c53-4ae4-ab49-fa30e1876a99@googlegroups.com> |
| In reply to | #40804 |
On Sunday, July 26, 2015 at 1:18:23 PM UTC-5, Paul Rubin wrote: > "Alex McDonald" <blog@rivadpm.com> writes: > > The definition of a 1 dimensional array is trivial; perhaps that's why. > > : 1dim create cells allot does> swap cells + ; > > You're going to use arrays with no bounds checks to script potentially > hostile internet devices? Sounds dangerous to me. One way to view this is, sure, your arrays should have bounds checking. And so should every other level of every other part of your program. You should everywhere find words running paranoid checks on values right before those values are fed into other words that run the same paranoid checks against them. Nowhere in your program may you say "I trust what has gotten this far, because it's surely been checked by now." You may, at best, have transition points where the tests kill your program with "the impossible happened--bailing out!" rather than gracefully handle an error condition. The only escape from this drudgery? A really smart compiler, that can know when the checks aren't unnecessary, and which can even come up with checks by itself. The advantage of this view, if you stick with it in Forth, is that you can, with some effort, achieve something like the absolutely miserable results that people manage with other languages that offer more advanced support for it. Another way to view this is... huh? What do *internet devices* have to do with *arrays*?! Let's say you're writing an IRC server. One thing IRC servers do is allow, into a room, a number of users. Faced with the famous "zero, one, or many" question of what limits to have, you of course pick an arbitrary configurable number, and then document the limits and resource implications of that number. Software, you see, does not in fact run on hardware possessed of infinite resources, and network services lack magic hardware even more severely than most software. So your configurable number makes its way to two separate places in your code: the size of an array of users in a room, where there is no bounds checking whatsoever, and also to the 'join a user to a room' function of the server, which refuses to join users to a room that, by that number, is full. The cost of the bounds checking is directly tied to a user's attempt to enter a room, which helps you consider the costs of a user's total actions, which helps you kick users who are abusing your server. The error condition of a user trying to join a full room is obvious: "Sorry, the room is full." You don't need to throw an exception from deep within your code--you're already where you want to be, processing a user request and prepared to reply to it. Or you could, the moment you have a need for an array, spend some time adding bounds checking to it, just so that you can kill the program with an "index out of bounds" error. What a wonderful thing for a server to do out of the blue. And it *will* be 'out of the blue' because the only reason you would code like this is if the rest of the server's code was a dark and scary labyrinth to you. You don't know what you're doing, so you write defensive code, and the result is that you still don't know what you're doing and your defensive code now sometimes kills your server based on decisions made far away from your code. So have fun debugging that! - Of course, dark and scary labyrinths are certainly out there. A while back I added a feature to such a body of code. A bug in my addition would have harmlessly caused the program to fail to do its job, which would've been noticed and which would've resulted in mild embarrassment, if not for the bug resulting later on in a function getting called with a rather unpleasant argument. The result? The program failed to do its job -- and also inflicted enormous performance costs on the servers it ran on. It wasn't noticed for some time that my code push coincided with the sudden spate of performance issues. I spent a lot of time cursing and swearing while personally fighting the fires that resulted from these performance issues, without suspecting that I'd caused them... Would that have been helped by boundary-checked data structures? No, I had them. Would it have been helped by algebraic types and compile-time checking of them by a really smart compiler? No, the argument was validly typed as far as the performance-killing function was concerned. And since we weren't asking the question of should the potential arguments to this function be more constrained than that function was designed to accept, we didn't answer that question with a new constrained type, or an additional test, or scrutiny towards the potential arguments to it that could arise in the body of code. Additionally, I wasn't aware of how the function was respond to the argument it got; if you'd asked me, I would guessed that it would very quickly do nothing. What might've actually helped: instead of trusting in my ability to dive into a 500-line or whatever *massive* routine and make just the demanded changes, I could've pulled out the section I was editing into its own function, Forth-style, as a new factor with precisely understood and considered inputs and outputs. I also could've followed up on the logs and performance of this program after the push even though I knew I had made very minor changes. That is, what would've helped was all programmer-side, not language-side. - Still, I introduced a bug and bad things happened. So also could someone edit the 'join an IRC channel' code and accidently introduce a bug that then caused a buffer overflow in that internal 'users in a channel' array. And so, even with a clear and complete understanding of your flawless IRC server, you might add some checks at some boundaries, to protect parts of it from bugs that may later get introduced by other people into other parts of it. There's a fractal here: the network devices *could* be trusted because the whole network is trusted and carefully run, and then there'd be no reason even to write in "Sorry, the channel is full" sorts of code. But you don't trust the network, and the same impulse you have to consider such 'errors' coming the network, you can repeat at deeper and deeper levels of your server. The network could be at harmony but instead the server distrusts the network and the clients all distrust the server; the server could be in harmony but instead libraries within the server distrust the code that uses them; individual libraries could be in harmony but instead functions distrust other functions within the same library. At a deep enough level your real concern with that 1DIM array word is that code from a completely different module can alter the memory space 1DMIN uses for its array, without going through proper array words or 'join a user to a channel' code or anything. The point is, Alex wrote an array word in Forth. If you're going to bother with Forth, you may as well try to get as far as you can with harmonious, fully understood, brightly-lit code. There's where the benefits lie. There's also where the deficiencies don't worry you as much. You do not whinge, for example, about not having a potentially untrustworthy array library that you'd defend your code against. You're not dropping knowledge bombs on feckless monkeys who would come out with software ridden through with buffer overflows. You just kinda come off like a tourist. Meanwhile, here is an array library with bounds checking: https://code.google.com/p/ffl/wiki/car Yes, even CAR-SET throws an exception. CAR-OFFSET does the work: https://code.google.com/p/ffl/source/browse/trunk/ffl/car.fs -- Julian http://www.catb.org/jargon/html/Z/Zero-One-Infinity-Rule.html (Wisdom that's appropriate when "I ran out of memory and crashed trying to do what you just stupidly told me to do" is an acceptable behavior. So, rarely. And never if you're writing a server.)
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-07-26 14:56 -1000 |
| Message-ID | <3pOdnbiwrdo_HCjInZ2dnUU7-LWdnZ2d@supernews.com> |
| In reply to | #40804 |
On 7/26/15 8:18 AM, Paul Rubin wrote: > "Alex McDonald" <blog@rivadpm.com> writes: >> The definition of a 1 dimensional array is trivial; perhaps that's why. >> : 1dim create cells allot does> swap cells + ; > > You're going to use arrays with no bounds checks to script potentially > hostile internet devices? Sounds dangerous to me. See, that's the point. Where error checking goes should be a function of the application design. Within the scope of the application, you can know how reliable your data is (it's a property of the device). If it's coming from a device, for example, you know exactly its range. If it's from a less reliable source, you can check the value when it enters the system (e.g., making a human user re-enter an illegal value). That kind of approach yields both improved security and improved performance. A generic definition cannot know the environment in which it will be used. 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-07-26 14:20 -0400 |
| Message-ID | <mp389r$hso$1@dont-email.me> |
| In reply to | #40803 |
On 7/26/2015 1:53 PM, Alex McDonald 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 @ + . I think that it can be argued that given the extensible nature of forth that it is better to learn to craft simple structures like these in order to help with learning how to use these principles in more complicated and useful structures. It seems like many prefer to use a language (or languages) which have already done the work of providing lower level features for any given application. While this seems like a good idea, it requires learning the new language most appropriate for every new application. Notice that Mark mentioned several languages and WJ is often giving examples in several. Is that really any better or easier than learning a single language where you can create all of these advantages at the same time? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-07-26 17:29 -0700 |
| Message-ID | <87d1zeqw7p.fsf@jester.gateway.sonic.net> |
| In reply to | #40805 |
rickman <gnuarm@gmail.com> writes:
> While this seems like a good idea, it requires learning
> the new language most appropriate for every new application....
> Is that really any better or easier than learning a single language
> where you can create all of these advantages at the same time?
Yes it is, because 1) it's impossible to create all of the advantages at
the same time, and 2) you don't need a new language for every new
application--you can reasonably call yourself a versatile programmer
with a handful of languages but not just one.
- a low level systems language like C or Forth,
- a dynamic scripting language like Python
- a typed, managed HLL for large scale development. The most widely
used of these is currently Java, which sucks, but there are starting
to be alternatives
- Subjectively I'd add a typed functional langage like ML or Haskell
just because of the way it broadens one's thought processes
- you will probably need SQL from time to time
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-08-10 22:52 +0000 |
| Message-ID | <mqb9vg$m7u$1@dont-email.me> |
| In reply to | #40810 |
Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
> > While this seems like a good idea, it requires learning
> > the new language most appropriate for every new application....
> > Is that really any better or easier than learning a single language
> > where you can create all of these advantages at the same time?
>
> Yes it is, because 1) it's impossible to create all of the advantages at
> the same time, and 2) you don't need a new language for every new
> application
Many of the Forth fanatics here are like a man who refuses
to learn to use any tool other than a hammer.
> --you can reasonably call yourself a versatile programmer
> with a handful of languages but not just one.
> - a low level systems language like C or Forth,
> - a dynamic scripting language like Python
> - a typed, managed HLL for large scale development. The most widely
> used of these is currently Java, which sucks, but there are starting
> to be alternatives
> - Subjectively I'd add a typed functional langage like ML or Haskell
> just because of the way it broadens one's thought processes
> - you will probably need SQL from time to time
Gauche Scheme:
(use srfi-13 :only (string-tokenize))
(filter
(lambda (word)
(and (rxmatch #/[[:upper:]]/ word)
(not (member (string-length word) '(3 12)))))
(string-tokenize "
- a low level systems language like C or Forth,
- a dynamic scripting language like Python
- a typed, managed HLL for large scale development. The most widely
used of these is currently Java, which sucks, but there are starting
to be alternatives
- Subjectively I'd add a typed functional langage like ML or Haskell
just because of the way it broadens one's thought processes
- you will probably need SQL from time to time"
#[[:alpha:]']))
===>
("C" "Forth" "Python" "Java" "ML" "Haskell")
What is missing?
--
I would hesitate to describe America as a nation at all in 1997,
because it is something very different: a polyethnic federation
administered by a single ruling class.... [T]he accumulated
rot in America has now reached a point where the pillars of
society itself are failing. --- Ambrose Evans-Pritchard
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-07-26 17:11 -0400 |
| Message-ID | <op.x2efs8okyfako5@localhost> |
| In reply to | #40803 |
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 [] @ + . Isn't the non-factoring of Forth words the core issue Mark is getting at? Or, perhaps, he is pointing out that everyone has forgotten Forth has or had specialty words like +! and TOGGLE . If Forth has or had *those* words, why shouldn't Forth have a word to index into arrays? 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 | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-26 22:38 +0100 |
| Message-ID | <mp3ju1$tom$1@dont-email.me> |
| In reply to | #40808 |
on 26/07/2015 22:11:25, "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: > 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 ; Not really. You're not actually factoring. 6 1dim ARRAY 8 1dim BRRAY ARRAY and BRRAY use the same code compiled in the DOES> clause. > > 10 1dim myarray > 10 0 myarray [] ! > 20 1 myarray [] ! > 0 myarray [] @ 1 myarray [] @ + . > > Isn't the non-factoring of Forth words the core issue Mark is getting > at? Just declare it as e.g. 6 1dim myarray[] . Then 10 0 myarray[] ! . > > Or, perhaps, he is pointing out that everyone has forgotten Forth has > or had specialty words like +! and TOGGLE . > > If Forth has or had *those* words, why shouldn't Forth have a word to > index into arrays? A scheme with such a generic index makes it difficult to create cell, char or other sized elements, or do simple bounds checking. The object should do that for itself. > > > Rod Pemberton >
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-07-26 15:07 -1000 |
| Message-ID | <DeWdnZrMJ7nXGSjInZ2dnUU7-fWdnZ2d@supernews.com> |
| In reply to | #40808 |
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. > Isn't the non-factoring of Forth words the core issue Mark is getting at? > > Or, perhaps, he is pointing out that everyone has forgotten Forth has or > had specialty words like +! and TOGGLE . > > If Forth has or had *those* words, why shouldn't Forth have a word to index > into arrays? Because you don't necessarily want all your arrays to have the same runtime behavior. In addition to the fact that some will be cell-wise and some byte-wise or even contain doubles or floats, some will require bounds checking and some won't, and others will be more convenient if they have more complex behaviors. 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-26 21:26 -0400 |
| Message-ID | <op.x2erm4xbyfako5@localhost> |
| In reply to | #40812 |
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. 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-26 16:49 -1000 |
| Message-ID | <wYudnZX4vb7SASjInZ2dnUU7-TWdnZ2d@supernews.com> |
| In reply to | #40813 |
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. Such functions are worth factoring and being given a clear name. The longer the phrase, the fewer instances it takes to justify being factored. This particular phrase is very short, quite unlikely to be repeated beyond the use here, and the name [] conveys absolutely nothing resembling its function (square brackets in Forth suggest immediacy). 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 01:30 -0400 |
| Message-ID | <op.x2e2wk0kyfako5@localhost> |
| In reply to | #40814 |
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? > 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? ... > 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 ... 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? 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. 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]
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web