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 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-27 20:11 +0100 |
| Message-ID | <mp5vn1$u8l$1@dont-email.me> |
| In reply to | #40848 |
on 27/07/2015 19:16:19, wrote: > On Monday, July 27, 2015 at 10:47:29 AM UTC-7, Paul Rubin wrote: >> "Alex McDonald" <blog@rivadpm.com> writes: >> > The optional wordset may be large, but the core wordset is still very >> > small. >> >> I was surprised to notice that the core wordset contains quite a bit of >> what I'd consider to be bloat, e.g. words for fancy output formatting >> that typical embedded applications would have no way to use (no text >> output device!), and that for interactive testing are at best only >> slightly useful. > > I have been saying since 2009 that Forth-200x is doomed to failure It's 2015 and it still hasn't failed (and failure of the standard needs more tightly defined than "Hugh doesn't like it"). > because it is a single language-standard that is supposed to work on > hugely differe nt targets. A better plan would be to have two versions > of Forth, and both standardized --- one for micro-controllers and one > for desktop-computers. > > The micro-controller Forth would always be cross-compiled (the > cross-compil er would be written in the desktop-computer Forth). It > would be quite minim al compared to the grossly bloated ANS-Forth > standard. It would work with d ifferent cell sizes (16-bit or 32-bit > typically). > > The desktop-computer Forth would be 64-bit and would have a lot more > suppor t for text and numerical programming. It would also be designed > specificall y to support a cross-compiler though; it would have > features not available in Forth-200x (such as being able to examine an > xt and determine what word- list it is in and whether it is immediate > or not). > > Realistically, you can't have one language standard that works on both > the 64-bit x86 and the 16-bit MSP-430 --- you are going to be a "jack > of all tr ades and a master of none" --- this is the path to failure > that Forth-200x is striding down, following closely on ANS-Forth's > heals. > I've not seen here any demand to engineer solutions based on this dual standard agenda. Is anyone interested in this as a program?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-27 13:50 +0000 |
| Message-ID | <2015Jul27.155013@mips.complang.tuwien.ac.at> |
| In reply to | #40830 |
glidedog@gmail.com writes:
>On 7/27/15 3:36 AM, Anton Ertl wrote:
>> This demonstrates why there is no built-in array word in Forth.
>
>Does it? Not sure what harm providing Alex's first-try version as built
>in would cause. It's certainly a very common use case.
On what statistics do you base this claim on? I don't use it, and I
don't remember coming across it in any advanced code I have seen from
others. To me it seems to be a common textbook example that is too
limited for general usage.
The harm in standardizing it is that it would make beginners think
that this is the way to go (of course its use in textbooks may have a
similar effect, even if the textbook explains that the example is used
to demonstrate CREATE...DOES>, not arrays). It also would bloat the
standard with another little-used definition.
>As it is newbies to Forth must first learn the create ... does> idiom,
>which is definitely not trivial in my opinion, before they can do
>something as common as using an array the way Alex shows which I think
>is a good one.
It's not a good one, because it's only benefit is if you want to write
words that access one particular array. As soon as you want to write
words that can process several aways, it's at best useless. So
newbies don't need to learn create...does> before they can use arrays.
>It took me awhile to realize that the Forth standard, by its own
>explicit declaration, is constructed to minimize the word set
>to primarily support embedded programming.
>From the Forth standard 29 Feb 2012
>"A.1.2 Scope
>The result of the effort to satisfy all of these objectives is a
>Standard arranged so that the required word set remains small. Thus ANS
>Forth can be provided for resource-constrained embedded systems." So I
>take this as the standing rationale for keeping Forth stripped down.
>
>This remark has since been removed. I don't know why. Nothing has changed.
I don't remember our discussions concerning this paragraph. However,
my point of view is that Forth-94 has failed at the objective of being
a standard for resource-constrained embedded systems. People writing
Forth systems and particularly Forth programs for resource-constrained
embedded systems tend to deviate from Forth-94 and Forth-2012 in
various ways (e.g., by using a cross-compiled system, which is not
covered in the standard, by leaving out some required words or having
them behave in non-standard ways (e.g., create...does> on flash
systems), and for programs, by using non-standard features.
OTOH, the goal of supporting such systems did influence our decisions.
E.g., it would not be easy to standardize a word (other than ALLOCATE
and RESIZE themselves) that ALLOCATEs memory. Instead, we standardize
interfaces where the caller has to provide the buffer, and then check
whether the result fits, and maybe repeat it after resizing the buffer
(i.e., totally horrible interfaces).
- 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 08:56 -0700 |
| Message-ID | <a8607910-f351-4117-90f9-4f403cc12c7f@googlegroups.com> |
| In reply to | #40839 |
On 7/27/15 9:50 AM, Anton Ertl wrote: > glidedog@gmail.com writes: >> On 7/27/15 3:36 AM, Anton Ertl wrote: >>> This demonstrates why there is no built-in array word in Forth. >> >> Does it? Not sure what harm providing Alex's first-try version as >> built in would cause. It's certainly a very common use case. > > On what statistics do you base this claim on? None. Pulled it out of thin air. Guilty. Though I know I've coded it that way before. I see a byte array in Starting Forth coded that way. Alex did it. VFX provides an array defined that way (with some VFXisms added). But point taken. > I don't use it, and I don't remember coming across it in any advanced > code I have seen from others. To me it seems to be a common textbook > example that is too limited for general usage. > > The harm in standardizing it is that it would make beginners think > that this is the way to go (of course its use in textbooks may have > a similar effect, even if the textbook explains that the example is > used to demonstrate CREATE...DOES>, not arrays). It also would bloat > the standard with another little-used definition. Yes. The minimal word set thing I've acknowledged as part of Forth's (more or less official) position as an embedded-use language. I'll take your "little-used definition" assertion on good faith. >> As it is newbies to Forth must first learn the create ... does> >> idiom, which is definitely not trivial in my opinion, before they >> can do something as common as using an array the way Alex shows >> which I think is a good one. > > It's not a good one, because it's only benefit is if you want to > write words that access one particular array. As soon as you want to > write words that can process several aways, it's at best useless. > So newbies don't need to learn create...does> before they can use > arrays. > >> It took me awhile to realize that the Forth standard, by its own >> explicit declaration, is constructed to minimize the word set to >> primarily support embedded programming. From the Forth standard 29 >> Feb 2012 "A.1.2 Scope The result of the effort to satisfy all of >> these objectives is a Standard arranged so that the required word >> set remains small. Thus ANS Forth can be provided for >> resource-constrained embedded systems." So I take this as the >> standing rationale for keeping Forth stripped down. >> >> This remark has since been removed. I don't know why. Nothing has >> changed. > > I don't remember our discussions concerning this paragraph. > However, my point of view is that Forth-94 has failed at the > objective of being a standard for resource-constrained embedded > systems. People writing Forth systems and particularly Forth > programs for resource-constrained embedded systems tend to deviate > from Forth-94 and Forth-2012 in various ways (e.g., by using a > cross-compiled system, which is not covered in the standard, by > leaving out some required words or having them behave in non-standard > ways (e.g., create...does> on flash systems), and for programs, by > using non-standard features. > > OTOH, the goal of supporting such systems did influence our > decisions. Supporting embedded systems primarily. Clearly. -Doug > E.g., it would not be easy to standardize a word (other than > ALLOCATE and RESIZE themselves) that ALLOCATEs memory. Instead, we > standardize interfaces where the caller has to provide the buffer, > and then check whether the result fits, and maybe repeat it after > resizing the buffer (i.e., totally horrible interfaces). > > - anton >
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2015-08-09 09:32 -0400 |
| Message-ID | <55c75678$0$292$14726298@news.sunsite.dk> |
| In reply to | #40843 |
On 7/27/15 11:56 AM, glidedog@gmail.com wrote:
> On 7/27/15 9:50 AM, Anton Ertl wrote:
>> glidedog@gmail.com writes:
>>> On 7/27/15 3:36 AM, Anton Ertl wrote:
>>>> This demonstrates why there is no built-in array word in
>>>> Forth.
>>>
>>> Does it? Not sure what harm providing Alex's first-try version
>>> as built in would cause. It's certainly a very common use case.
>>
>> On what statistics do you base this claim on?
>
> None. Pulled it out of thin air. Guilty. Though I know I've coded
> it that way before. I see a byte array in Starting Forth coded that
> way. Alex did it. VFX provides an array defined that way (with some
> VFXisms added). But point taken.
Since then I found this in the FSL:
: MARRAY ( n cell_size -- | -- addr ) \ monotype array
CREATE
DUP , * ALLOT
DOES> CELL+
;
It is a slight variation (allows for different sized elements) but uses
essentially the same technique.
>> I don't use it, and I don't remember coming across it in any
>> advanced code I have seen from others. To me it seems to be a
>> common textbook example that is too limited for general usage.
It appears to be a more common practice than I thought.
>> The harm in standardizing it is that it would make beginners think
>> that this is the way to go (of course its use in textbooks may
>> have a similar effect, even if the textbook explains that the
>> example is used to demonstrate CREATE...DOES>, not arrays). It
>> also would bloat the standard with another little-used definition.
>
> Yes. The minimal word set thing I've acknowledged as part of
> Forth's (more or less official) position as an embedded-use language.
> I'll take your "little-used definition" assertion on good faith.
>
>
>>> As it is newbies to Forth must first learn the create ... does>
>>> idiom, which is definitely not trivial in my opinion, before
>>> they can do something as common as using an array the way Alex
>>> shows which I think is a good one.
>>
>> It's not a good one, because it's only benefit is if you want to
>> write words that access one particular array. As soon as you want
>> to write words that can process several aways, it's at best
>> useless. So newbies don't need to learn create...does> before they
>> can use arrays.
No. I said "using an array the way Alex shows", which uses create
does>. 'Useless' is a bit too strong I think.
But after subsequently reading your thoughts about pre-defined array
words in the GForth docs I now understand your reaction. 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.
It reminded me why I don't post here much anymore.
-Doug
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-08-09 16:30 -1000 |
| Message-ID | <qqKdnfEoAuUtkVXInZ2dnUU7-V2dnZ2d@supernews.com> |
| In reply to | #41226 |
On 8/9/15 3:32 AM, Doug Hoffman wrote:
> On 7/27/15 11:56 AM, glidedog@gmail.com wrote:
>> On 7/27/15 9:50 AM, Anton Ertl wrote:
>>> glidedog@gmail.com writes:
>>>> On 7/27/15 3:36 AM, Anton Ertl wrote:
>>>>> This demonstrates why there is no built-in array word in
>>>>> Forth.
>>>>
>>>> Does it? Not sure what harm providing Alex's first-try version
>>>> as built in would cause. It's certainly a very common use case.
>>>
>>> On what statistics do you base this claim on?
>>
>> None. Pulled it out of thin air. Guilty. Though I know I've coded
>> it that way before. I see a byte array in Starting Forth coded that
>> way. Alex did it. VFX provides an array defined that way (with some
>> VFXisms added). But point taken.
>
> Since then I found this in the FSL:
>
> : MARRAY ( n cell_size -- | -- addr ) \ monotype array
> CREATE
> DUP , * ALLOT
> DOES> CELL+
> ;
>
> It is a slight variation (allows for different sized elements) but uses
> essentially the same technique.
That's a variation on common method, but it lacks several useful
features: it provides the address of the second cell in the array, but
makes no use of the cell size stored in the first cell, and leaves it to
the user to apply whatever offset in the correct units. In other words,
it's not very smart (and I think most Forth texts are a little better
than that).
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 + ;
This saves the array length in the first cell, and uses it to apply
range checking. It makes use of the standard word CELLS to handle the
cell size in address units instead of requiring the user to supply it.
The instance part also takes an index and returns the indexed cells, so
it's very useful in loops that run through the array, which is a common
need.
But, in fact, there are many applications in which the overhead for
range checking isn't required, because the design of the application
precludes the possibility of invoking the array with an invalid index
(for example, it may be in a precompiled embedded application in which
it's only referenced in loops that run through the valid range).
>>> I don't use it, and I don't remember coming across it in any
>>> advanced code I have seen from others. To me it seems to be a
>>> common textbook example that is too limited for general usage.
>
> It appears to be a more common practice than I thought.
I'd like to think "common practice" is smarter than that FSL example.
>>> The harm in standardizing it is that it would make beginners think
>>> that this is the way to go (of course its use in textbooks may
>>> have a similar effect, even if the textbook explains that the
>>> example is used to demonstrate CREATE...DOES>, not arrays). It
>>> also would bloat the standard with another little-used definition.
>>
>> Yes. The minimal word set thing I've acknowledged as part of
>> Forth's (more or less official) position as an embedded-use language.
>> I'll take your "little-used definition" assertion on good faith.
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. 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.
>>>> As it is newbies to Forth must first learn the create ... does>
>>>> idiom, which is definitely not trivial in my opinion, before
>>>> they can do something as common as using an array the way Alex
>>>> shows which I think is a good one.
>>>
>>> It's not a good one, because it's only benefit is if you want to
>>> write words that access one particular array. As soon as you want
>>> to write words that can process several arrays, it's at best
>>> useless. So newbies don't need to learn create...does> before they
>>> can use arrays.
>
> No. I said "using an array the way Alex shows", which uses create
> does>. 'Useless' is a bit too strong I think.
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.
> But after subsequently reading your thoughts about pre-defined array
> words in the GForth docs I now understand your reaction. 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'll agree with most of that.
> It reminded me why I don't post here much anymore.
That's unfortunate, though :-)
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-08-09 22:56 -0700 |
| Message-ID | <5b5b3f8c-49d3-46b5-aa2d-69884596ec1f@googlegroups.com> |
| In reply to | #41247 |
On Sunday, August 9, 2015 at 7:30:10 PM UTC-7, Elizabeth D. Rather wrote: > On 8/9/15 3:32 AM, Doug Hoffman wrote: > > Since then I found this in the FSL: > > > > : MARRAY ( n cell_size -- | -- addr ) \ monotype array > > CREATE > > DUP , * ALLOT > > DOES> CELL+ > > ; > > > > It is a slight variation (allows for different sized elements) but uses > > essentially the same technique. > > That's a variation on common method, but it lacks several useful > features: it provides the address of the second cell in the array, but > makes no use of the cell size stored in the first cell, and leaves it to > the user to apply whatever offset in the correct units. In other words, > it's not very smart (and I think most Forth texts are a little better > than that). > > 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 + ; > > This saves the array length in the first cell, and uses it to apply > range checking. It makes use of the standard word CELLS to handle the > cell size in address units instead of requiring the user to supply it. CREATE DOES> is always inefficient because the programmer commas data after the CREATE and then fetches that data in the DOES> part. This data is known at compile-time though. It is a waste of time to fetch it out of memory at run-time, especially in an array access that may be done many thousands of times. The above ARRAY is also not a general-purpose data-structure, because it requires the fields to be cells --- it should allow the user to specify the field size. In my novice package I have 1ARRAY that is significantly more efficient than Elizabeth Rather's ARRAY above, and is also general-purpose. > The instance part also takes an index and returns the indexed cells, so > it's very useful in loops that run through the array, which is a common > need. For arrays that will stepped through, it is more efficient to use my ARY. All of this code is also a lot more readable than the mess of stack juggling words that Elizabeth Rather used. I think that a big part of why Forth has failed, is because Elizabeth Rather relentlessly "teaches" Forth in a stupid way. Really, saving a constant in memory at compile-time and then fetching it out of memory at run-time with every array access is stupid --- obviously, it should be a constant rather than a variable --- this is programming-101. Elizabeth Rather makes the entire Forth community look stupid by teaching such a grossly inefficient technique and presenting it as the standard Forth idiom.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-08-10 08:53 +0000 |
| Message-ID | <2015Aug10.105346@mips.complang.tuwien.ac.at> |
| In reply to | #41247 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 8/9/15 3:32 AM, Doug Hoffman wrote:
>> Since then I found this in the FSL:
>>
>> : MARRAY ( n cell_size -- | -- addr ) \ monotype array
>> CREATE
>> DUP , * ALLOT
>> DOES> CELL+
>> ;
>>
>> It is a slight variation (allows for different sized elements) but uses
>> essentially the same technique.
>
>That's a variation on common method, but it lacks several useful
>features: it provides the address of the second cell in the array, but
>makes no use of the cell size stored in the first cell, and leaves it to
>the user to apply whatever offset in the correct units. In other words,
>it's not very smart (and I think most Forth texts are a little better
>than that).
That's what's makes this array word not as useless as most: At
run-time it provides an address that can be passed to a word that can
therefore be used to process more than one array.
>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 + ;
>
>This saves the array length in the first cell, and uses it to apply
>range checking. It makes use of the standard word CELLS to handle the
>cell size in address units instead of requiring the user to supply it.
It also includes indexing. This is an example of an at-best-useless
array word. At worst, the user might then write stuff like
5 array a
5 array b
: foo ... ?do i a i b * + loop ... ;
i.e., where the specific arrays are hard-coded into the word and you
cannot factor out the inner-product logic into a separate, generally
useful word; ok, inner product is simple, what about a cache-optimized
matrix multiplication?
>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 Forth-2012.
- 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-08-10 08:28 -1000 |
| Message-ID | <raednYX6XIv7cFXInZ2dnUU7-VOdnZ2d@supernews.com> |
| In reply to | #41254 |
On 8/9/15 10:53 PM, Anton Ertl wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> On 8/9/15 3:32 AM, Doug Hoffman wrote: >>> Since then I found this in the FSL: >>> >>> : MARRAY ( n cell_size -- | -- addr ) \ monotype array >>> CREATE >>> DUP , * ALLOT >>> DOES> CELL+ >>> ; >>> >>> It is a slight variation (allows for different sized elements) but uses >>> essentially the same technique. >> >> That's a variation on common method, but it lacks several useful >> features: it provides the address of the second cell in the array, but >> makes no use of the cell size stored in the first cell, and leaves it to >> the user to apply whatever offset in the correct units. In other words, >> it's not very smart (and I think most Forth texts are a little better >> than that). > > That's what's makes this array word not as useless as most: At > run-time it provides an address that can be passed to a word that can > therefore be used to process more than one array. That sounds like adding complexity and steps, rather than simplifying. >> 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 + ; >> >> This saves the array length in the first cell, and uses it to apply >> range checking. It makes use of the standard word CELLS to handle the >> cell size in address units instead of requiring the user to supply it. > > It also includes indexing. This is an example of an at-best-useless > array word. At worst, the user might then write stuff like > > 5 array a > 5 array b > : foo ... ?do i a i b * + loop ... ; > > i.e., where the specific arrays are hard-coded into the word and you > cannot factor out the inner-product logic into a separate, generally > useful word; ok, inner product is simple, what about a cache-optimized > matrix multiplication? Well, it really depends totally on the application. Sometimes adding the indexing is useful sometimes not. When we sit down to design an application, one of the things we look at is what kind of data structures it has and how they can best be handled in *this* application. There are a few common solutions, and occasionally totally custom ones. But this is a good illustration of why I don't like the idea of standardizing specific array definitions. >> 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 Forth-2012. Good. So, no one can say that Forth-2012 "doesn't have any arrays". Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-08-11 15:17 +0000 |
| Message-ID | <2015Aug11.171759@mips.complang.tuwien.ac.at> |
| In reply to | #41262 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 8/9/15 10:53 PM, Anton Ertl wrote:
>> "Elizabeth D. Rather" <erather@forth.com> writes:
>>> On 8/9/15 3:32 AM, Doug Hoffman wrote:
>>>> Since then I found this in the FSL:
>>>>
>>>> : MARRAY ( n cell_size -- | -- addr ) \ monotype array
>>>> CREATE
>>>> DUP , * ALLOT
>>>> DOES> CELL+
>>>> ;
>>>>
>>>> It is a slight variation (allows for different sized elements) but uses
>>>> essentially the same technique.
>>>
>>> That's a variation on common method, but it lacks several useful
>>> features: it provides the address of the second cell in the array, but
>>> makes no use of the cell size stored in the first cell, and leaves it to
>>> the user to apply whatever offset in the correct units. In other words,
>>> it's not very smart (and I think most Forth texts are a little better
>>> than that).
>>
>> That's what's makes this array word not as useless as most: At
>> run-time it provides an address that can be passed to a word that can
>> therefore be used to process more than one array.
>
>That sounds like adding complexity and steps, rather than simplifying.
True, a word AxB->C ( -- ) that just multiplies matrixes A and B, with
the result in C, is simpler in implementation than a word MAT* ( mat1
mat2 matres -- ) that can multiply matrices that are passed as
parameters on the stack (in the form of addresses).
But it's also much less versatile. If we also need to multiply DxE
giving F, the word AxB->C ( -- ) is either useless or requires
cumbersome copying of parameters into A and B, and copying the result
out of C (and that assumes that the matrices fit); plus you have to
save A,B,C before the whole operation, and restore them afterwards; i.e.,
SAVE-A SAVE-B SAVE-C D->A E->B AxB->C C->F RESTORE-A RESTORE-B RESTORE-C
Really so much simpler than D E F MAT*, no?
>> BUFFER: is Forth-2012.
>
>Good. So, no one can say that Forth-2012 "doesn't have any arrays".
Well, in that sense Forth-94 has arrays, because it has ALLOT and
ALLOCATE.
- 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-08-10 14:14 -0700 |
| Message-ID | <09fa8117-c9f9-4df3-b56c-f449e5f173f9@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 + ;
>
> This saves the array length in the first cell, and uses it to apply
> range checking. It makes use of the standard word CELLS to handle the
> cell size in address units instead of requiring the user to supply it.
> The instance part also takes an index and returns the indexed cells, so
> it's very useful in loops that run through the array, which is a common
> need.
I already pointed out the two major problems with Elizabeth Rather's code:
1.) CREATE DOES> involves comma'ing constant data into memory at compile-time, then fetching this data out of memory at run-time for every array access, which is grossly inefficient.
2.) Her ARRAY is limited to arrays of cells, so it is not a general-purpose data-structure (the user should be allowed to specify the element size).
Bizarrely, Elizabeth Rather has the index starting at 1 rather than 0 --- most likely, this is her COBOL background showing through --- she doesn't realize that programmers have been starting the index at 0 rather than 1 for the last 40 years.
Another problem with efficiency is that she has made the bounds checking over-complicated because she doesn't know about the unsigned comparisons.
Here is a more efficient definition that does the same thing (except with the index starting at 0 rather than 1):
: array ( n -- )
create dup , cells allot
does> ( index base-adr -- )
2dup @ u< 0= abort" *** ARRAY index out of range ***"
swap 1+ cells + ;
Because of the two major problems described above, my code is crap. It is not of the quality standard that would allow it to be included in the novice-package.
Although my code is crap, it is still better than the code that Elizabeth Rather wrote. Elizabeth Rather is writing Forth code in a COBOL style (index starting at 1); this is extremely low quality programming. Nobody has done this in about 40 years because it is a bad idea. Also, Elizabeth Rather doesn't know about unsigned comparisons (the U< in my code) and has consequently written some very convoluted and inefficient code to do the error-checking using signed comparisons (two < and an OR plus a lot of stack-juggling).
Elizabeth Rather is not a Forth programmer. The code she is presenting as a Forth idiom is total crap --- I would really expect better code out of anybody who has studied Forth for more than one week and who has a programming background in any language other than COBOL --- I strongly recommend that Forth students ignore Elizabeth Rather completely, as she is just an idiot sales-person pretending to be an expert on a technical subject that she knows nothing about.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-08-10 16:29 -0700 |
| Message-ID | <d8bf7f10-a4ad-4ca2-a459-74d9cb807433@googlegroups.com> |
| In reply to | #41263 |
On Monday, August 10, 2015 at 2:14:40 PM UTC-7, hughag...@gmail.com wrote: > 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 + ; > ... > Here is a more efficient definition that does the same thing (except with the index starting at 0 rather than 1): > > : array ( n -- ) > create dup , cells allot > does> ( index base-adr -- ) > 2dup @ u< 0= abort" *** ARRAY index out of range ***" > swap 1+ cells + ; Using SwiftForth Evaluation v-3.5.7, this is Elizabeth Rather's code (name changed to EARRAY): see earray 48C9AF 40FAFF ( CREATE ) CALL E84B31F8FF 48C9B4 4 # EBP SUB 83ED04 48C9B7 EBX 0 [EBP] MOV 895D00 48C9BA 40AA2F ( , ) CALL E870E0F7FF 48C9BF EBX 2 # SHL C1E302 48C9C2 40A9AF ( ALLOT ) CALL E8E8DFF7FF 48C9C7 40DA4F ( (;CODE) ) CALL E88310F8FF 48C9CC 4 # EBP SUB 83ED04 48C9CF 0 [EBP] POP 8F4500 48C9D2 4 # EBP SUB 83ED04 48C9D5 EBX 0 [EBP] MOV 895D00 48C9D8 4 [EBP] EBX MOV 8B5D04 48C9DB 0 [EBX] EBX MOV 8B1B 48C9DD 0 [EBP] EBX CMP 3B5D00 48C9E0 0 # EBX MOV BB00000000 48C9E5 48C9E8 JNL 7D01 48C9E7 EBX DEC 4B 48C9E8 4 # EBP SUB 83ED04 48C9EB EBX 0 [EBP] MOV 895D00 48C9EE 4 [EBP] EBX MOV 8B5D04 48C9F1 1 # EBX CMP 83FB01 48C9F4 0 # EBX MOV BB00000000 48C9F9 48C9FC JNL 7D01 48C9FB EBX DEC 4B 48C9FC 0 [EBP] EBX OR 0B5D00 48C9FF 4 # EBP ADD 83C504 48CA02 4076BF ( (S") ) CALL E8B8ACF7FF 48CA07 "Out of Range" 48CA15 407E9F ( ?ABORT ) CALL E885B4F7FF 48CA1A EBX 2 # SHL C1E302 48CA1D 0 [EBP] EBX ADD 035D00 48CA20 4 # EBP ADD 83C504 48CA23 RET C3 ok see (;code) 40DA4F 4 # EBP SUB 83ED04 40DA52 EBX 0 [EBP] MOV 895D00 40DA55 EBX POP 5B 40DA56 4 # EBP SUB 83ED04 40DA59 EBX 0 [EBP] MOV 895D00 40DA5C A94 [EDI] EBX MOV 8B9F940A0000 40DA62 40830F ( NAME> ) CALL E8A8A8FFFF 40DA67 5 [EDI] [EBX] EBX LEA 8D5C1F05 40DA6B EBX NEG F7DB 40DA6D 0 [EBP] EBX ADD 035D00 40DA70 4 # EBP ADD 83C504 40DA73 4 # EBP SUB 83ED04 40DA76 EBX 0 [EBP] MOV 895D00 40DA79 A94 [EDI] EBX MOV 8B9F940A0000 40DA7F 40830F ( NAME> ) CALL E88BA8FFFF 40DA84 EDI EBX ADD 01FB 40DA86 4 # EBP SUB 83ED04 40DA89 EBX 0 [EBP] MOV 895D00 40DA8C E8 # EBX MOV BBE8000000 40DA91 4 # EBP SUB 83ED04 40DA94 EBX 0 [EBP] MOV 895D00 40DA97 4 [EBP] EBX MOV 8B5D04 40DA9A 0 [EBP] EAX MOV 8B4500 40DA9D AL 0 [EBX] MOV 8803 40DA9F 4 [EBP] EBX MOV 8B5D04 40DAA2 8 # EBP ADD 83C508 40DAA5 EBX INC 43 40DAA6 0 [EBP] EAX MOV 8B4500 40DAA9 EAX 0 [EBX] MOV 8903 40DAAB 4 [EBP] EBX MOV 8B5D04 40DAAE 8 # EBP ADD 83C508 40DAB1 RET C3 ok see ?abort 407E9F EBX ECX MOV 8BCB 407EA1 4 [EBP] EBX MOV 8B5D04 407EA4 0 [EBP] EAX MOV 8B4500 407EA7 EAX 4 [EBP] MOV 894504 407EAA ECX 0 [EBP] MOV 894D00 407EAD EBX EBX OR 09DB 407EAF 0 [EBP] EBX MOV 8B5D00 407EB2 4 [EBP] EBP LEA 8D6D04 407EB5 407EC0 JZ 0F8405000000 407EBB 407E1F ( (ABORT") ) CALL E85FFFFFFF 407EC0 4 [EBP] EBX MOV 8B5D04 407EC3 8 # EBP ADD 83C508 407EC6 RET C3 ok This is my version of a CREATE DOES> solution: see array 48CA3F 40FAFF ( CREATE ) CALL E8BB30F8FF 48CA44 4 # EBP SUB 83ED04 48CA47 EBX 0 [EBP] MOV 895D00 48CA4A 40AA2F ( , ) CALL E8E0DFF7FF 48CA4F EBX 2 # SHL C1E302 48CA52 40A9AF ( ALLOT ) CALL E858DFF7FF 48CA57 40DA4F ( (;CODE) ) CALL E8F30FF8FF 48CA5C 4 # EBP SUB 83ED04 48CA5F EBX 0 [EBP] MOV 895D00 48CA62 EBX POP 5B 48CA63 8 # EBP SUB 83ED08 48CA66 EBX 4 [EBP] MOV 895D04 48CA69 8 [EBP] EAX MOV 8B4508 48CA6C EAX 0 [EBP] MOV 894500 48CA6F 0 [EBX] EBX MOV 8B1B 48CA71 405F7F ( U< ) CALL E80995F7FF 48CA76 EBX NEG F7DB 48CA78 EBX EBX SBC 19DB 48CA7A EBX NOT F7D3 48CA7C 4076BF ( (S") ) CALL E83EACF7FF 48CA81 "*** ARRAY out of range ***" 48CA9D 407E9F ( ?ABORT ) CALL E8FDB3F7FF 48CAA2 0 [EBP] EAX MOV 8B4500 48CAA5 EBX 0 [EBP] MOV 895D00 48CAA8 EAX EBX MOV 8BD8 48CAAA EBX INC 43 48CAAB EBX 2 # SHL C1E302 48CAAE 0 [EBP] EBX ADD 035D00 48CAB1 4 # EBP ADD 83C504 48CAB4 RET C3 ok see u< 405F7F EBX 0 [EBP] CMP 395D00 405F82 EBX EBX SBC 19DB 405F84 4 # EBP ADD 83C504 405F87 RET C3 ok All of the above code, using CREATE DOES>, is crap. I strongly recommend against the use of CREATE DOES> in time-critical code, especially in SwiftForth that has a very inefficient DOES> code. This is my 1ARRAY from the novice package (bounds-checking option turned on): 8 w 1array aaa ok see aaa 48E68F 4 # EBP SUB 83ED04 48E692 EBX 0 [EBP] MOV 895D00 48E695 8 # EBX MOV BB08000000 48E69A 48B55F ( check1 ) CALL E8C0CEFFFF 48E69F EBX 2 # SHL C1E302 48E6A2 48E628 # EBX ADD 81C328E64800 48E6A8 RET C3 ok see check1 48B55F 0 [EBP] EBX CMP 3B5D00 48B562 0 # EBX MOV BB00000000 48B567 48B56A JBE 7601 48B569 EBX DEC 4B 48B56A -1 # EBX XOR 83F3FF 48B56D 4076BF ( (S") ) CALL E84DC1F7FF 48B572 "*** array index 1 out of bounds ***" 48B597 407E9F ( ?ABORT ) JMP E903C9F7FF ok This is my 1ARRAY from the novice package (bounds-checking option turned off): false to bounds-check? ok 8 w 1array aaa-fast ok see aaa-fast 48E83F EBX 2 # SHL C1E302 48E842 48E7FC # EBX ADD 81C3FCE74800 48E848 RET C3 ok This is my ARY from the novice package (no bounds-checking option provided): w 0 8 ary bbb ok see bbb 48E79F 4 # EBP SUB 83ED04 48E7A2 48E76C # 0 [EBP] MOV C745006CE74800 48E7A9 EBX 2 # SHL C1E302 48E7AC 0 [EBP] EBX ADD 035D00 48E7AF 4 # EBP ADD 83C504 48E7B2 RET C3 ok
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-08-11 01:44 -0700 |
| Message-ID | <47f475e2-1c7f-4889-962f-a3522f7b6391@googlegroups.com> |
| In reply to | #41263 |
On Monday, 10 August 2015 22:14:40 UTC+1, hughag...@gmail.com wrote: > Here is a more efficient definition that does the same thing (except with the index starting at 0 rather than 1): > > : array ( n -- ) > create dup , cells allot > does> ( index base-adr -- ) > 2dup @ u< 0= abort" *** ARRAY index out of range ***" > swap 1+ cells + ; > Ha! That is officially neat code! Love it! That just made it onto my "useful snippets" disk on my hobby system. With attribution, of course :-)
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-08-11 11:09 +0100 |
| Message-ID | <mqchi1$aka$1@dont-email.me> |
| In reply to | #41275 |
on 11/08/2015 09:44:21, Mark Wills wrote:
> On Monday, 10 August 2015 22:14:40 UTC+1, hughag...@gmail.com wrote:
>> Here is a more efficient definition that does the same thing (except with the index starting at 0 rather than 1):
>>
>> : array ( n -- )
>> create dup , cells allot
>> does> ( index base-adr -- )
>> 2dup @ u< 0= abort" *** ARRAY index out of range ***"
>> swap 1+ cells + ;
>>
>
> Ha!
>
> That is officially neat code! Love it! That just made it onto my
> "useful snippets" disk on my hobby system. With attribution, of
> course :-)
>
Attribution for whom?
: 1dim create dup , cells allot
does> 2dup @ 0 within abort" index out of bounds"
swap 1+ cells + ;
I wrote the above way back in this very thread
https://groups.google.com/forum/message/raw?msg=comp.lang.forth/yTvD4nqPGA4/QW6psyQYAekJ
and Anton Ertl commented that "instead of 0 WITHIN, you can also write U<
0= (or non-standard U>=)."
Hey presto, Hugh's code. Perhaps Anton and I can get a share in the
royalties.
Unfortunately, Hugh doesn't use this code or anything like it in his
novice package, so he probably won't approve of you mentioning his name
at all.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-08-11 11:03 -0400 |
| Message-ID | <mqd2pa$ffm$1@dont-email.me> |
| In reply to | #41277 |
On 8/11/2015 6:09 AM, Alex McDonald wrote: > > Unfortunately, Hugh doesn't use this code or anything like it in his > novice package, so he probably won't approve of you mentioning his name > at all. If you do mention a name, don't say it three times.... -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-08-11 08:08 -0700 |
| Message-ID | <801c14f4-4743-476b-8320-132a86b15078@googlegroups.com> |
| In reply to | #41277 |
On Tuesday, 11 August 2015 11:09:42 UTC+1, Alex McDonald wrote: > on 11/08/2015 09:44:21, Mark Wills wrote: > > On Monday, 10 August 2015 22:14:40 UTC+1, hughag...@gmail.com wrote: > >> Here is a more efficient definition that does the same thing (except with the index starting at 0 rather than 1): > >> > >> : array ( n -- ) > >> create dup , cells allot > >> does> ( index base-adr -- ) > >> 2dup @ u< 0= abort" *** ARRAY index out of range ***" > >> swap 1+ cells + ; > >> > > > > Ha! > > > > That is officially neat code! Love it! That just made it onto my > > "useful snippets" disk on my hobby system. With attribution, of > > course :-) > > > > Attribution for whom? > > : 1dim create dup , cells allot > does> 2dup @ 0 within abort" index out of bounds" > swap 1+ cells + ; > > I wrote the above way back in this very thread > https://groups.google.com/forum/message/raw?msg=comp.lang.forth/yTvD4nqPGA4/QW6psyQYAekJ > and Anton Ertl commented that "instead of 0 WITHIN, you can also write U< > 0= (or non-standard U>=)." > > Hey presto, Hugh's code. Perhaps Anton and I can get a share in the > royalties. > > Unfortunately, Hugh doesn't use this code or anything like it in his > novice package, so he probably won't approve of you mentioning his name > at all. Oh the dilemma's of attribution. I'll just say I wrote it :-)
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-08-11 17:21 +0100 |
| Message-ID | <mqd7c3$439$1@dont-email.me> |
| In reply to | #41286 |
on 11/08/2015 16:08:15, Mark Wills wrote: > On Tuesday, 11 August 2015 11:09:42 UTC+1, Alex McDonald wrote: >> on 11/08/2015 09:44:21, Mark Wills wrote: >> > On Monday, 10 August 2015 22:14:40 UTC+1, hughag...@gmail.com wrote: >> >> Here is a more efficient definition that does the same thing (except with the index starting at 0 rather than 1): >> >> >> >> : array ( n -- ) >> >> create dup , cells allot >> >> does> ( index base-adr -- ) >> >> 2dup @ u< 0= abort" *** ARRAY index out of range ***" >> >> swap 1+ cells + ; >> >> >> > >> > Ha! >> > >> > That is officially neat code! Love it! That just made it onto my >> > "useful snippets" disk on my hobby system. With attribution, of >> > course :-) >> > >> >> Attribution for whom? >> >> : 1dim create dup , cells allot >> does> 2dup @ 0 within abort" index out of bounds" >> swap 1+ cells + ; >> >> I wrote the above way back in this very thread >> https://groups.google.com/forum/message/raw?msg=comp.lang.forth/yTvD4nqPGA4/QW6psyQYAekJ >> and Anton Ertl commented that "instead of 0 WITHIN, you can also write U< >> 0= (or non-standard U>=)." >> >> Hey presto, Hugh's code. Perhaps Anton and I can get a share in the >> royalties. >> >> Unfortunately, Hugh doesn't use this code or anything like it in his >> novice package, so he probably won't approve of you mentioning his name >> at all. > > Oh the dilemma's of attribution. I'll just say I wrote it :-) > Copyright is funny stuff. Even posts like this have copyright associated with them. One of the interesting things about this particular code is how few sensible variants it permits. I suspect that most programmers would arrive at roughly the same solution given the brief of "write a word that defines a fixed 1 dimensional array and does bounds checking".
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-08-11 22:05 -0700 |
| Message-ID | <88e9174d-d5d1-4a22-b89f-8dc5b1ed15e5@googlegroups.com> |
| In reply to | #41275 |
On Tuesday, August 11, 2015 at 1:44:24 AM UTC-7, Mark Wills wrote:
> On Monday, 10 August 2015 22:14:40 UTC+1, hughag...@gmail.com wrote:
> > Here is a more efficient definition that does the same thing (except with the index starting at 0 rather than 1):
> >
> > : array ( n -- )
> > create dup , cells allot
> > does> ( index base-adr -- )
> > 2dup @ u< 0= abort" *** ARRAY index out of range ***"
> > swap 1+ cells + ;
> >
>
> Ha!
>
> That is officially neat code! Love it! That just made it onto my
> "useful snippets" disk on my hobby system. With attribution, of
> course :-)
You don't have to attribute that to me. It was a demonstration of how a student with one week of experience would write an array defining word. As I said before, this code is not of the quality level that would get it into the novice package.
Any use of CREATE DOES> is going to be inefficient. This is because data is comma'd into memory at compile-time and then fetched out at run-time. This data is known at compile-time and it is immutable, so it shouldn't be stored in memory like mutable data but should just be a literal value in the code.
A one-dimensional array isn't a very good demonstration of this problem because no data needs to be comma'd in (except for the size that is used in bounds-checking). The problem is more apparent in a multi-dimensional array because the size of every dimension (except the last) needs to be held.
If the size of the array element can be set by the programmer (making the array general-purpose), then this size also has to be stored, and the problem becomes apparent. This is most likely why Elizabeth Rather restricts her array to only work with cells --- so the size of the element is fixed at one cell and the multiplication by the size is hidden inside of CELLS --- this is a pretty gross limitation though, that was done purely for the purpose of keeping the code simplistic for teaching purposes.
In the novice-package I have an example of how a student with one week of experience would write a three-dimensional array defining word:
: 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
\ SLOW-3ARRAY is provided for comparison with 3ARRAY.
\ In SwiftForth, an array access is 1+44=45 instructions long with two CALL instructions.
\ By comparison, my 3ARRAY is 19 instructions long with one CALL instruction.
I wrote that years ago when I was using SwiftForth-v2. Nothing has changed in SwiftForth-v3. Here is the code:
Here is the code for SLOW-3ARRAY. When the array gets called with CALL, it then does a CALL to the code after the (;CODE) --- that is why I say that there are two CALL instructions.
see slow-3array
48BF2F 40FAFF ( CREATE ) CALL E8CB3BF8FF
48BF34 4 # EBP SUB 83ED04
48BF37 EBX 0 [EBP] MOV 895D00
48BF3A 40AA2F ( , ) CALL E8F0EAF7FF
48BF3F EBX PUSH 53
48BF40 0 [EBP] EBX MOV 8B5D00
48BF43 4 # EBP ADD 83C504
48BF46 EBX ECX MOV 8BCB
48BF48 4 [EBP] EBX MOV 8B5D04
48BF4B 0 [EBP] EAX MOV 8B4500
48BF4E EAX 4 [EBP] MOV 894504
48BF51 ECX 0 [EBP] MOV 894D00
48BF54 4 # EBP SUB 83ED04
48BF57 EBX 0 [EBP] MOV 895D00
48BF5A EBX POP 5B
48BF5B 0 [EBP] EAX MOV 8B4500
48BF5E EBX MUL F7E3
48BF60 EAX EBX MOV 8BD8
48BF62 4 # EBP ADD 83C504
48BF65 4 # EBP SUB 83ED04
48BF68 EBX 0 [EBP] MOV 895D00
48BF6B 40AA2F ( , ) CALL E8BFEAF7FF
48BF70 EBX ECX MOV 8BCB
48BF72 4 [EBP] EBX MOV 8B5D04
48BF75 0 [EBP] EAX MOV 8B4500
48BF78 EAX 4 [EBP] MOV 894504
48BF7B ECX 0 [EBP] MOV 894D00
48BF7E 0 [EBP] EAX MOV 8B4500
48BF81 EBX MUL F7E3
48BF83 EAX EBX MOV 8BD8
48BF85 4 # EBP ADD 83C504
48BF88 4 # EBP SUB 83ED04
48BF8B EBX 0 [EBP] MOV 895D00
48BF8E 40AA2F ( , ) CALL E89CEAF7FF
48BF93 0 [EBP] EAX MOV 8B4500
48BF96 EBX MUL F7E3
48BF98 EAX EBX MOV 8BD8
48BF9A 4 # EBP ADD 83C504
48BF9D 40A9AF ( ALLOT ) CALL E80DEAF7FF
48BFA2 40DA4F ( (;CODE) ) CALL E8A81AF8FF
48BFA7 4 # EBP SUB 83ED04
48BFAA EBX 0 [EBP] MOV 895D00
48BFAD EBX POP 5B
48BFAE EBX PUSH 53
48BFAF 8 # EBX ADD 83C308
48BFB2 0 [EBX] EBX MOV 8B1B
48BFB4 0 [EBP] EAX MOV 8B4500
48BFB7 EBX MUL F7E3
48BFB9 EAX EBX MOV 8BD8
48BFBB 4 # EBP ADD 83C504
48BFBE 0 [EBP] EAX MOV 8B4500
48BFC1 EBX 0 [EBP] MOV 895D00
48BFC4 EAX EBX MOV 8BD8
48BFC6 4 # EBP SUB 83ED04
48BFC9 EBX 0 [EBP] MOV 895D00
48BFCC 0 [ESP] EBX MOV 8B1C24
48BFCF 4 # EBX ADD 83C304
48BFD2 0 [EBX] EBX MOV 8B1B
48BFD4 0 [EBP] EAX MOV 8B4500
48BFD7 EBX MUL F7E3
48BFD9 EAX EBX MOV 8BD8
48BFDB 4 # EBP ADD 83C504
48BFDE 0 [EBP] EBX ADD 035D00
48BFE1 4 # EBP ADD 83C504
48BFE4 0 [EBP] EAX MOV 8B4500
48BFE7 EBX 0 [EBP] MOV 895D00
48BFEA EAX EBX MOV 8BD8
48BFEC 4 # EBP SUB 83ED04
48BFEF EBX 0 [EBP] MOV 895D00
48BFF2 0 [ESP] EBX MOV 8B1C24
48BFF5 0 [EBX] EBX MOV 8B1B
48BFF7 0 [EBP] EAX MOV 8B4500
48BFFA EBX MUL F7E3
48BFFC EAX EBX MOV 8BD8
48BFFE 4 # EBP ADD 83C504
48C001 0 [EBP] EBX ADD 035D00
48C004 4 # EBP ADD 83C504
48C007 4 # EBP SUB 83ED04
48C00A EBX 0 [EBP] MOV 895D00
48C00D EBX POP 5B
48C00E C # EBX ADD 83C30C
48C011 0 [EBP] EBX ADD 035D00
48C014 4 # EBP ADD 83C504
48C017 RET C3 ok
Here is the same thing defined with 3ARRAY for efficiency:
false to bounds-check? ok
10 10 10 16 3array aaa ok
see aaa
49646F 640 # EAX MOV B840060000
496474 EBX MUL F7E3
496476 EAX EBX MOV 8BD8
496478 0 [EBP] EAX MOV 8B4500
49647B EBX 0 [EBP] MOV 895D00
49647E EAX EBX MOV 8BD8
496480 A0 # EAX MOV B8A0000000
496485 EBX MUL F7E3
496487 EAX EBX MOV 8BD8
496489 0 [EBP] EBX ADD 035D00
49648C 4 # EBP ADD 83C504
49648F 0 [EBP] EAX MOV 8B4500
496492 EBX 0 [EBP] MOV 895D00
496495 EAX EBX MOV 8BD8
496497 EBX 4 # SHL C1E304
49649A 0 [EBP] EBX ADD 035D00
49649D 4 # EBP ADD 83C504
4964A0 4925D0 # EBX ADD 81C3D0254900
4964A6 RET C3 ok
Here is the same thing defined with ARY instead:
16 0 10 10 10 ary vvv ok
see vvv
49A5CF 4 # EBP SUB 83ED04
49A5D2 496580 # 0 [EBP] MOV C7450080654900
49A5D9 EBX 2 # SHL C1E302
49A5DC 0 [EBP] EBX ADD 035D00
49A5DF 4 # EBP ADD 83C504
49A5E2 0 [EBX] EAX MOV 8B03
49A5E4 0 [EBP] EBX MOV 8B5D00
49A5E7 EAX 0 [EBP] MOV 894500
49A5EA EBX 2 # SHL C1E302
49A5ED 0 [EBP] EBX ADD 035D00
49A5F0 4 # EBP ADD 83C504
49A5F3 0 [EBX] EAX MOV 8B03
49A5F5 0 [EBP] EBX MOV 8B5D00
49A5F8 EAX 0 [EBP] MOV 894500
49A5FB EBX 4 # SHL C1E304
49A5FE 0 [EBP] EBX ADD 035D00
49A601 4 # EBP ADD 83C504
49A604 RET C3 ok
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-08-12 05:50 -0700 |
| Message-ID | <16a0894c-48df-43ea-9a0d-ce1ed962d9e8@googlegroups.com> |
| In reply to | #41293 |
On Wednesday, 12 August 2015 06:05:31 UTC+1, hughag...@gmail.com wrote: > On Tuesday, August 11, 2015 at 1:44:24 AM UTC-7, Mark Wills wrote: > > On Monday, 10 August 2015 22:14:40 UTC+1, hughag...@gmail.com wrote: > > > Here is a more efficient definition that does the same thing (except with the index starting at 0 rather than 1): > > > > > > : array ( n -- ) > > > create dup , cells allot > > > does> ( index base-adr -- ) > > > 2dup @ u< 0= abort" *** ARRAY index out of range ***" > > > swap 1+ cells + ; > > > > > > > Ha! > > > > That is officially neat code! Love it! That just made it onto my > > "useful snippets" disk on my hobby system. With attribution, of > > course :-) > > You don't have to attribute that to me. It was a demonstration of how a student with one week of experience would write an array defining word. As I said before, this code is not of the quality level that would get it into the novice package. > > Any use of CREATE DOES> is going to be inefficient. This is because data is comma'd into memory at compile-time and then fetched out at run-time. This data is known at compile-time and it is immutable, so it shouldn't be stored in memory like mutable data but should just be a literal value in the code. > > A one-dimensional array isn't a very good demonstration of this problem because no data needs to be comma'd in (except for the size that is used in bounds-checking). The problem is more apparent in a multi-dimensional array because the size of every dimension (except the last) needs to be held. > > If the size of the array element can be set by the programmer (making the array general-purpose), then this size also has to be stored, and the problem becomes apparent. This is most likely why Elizabeth Rather restricts her array to only work with cells --- so the size of the element is fixed at one cell and the multiplication by the size is hidden inside of CELLS --- this is a pretty gross limitation though, that was done purely for the purpose of keeping the code simplistic for teaching purposes. > > In the novice-package I have an example of how a student with one week of experience would write a three-dimensional array defining word: > > : 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 > > \ SLOW-3ARRAY is provided for comparison with 3ARRAY. > \ In SwiftForth, an array access is 1+44=45 instructions long with two CALL instructions. > \ By comparison, my 3ARRAY is 19 instructions long with one CALL instruction. > > I wrote that years ago when I was using SwiftForth-v2. Nothing has changed in SwiftForth-v3. Here is the code: > > Here is the code for SLOW-3ARRAY. When the array gets called with CALL, it then does a CALL to the code after the (;CODE) --- that is why I say that there are two CALL instructions. > > see slow-3array > 48BF2F 40FAFF ( CREATE ) CALL E8CB3BF8FF > 48BF34 4 # EBP SUB 83ED04 > 48BF37 EBX 0 [EBP] MOV 895D00 > 48BF3A 40AA2F ( , ) CALL E8F0EAF7FF > 48BF3F EBX PUSH 53 > 48BF40 0 [EBP] EBX MOV 8B5D00 > 48BF43 4 # EBP ADD 83C504 > 48BF46 EBX ECX MOV 8BCB > 48BF48 4 [EBP] EBX MOV 8B5D04 > 48BF4B 0 [EBP] EAX MOV 8B4500 > 48BF4E EAX 4 [EBP] MOV 894504 > 48BF51 ECX 0 [EBP] MOV 894D00 > 48BF54 4 # EBP SUB 83ED04 > 48BF57 EBX 0 [EBP] MOV 895D00 > 48BF5A EBX POP 5B > 48BF5B 0 [EBP] EAX MOV 8B4500 > 48BF5E EBX MUL F7E3 > 48BF60 EAX EBX MOV 8BD8 > 48BF62 4 # EBP ADD 83C504 > 48BF65 4 # EBP SUB 83ED04 > 48BF68 EBX 0 [EBP] MOV 895D00 > 48BF6B 40AA2F ( , ) CALL E8BFEAF7FF > 48BF70 EBX ECX MOV 8BCB > 48BF72 4 [EBP] EBX MOV 8B5D04 > 48BF75 0 [EBP] EAX MOV 8B4500 > 48BF78 EAX 4 [EBP] MOV 894504 > 48BF7B ECX 0 [EBP] MOV 894D00 > 48BF7E 0 [EBP] EAX MOV 8B4500 > 48BF81 EBX MUL F7E3 > 48BF83 EAX EBX MOV 8BD8 > 48BF85 4 # EBP ADD 83C504 > 48BF88 4 # EBP SUB 83ED04 > 48BF8B EBX 0 [EBP] MOV 895D00 > 48BF8E 40AA2F ( , ) CALL E89CEAF7FF > 48BF93 0 [EBP] EAX MOV 8B4500 > 48BF96 EBX MUL F7E3 > 48BF98 EAX EBX MOV 8BD8 > 48BF9A 4 # EBP ADD 83C504 > 48BF9D 40A9AF ( ALLOT ) CALL E80DEAF7FF > 48BFA2 40DA4F ( (;CODE) ) CALL E8A81AF8FF > 48BFA7 4 # EBP SUB 83ED04 > 48BFAA EBX 0 [EBP] MOV 895D00 > 48BFAD EBX POP 5B > 48BFAE EBX PUSH 53 > 48BFAF 8 # EBX ADD 83C308 > 48BFB2 0 [EBX] EBX MOV 8B1B > 48BFB4 0 [EBP] EAX MOV 8B4500 > 48BFB7 EBX MUL F7E3 > 48BFB9 EAX EBX MOV 8BD8 > 48BFBB 4 # EBP ADD 83C504 > 48BFBE 0 [EBP] EAX MOV 8B4500 > 48BFC1 EBX 0 [EBP] MOV 895D00 > 48BFC4 EAX EBX MOV 8BD8 > 48BFC6 4 # EBP SUB 83ED04 > 48BFC9 EBX 0 [EBP] MOV 895D00 > 48BFCC 0 [ESP] EBX MOV 8B1C24 > 48BFCF 4 # EBX ADD 83C304 > 48BFD2 0 [EBX] EBX MOV 8B1B > 48BFD4 0 [EBP] EAX MOV 8B4500 > 48BFD7 EBX MUL F7E3 > 48BFD9 EAX EBX MOV 8BD8 > 48BFDB 4 # EBP ADD 83C504 > 48BFDE 0 [EBP] EBX ADD 035D00 > 48BFE1 4 # EBP ADD 83C504 > 48BFE4 0 [EBP] EAX MOV 8B4500 > 48BFE7 EBX 0 [EBP] MOV 895D00 > 48BFEA EAX EBX MOV 8BD8 > 48BFEC 4 # EBP SUB 83ED04 > 48BFEF EBX 0 [EBP] MOV 895D00 > 48BFF2 0 [ESP] EBX MOV 8B1C24 > 48BFF5 0 [EBX] EBX MOV 8B1B > 48BFF7 0 [EBP] EAX MOV 8B4500 > 48BFFA EBX MUL F7E3 > 48BFFC EAX EBX MOV 8BD8 > 48BFFE 4 # EBP ADD 83C504 > 48C001 0 [EBP] EBX ADD 035D00 > 48C004 4 # EBP ADD 83C504 > 48C007 4 # EBP SUB 83ED04 > 48C00A EBX 0 [EBP] MOV 895D00 > 48C00D EBX POP 5B > 48C00E C # EBX ADD 83C30C > 48C011 0 [EBP] EBX ADD 035D00 > 48C014 4 # EBP ADD 83C504 > 48C017 RET C3 ok > > > Here is the same thing defined with 3ARRAY for efficiency: > > false to bounds-check? ok > 10 10 10 16 3array aaa ok > see aaa > 49646F 640 # EAX MOV B840060000 > 496474 EBX MUL F7E3 > 496476 EAX EBX MOV 8BD8 > 496478 0 [EBP] EAX MOV 8B4500 > 49647B EBX 0 [EBP] MOV 895D00 > 49647E EAX EBX MOV 8BD8 > 496480 A0 # EAX MOV B8A0000000 > 496485 EBX MUL F7E3 > 496487 EAX EBX MOV 8BD8 > 496489 0 [EBP] EBX ADD 035D00 > 49648C 4 # EBP ADD 83C504 > 49648F 0 [EBP] EAX MOV 8B4500 > 496492 EBX 0 [EBP] MOV 895D00 > 496495 EAX EBX MOV 8BD8 > 496497 EBX 4 # SHL C1E304 > 49649A 0 [EBP] EBX ADD 035D00 > 49649D 4 # EBP ADD 83C504 > 4964A0 4925D0 # EBX ADD 81C3D0254900 > 4964A6 RET C3 ok > > > Here is the same thing defined with ARY instead: > > 16 0 10 10 10 ary vvv ok > see vvv > 49A5CF 4 # EBP SUB 83ED04 > 49A5D2 496580 # 0 [EBP] MOV C7450080654900 > 49A5D9 EBX 2 # SHL C1E302 > 49A5DC 0 [EBP] EBX ADD 035D00 > 49A5DF 4 # EBP ADD 83C504 > 49A5E2 0 [EBX] EAX MOV 8B03 > 49A5E4 0 [EBP] EBX MOV 8B5D00 > 49A5E7 EAX 0 [EBP] MOV 894500 > 49A5EA EBX 2 # SHL C1E302 > 49A5ED 0 [EBP] EBX ADD 035D00 > 49A5F0 4 # EBP ADD 83C504 > 49A5F3 0 [EBX] EAX MOV 8B03 > 49A5F5 0 [EBP] EBX MOV 8B5D00 > 49A5F8 EAX 0 [EBP] MOV 894500 > 49A5FB EBX 4 # SHL C1E304 > 49A5FE 0 [EBP] EBX ADD 035D00 > 49A601 4 # EBP ADD 83C504 > 49A604 RET C3 ok I see both 3array ary, as well as being a lot shorter, also contain zero calls. Neat.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-08-12 18:02 +0100 |
| Message-ID | <mqfu4a$hme$1@dont-email.me> |
| In reply to | #41295 |
on 12/08/2015 13:50:09, Mark Wills wrote: > On Wednesday, 12 August 2015 06:05:31 UTC+1, hughag...@gmail.com > > wrote: >> On Tuesday, August 11, 2015 at 1:44:24 AM UTC-7, Mark Wills wrote: > > wrote: >> > On Monday, 10 August 2015 22:14:40 UTC+1, hughag...@gmail.com wrote: > > wrote: >> > > Here is a more efficient definition that does the same thing (except > wrote: with the index starting at 0 rather than 1): >> > > >> > > : array ( n -- ) >> > > create dup , cells allot >> > > does> ( index base-adr -- ) >> > > 2dup @ u< 0= abort" *** ARRAY index out of range ***" >> > > swap 1+ cells + ; >> > > >> > >> > Ha! >> > >> > That is officially neat code! Love it! That just made it onto my >> > "useful snippets" disk on my hobby system. With attribution, of >> > course :-) >> >> You don't have to attribute that to me. It was a demonstration of how a s > tudent with one week of experience would write an array defining word. > As I said before, this code is not of the quality level that would get > it into the novice package. >> >> Any use of CREATE DOES> is going to be inefficient. This is because data > is comma'd into memory at compile-time and then fetched out at > run-time. Th is data is known at compile-time and it is immutable, so > it shouldn't be st ored in memory like mutable data but should just be > a literal value in the code. >> >> A one-dimensional array isn't a very good demonstration of this problem b > ecause no data needs to be comma'd in (except for the size that is > used in bounds-checking). The problem is more apparent in a > multi-dimensional array because the size of every dimension (except > > the last) needs to be held. >> > > the last) needs to be held. >> If the size of the array element can be set by the programmer (making the > the last) needs to be held. array general-purpose), then this size > also has to be stored, and the prob lem becomes apparent. This is most > likely why Elizabeth Rather restricts he r array to only work with > cells --- so the size of the element is fixed at one cell and the > multiplication by the size is hidden inside of CELLS --- t his is a > pretty gross limitation though, that was done purely for the purpo se > > of keeping the code simplistic for teaching purposes. >> > > of keeping the code simplistic for teaching purposes. >> In the novice-package I have an example of how a student with one week of > of keeping the code simplistic for teaching purposes. experience would > > write a three-dimensional array defining word: >> > > write a three-dimensional array defining word: >> : slow-3array ( dim1 dim2 dim3 siz1 -- ) > > write a three-dimensional array defining word: >> create > > write a three-dimensional array defining word: >> dup , \ -- dim1 dim2 dim3 s > write a three-dimensional array defining word: iz1 -- >> >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 >> >> \ SLOW-3ARRAY is provided for comparison with 3ARRAY. >> \ In SwiftForth, an array access is 1+44=45 instructions long with two > CALL instructions. >> \ By comparison, my 3ARRAY is 19 instructions long with one CALL instruct > ion. >> >> I wrote that years ago when I was using SwiftForth-v2. Nothing has change > d in SwiftForth-v3. Here is the code: >> >> Here is the code for SLOW-3ARRAY. When the array gets called with CALL, i > t then does a CALL to the code after the (;CODE) --- that is why I say > that there are two CALL instructions. >> >> see slow-3array >> 48BF2F 40FAFF ( CREATE ) CALL E8CB3BF8FF >> 48BF34 4 # EBP SUB 83ED04 >> 48BF37 EBX 0 [EBP] MOV 895D00 >> 48BF3A 40AA2F ( , ) CALL E8F0EAF7FF >> 48BF3F EBX PUSH 53 >> 48BF40 0 [EBP] EBX MOV 8B5D00 >> 48BF43 4 # EBP ADD 83C504 >> 48BF46 EBX ECX MOV 8BCB >> 48BF48 4 [EBP] EBX MOV 8B5D04 >> 48BF4B 0 [EBP] EAX MOV 8B4500 >> 48BF4E EAX 4 [EBP] MOV 894504 >> 48BF51 ECX 0 [EBP] MOV 894D00 >> 48BF54 4 # EBP SUB 83ED04 >> 48BF57 EBX 0 [EBP] MOV 895D00 >> 48BF5A EBX POP 5B >> 48BF5B 0 [EBP] EAX MOV 8B4500 >> 48BF5E EBX MUL F7E3 >> 48BF60 EAX EBX MOV 8BD8 >> 48BF62 4 # EBP ADD 83C504 >> 48BF65 4 # EBP SUB 83ED04 >> 48BF68 EBX 0 [EBP] MOV 895D00 >> 48BF6B 40AA2F ( , ) CALL E8BFEAF7FF >> 48BF70 EBX ECX MOV 8BCB >> 48BF72 4 [EBP] EBX MOV 8B5D04 >> 48BF75 0 [EBP] EAX MOV 8B4500 >> 48BF78 EAX 4 [EBP] MOV 894504 >> 48BF7B ECX 0 [EBP] MOV 894D00 >> 48BF7E 0 [EBP] EAX MOV 8B4500 >> 48BF81 EBX MUL F7E3 >> 48BF83 EAX EBX MOV 8BD8 >> 48BF85 4 # EBP ADD 83C504 >> 48BF88 4 # EBP SUB 83ED04 >> 48BF8B EBX 0 [EBP] MOV 895D00 >> 48BF8E 40AA2F ( , ) CALL E89CEAF7FF >> 48BF93 0 [EBP] EAX MOV 8B4500 >> 48BF96 EBX MUL F7E3 >> 48BF98 EAX EBX MOV 8BD8 >> 48BF9A 4 # EBP ADD 83C504 >> 48BF9D 40A9AF ( ALLOT ) CALL E80DEAF7FF >> 48BFA2 40DA4F ( (;CODE) ) CALL E8A81AF8FF >> 48BFA7 4 # EBP SUB 83ED04 >> 48BFAA EBX 0 [EBP] MOV 895D00 >> 48BFAD EBX POP 5B >> 48BFAE EBX PUSH 53 >> 48BFAF 8 # EBX ADD 83C308 >> 48BFB2 0 [EBX] EBX MOV 8B1B >> 48BFB4 0 [EBP] EAX MOV 8B4500 >> 48BFB7 EBX MUL F7E3 >> 48BFB9 EAX EBX MOV 8BD8 >> 48BFBB 4 # EBP ADD 83C504 >> 48BFBE 0 [EBP] EAX MOV 8B4500 >> 48BFC1 EBX 0 [EBP] MOV 895D00 >> 48BFC4 EAX EBX MOV 8BD8 >> 48BFC6 4 # EBP SUB 83ED04 >> 48BFC9 EBX 0 [EBP] MOV 895D00 >> 48BFCC 0 [ESP] EBX MOV 8B1C24 >> 48BFCF 4 # EBX ADD 83C304 >> 48BFD2 0 [EBX] EBX MOV 8B1B >> 48BFD4 0 [EBP] EAX MOV 8B4500 >> 48BFD7 EBX MUL F7E3 >> 48BFD9 EAX EBX MOV 8BD8 >> 48BFDB 4 # EBP ADD 83C504 >> 48BFDE 0 [EBP] EBX ADD 035D00 >> 48BFE1 4 # EBP ADD 83C504 >> 48BFE4 0 [EBP] EAX MOV 8B4500 >> 48BFE7 EBX 0 [EBP] MOV 895D00 >> 48BFEA EAX EBX MOV 8BD8 >> 48BFEC 4 # EBP SUB 83ED04 >> 48BFEF EBX 0 [EBP] MOV 895D00 >> 48BFF2 0 [ESP] EBX MOV 8B1C24 >> 48BFF5 0 [EBX] EBX MOV 8B1B >> 48BFF7 0 [EBP] EAX MOV 8B4500 >> 48BFFA EBX MUL F7E3 >> 48BFFC EAX EBX MOV 8BD8 >> 48BFFE 4 # EBP ADD 83C504 >> 48C001 0 [EBP] EBX ADD 035D00 >> 48C004 4 # EBP ADD 83C504 >> 48C007 4 # EBP SUB 83ED04 >> 48C00A EBX 0 [EBP] MOV 895D00 >> 48C00D EBX POP 5B >> 48C00E C # EBX ADD 83C30C >> 48C011 0 [EBP] EBX ADD 035D00 >> 48C014 4 # EBP ADD 83C504 >> 48C017 RET C3 ok >> >> >> Here is the same thing defined with 3ARRAY for efficiency: >> >> false to bounds-check? ok >> 10 10 10 16 3array aaa ok >> see aaa >> 49646F 640 # EAX MOV B840060000 >> 496474 EBX MUL F7E3 >> 496476 EAX EBX MOV 8BD8 >> 496478 0 [EBP] EAX MOV 8B4500 >> 49647B EBX 0 [EBP] MOV 895D00 >> 49647E EAX EBX MOV 8BD8 >> 496480 A0 # EAX MOV B8A0000000 >> 496485 EBX MUL F7E3 >> 496487 EAX EBX MOV 8BD8 >> 496489 0 [EBP] EBX ADD 035D00 >> 49648C 4 # EBP ADD 83C504 >> 49648F 0 [EBP] EAX MOV 8B4500 >> 496492 EBX 0 [EBP] MOV 895D00 >> 496495 EAX EBX MOV 8BD8 >> 496497 EBX 4 # SHL C1E304 >> 49649A 0 [EBP] EBX ADD 035D00 >> 49649D 4 # EBP ADD 83C504 >> 4964A0 4925D0 # EBX ADD 81C3D0254900 >> 4964A6 RET C3 ok >> >> >> Here is the same thing defined with ARY instead: >> >> 16 0 10 10 10 ary vvv ok >> see vvv >> 49A5CF 4 # EBP SUB 83ED04 >> 49A5D2 496580 # 0 [EBP] MOV C7450080654900 >> 49A5D9 EBX 2 # SHL C1E302 >> 49A5DC 0 [EBP] EBX ADD 035D00 >> 49A5DF 4 # EBP ADD 83C504 >> 49A5E2 0 [EBX] EAX MOV 8B03 >> 49A5E4 0 [EBP] EBX MOV 8B5D00 >> 49A5E7 EAX 0 [EBP] MOV 894500 >> 49A5EA EBX 2 # SHL C1E302 >> 49A5ED 0 [EBP] EBX ADD 035D00 >> 49A5F0 4 # EBP ADD 83C504 >> 49A5F3 0 [EBX] EAX MOV 8B03 >> 49A5F5 0 [EBP] EBX MOV 8B5D00 >> 49A5F8 EAX 0 [EBP] MOV 894500 >> 49A5FB EBX 4 # SHL C1E304 >> 49A5FE 0 [EBP] EBX ADD 035D00 >> 49A601 4 # EBP ADD 83C504 >> 49A604 RET C3 ok > > I see both 3array ary, as well as being a lot shorter, also > contain zero calls. Neat. > I detect a certain amount of comparing chalk and cheese here. Look at what is being SEEn; the first is not comparable to the second two. Plus, it's pretty badly written code and could be a whole lot simpler -- and hence much shorter -- given some thought.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-08-12 05:51 -0700 |
| Message-ID | <744d20b1-3686-4eb7-8014-7749929110cd@googlegroups.com> |
| In reply to | #41293 |
On Wednesday, 12 August 2015 06:05:31 UTC+1, hughag...@gmail.com wrote: > On Tuesday, August 11, 2015 at 1:44:24 AM UTC-7, Mark Wills wrote: > > On Monday, 10 August 2015 22:14:40 UTC+1, hughag...@gmail.com wrote: > > > Here is a more efficient definition that does the same thing (except with the index starting at 0 rather than 1): > > > > > > : array ( n -- ) > > > create dup , cells allot > > > does> ( index base-adr -- ) > > > 2dup @ u< 0= abort" *** ARRAY index out of range ***" > > > swap 1+ cells + ; > > > > > > > Ha! > > > > That is officially neat code! Love it! That just made it onto my > > "useful snippets" disk on my hobby system. With attribution, of > > course :-) > > You don't have to attribute that to me. It was a demonstration of how a student with one week of experience would write an array defining word. As I said before, this code is not of the quality level that would get it into the novice package. > > Any use of CREATE DOES> is going to be inefficient. This is because data is comma'd into memory at compile-time and then fetched out at run-time. This data is known at compile-time and it is immutable, so it shouldn't be stored in memory like mutable data but should just be a literal value in the code. > > A one-dimensional array isn't a very good demonstration of this problem because no data needs to be comma'd in (except for the size that is used in bounds-checking). The problem is more apparent in a multi-dimensional array because the size of every dimension (except the last) needs to be held. > > If the size of the array element can be set by the programmer (making the array general-purpose), then this size also has to be stored, and the problem becomes apparent. This is most likely why Elizabeth Rather restricts her array to only work with cells --- so the size of the element is fixed at one cell and the multiplication by the size is hidden inside of CELLS --- this is a pretty gross limitation though, that was done purely for the purpose of keeping the code simplistic for teaching purposes. > > In the novice-package I have an example of how a student with one week of experience would write a three-dimensional array defining word: > > : 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 > > \ SLOW-3ARRAY is provided for comparison with 3ARRAY. > \ In SwiftForth, an array access is 1+44=45 instructions long with two CALL instructions. > \ By comparison, my 3ARRAY is 19 instructions long with one CALL instruction. > > I wrote that years ago when I was using SwiftForth-v2. Nothing has changed in SwiftForth-v3. Here is the code: > > Here is the code for SLOW-3ARRAY. When the array gets called with CALL, it then does a CALL to the code after the (;CODE) --- that is why I say that there are two CALL instructions. > > see slow-3array > 48BF2F 40FAFF ( CREATE ) CALL E8CB3BF8FF > 48BF34 4 # EBP SUB 83ED04 > 48BF37 EBX 0 [EBP] MOV 895D00 > 48BF3A 40AA2F ( , ) CALL E8F0EAF7FF > 48BF3F EBX PUSH 53 > 48BF40 0 [EBP] EBX MOV 8B5D00 > 48BF43 4 # EBP ADD 83C504 > 48BF46 EBX ECX MOV 8BCB > 48BF48 4 [EBP] EBX MOV 8B5D04 > 48BF4B 0 [EBP] EAX MOV 8B4500 > 48BF4E EAX 4 [EBP] MOV 894504 > 48BF51 ECX 0 [EBP] MOV 894D00 > 48BF54 4 # EBP SUB 83ED04 > 48BF57 EBX 0 [EBP] MOV 895D00 > 48BF5A EBX POP 5B > 48BF5B 0 [EBP] EAX MOV 8B4500 > 48BF5E EBX MUL F7E3 > 48BF60 EAX EBX MOV 8BD8 > 48BF62 4 # EBP ADD 83C504 > 48BF65 4 # EBP SUB 83ED04 > 48BF68 EBX 0 [EBP] MOV 895D00 > 48BF6B 40AA2F ( , ) CALL E8BFEAF7FF > 48BF70 EBX ECX MOV 8BCB > 48BF72 4 [EBP] EBX MOV 8B5D04 > 48BF75 0 [EBP] EAX MOV 8B4500 > 48BF78 EAX 4 [EBP] MOV 894504 > 48BF7B ECX 0 [EBP] MOV 894D00 > 48BF7E 0 [EBP] EAX MOV 8B4500 > 48BF81 EBX MUL F7E3 > 48BF83 EAX EBX MOV 8BD8 > 48BF85 4 # EBP ADD 83C504 > 48BF88 4 # EBP SUB 83ED04 > 48BF8B EBX 0 [EBP] MOV 895D00 > 48BF8E 40AA2F ( , ) CALL E89CEAF7FF > 48BF93 0 [EBP] EAX MOV 8B4500 > 48BF96 EBX MUL F7E3 > 48BF98 EAX EBX MOV 8BD8 > 48BF9A 4 # EBP ADD 83C504 > 48BF9D 40A9AF ( ALLOT ) CALL E80DEAF7FF > 48BFA2 40DA4F ( (;CODE) ) CALL E8A81AF8FF > 48BFA7 4 # EBP SUB 83ED04 > 48BFAA EBX 0 [EBP] MOV 895D00 > 48BFAD EBX POP 5B > 48BFAE EBX PUSH 53 > 48BFAF 8 # EBX ADD 83C308 > 48BFB2 0 [EBX] EBX MOV 8B1B > 48BFB4 0 [EBP] EAX MOV 8B4500 > 48BFB7 EBX MUL F7E3 > 48BFB9 EAX EBX MOV 8BD8 > 48BFBB 4 # EBP ADD 83C504 > 48BFBE 0 [EBP] EAX MOV 8B4500 > 48BFC1 EBX 0 [EBP] MOV 895D00 > 48BFC4 EAX EBX MOV 8BD8 > 48BFC6 4 # EBP SUB 83ED04 > 48BFC9 EBX 0 [EBP] MOV 895D00 > 48BFCC 0 [ESP] EBX MOV 8B1C24 > 48BFCF 4 # EBX ADD 83C304 > 48BFD2 0 [EBX] EBX MOV 8B1B > 48BFD4 0 [EBP] EAX MOV 8B4500 > 48BFD7 EBX MUL F7E3 > 48BFD9 EAX EBX MOV 8BD8 > 48BFDB 4 # EBP ADD 83C504 > 48BFDE 0 [EBP] EBX ADD 035D00 > 48BFE1 4 # EBP ADD 83C504 > 48BFE4 0 [EBP] EAX MOV 8B4500 > 48BFE7 EBX 0 [EBP] MOV 895D00 > 48BFEA EAX EBX MOV 8BD8 > 48BFEC 4 # EBP SUB 83ED04 > 48BFEF EBX 0 [EBP] MOV 895D00 > 48BFF2 0 [ESP] EBX MOV 8B1C24 > 48BFF5 0 [EBX] EBX MOV 8B1B > 48BFF7 0 [EBP] EAX MOV 8B4500 > 48BFFA EBX MUL F7E3 > 48BFFC EAX EBX MOV 8BD8 > 48BFFE 4 # EBP ADD 83C504 > 48C001 0 [EBP] EBX ADD 035D00 > 48C004 4 # EBP ADD 83C504 > 48C007 4 # EBP SUB 83ED04 > 48C00A EBX 0 [EBP] MOV 895D00 > 48C00D EBX POP 5B > 48C00E C # EBX ADD 83C30C > 48C011 0 [EBP] EBX ADD 035D00 > 48C014 4 # EBP ADD 83C504 > 48C017 RET C3 ok > > > Here is the same thing defined with 3ARRAY for efficiency: > > false to bounds-check? ok > 10 10 10 16 3array aaa ok > see aaa > 49646F 640 # EAX MOV B840060000 > 496474 EBX MUL F7E3 > 496476 EAX EBX MOV 8BD8 > 496478 0 [EBP] EAX MOV 8B4500 > 49647B EBX 0 [EBP] MOV 895D00 > 49647E EAX EBX MOV 8BD8 > 496480 A0 # EAX MOV B8A0000000 > 496485 EBX MUL F7E3 > 496487 EAX EBX MOV 8BD8 > 496489 0 [EBP] EBX ADD 035D00 > 49648C 4 # EBP ADD 83C504 > 49648F 0 [EBP] EAX MOV 8B4500 > 496492 EBX 0 [EBP] MOV 895D00 > 496495 EAX EBX MOV 8BD8 > 496497 EBX 4 # SHL C1E304 > 49649A 0 [EBP] EBX ADD 035D00 > 49649D 4 # EBP ADD 83C504 > 4964A0 4925D0 # EBX ADD 81C3D0254900 > 4964A6 RET C3 ok > > > Here is the same thing defined with ARY instead: > > 16 0 10 10 10 ary vvv ok > see vvv > 49A5CF 4 # EBP SUB 83ED04 > 49A5D2 496580 # 0 [EBP] MOV C7450080654900 > 49A5D9 EBX 2 # SHL C1E302 > 49A5DC 0 [EBP] EBX ADD 035D00 > 49A5DF 4 # EBP ADD 83C504 > 49A5E2 0 [EBX] EAX MOV 8B03 > 49A5E4 0 [EBP] EBX MOV 8B5D00 > 49A5E7 EAX 0 [EBP] MOV 894500 > 49A5EA EBX 2 # SHL C1E302 > 49A5ED 0 [EBP] EBX ADD 035D00 > 49A5F0 4 # EBP ADD 83C504 > 49A5F3 0 [EBX] EAX MOV 8B03 > 49A5F5 0 [EBP] EBX MOV 8B5D00 > 49A5F8 EAX 0 [EBP] MOV 894500 > 49A5FB EBX 4 # SHL C1E304 > 49A5FE 0 [EBP] EBX ADD 035D00 > 49A601 4 # EBP ADD 83C504 > 49A604 RET C3 ok Just out of interest, how does VFX do with these? I'd try myself but I'm on an office machine which doesn't have any Forth software installed.
[toc] | [prev] | [next] | [standalone]
Page 3 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