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 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | mhx@iae.nl |
|---|---|
| Date | 2015-08-12 10:18 -0700 |
| Message-ID | <86045ab9-f1ca-4ff4-8734-d3eeff02b153@googlegroups.com> |
| In reply to | #41296 |
On Wednesday, August 12, 2015 at 2:51:50 PM UTC+2, Mark Wills wrote: [..] > 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. Probably even better than this: FORTH> : slow-3array ( dim1 dim2 dim3 siz1 -- ) <3>[FORTH>] create <3>[FORTH>] dup , <3>[FORTH>] >r rot r> * dup , <3>[FORTH>] rot * dup , <3>[FORTH>] * allot <3>[FORTH>] does> <3>[FORTH>] >r <3>[FORTH>] r@ 2 cells + @ * swap <3>[FORTH>] r@ 1 cells + @ * + swap <3>[FORTH>] r@ @ * + r> 3 cells + + ; ok FORTH> 5 6 7 8 slow-3array foo FORTH> : bar pi 1 2 3 foo f! 1 2 3 foo f@ fdrop ; ok FORTH> see bar $01224340 : bar $0122434A fld $01112C40 tbyte-offset $01224350 mov rbx, $01223890 qword-offset $01224357 lea rbx, [rbx*2 0 +] qword $0122435F add rbx, $01223890 qword-offset $01224366 mov rdi, $01223888 qword-offset $0122436D lea rbx, [rbx rdi*2] qword $01224371 add rbx, $01223880 qword-offset $01224378 fstp [rbx $01223898 +] tbyte $0122437E mov rbx, $01223890 qword-offset $01224385 lea rbx, [rbx*2 0 +] qword $0122438D add rbx, $01223890 qword-offset $01224394 mov rdi, $01223888 qword-offset $0122439B lea rbx, [rbx rdi*2] qword $0122439F add rbx, $01223880 qword-offset $012243A6 fld [rbx $01223898 +] tbyte $012243AC ffreep ST(0) $012243AE ; -marcel
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2015-08-13 10:37 -0700 |
| Message-ID | <4d83aa2d-3a5e-4db9-bda8-143877d942be@googlegroups.com> |
| In reply to | #41303 |
On Wednesday, August 12, 2015 at 7:18:33 PM UTC+2, m...@iae.nl wrote: > On Wednesday, August 12, 2015 at 2:51:50 PM UTC+2, Mark Wills wrote: > [..] > > 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. [..] If non-standardness is not a problem and the data is immutable: FORTH> : slow-3array ( dim1 dim2 dim3 siz1 -- ) <3>[FORTH>] create <3>[FORTH>] here >R <3>[FORTH>] dup , <3>[FORTH>] >r rot r> * dup , <3>[FORTH>] rot * dup , <3>[FORTH>] R> 3 CELLS CONST-DATA <3>[FORTH>] * allot <3>[FORTH>] does> <3>[FORTH>] >r <3>[FORTH>] r@ 2 cells + @ * swap <3>[FORTH>] r@ 1 cells + @ * + swap <3>[FORTH>] r@ @ * + r> 3 cells + + ; ok FORTH> 5 6 7 8 slow-3array foo ok FORTH> : bar pi 1 2 3 foo f! 1 2 3 foo f@ fdrop ; ok FORTH> ' bar idis $01224340 : bar $0122434A fld $01112C40 tbyte-offset $01224350 fstp $01223BD0 tbyte-offset $01224356 fld $01223BD0 tbyte-offset $0122435C ffreep ST(0) $0122435E ; By setting the whole array to CONST-DATA the expected happens, but initializing becomes a bit of a challenge. -marcel
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-08-14 12:13 +0000 |
| Message-ID | <2015Aug14.141330@mips.complang.tuwien.ac.at> |
| In reply to | #41308 |
mhx@iae.nl writes:
>By setting the whole array to CONST-DATA the expected happens,
>but initializing becomes a bit of a challenge.
How about doing CONST-DATA only after initializiation?
- 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-08-14 21:30 +0200 |
| Message-ID | <mqlfi9$ukt$1@dont-email.me> |
| In reply to | #41311 |
Anton Ertl wrote: > mhx@iae.nl writes: >>By setting the whole array to CONST-DATA the expected happens, >>but initializing becomes a bit of a challenge. > > How about doing CONST-DATA only after initializiation? I probably would do that stuff region-based, as with a cross-compiler that can compile into ROM. : 3array ( dim1 dim2 dim3 sizeu -- ) get-region >r const-data: ( or ROM or how that region is called ) Create dup , >r rot r> * dup , rot * dup , * allot r> set-region DOES> ... ; The compile can now pretty easy detect what is constant data (everything in the const-data section), and if you want to enforce the read-only attribute of that section, you can use mprotect - mprotect R/W it when it is active, and R/O when another region is active. Furthermore, the coding style is compatible with embedded systems with different sections. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-08-14 13:05 -0700 |
| Message-ID | <701138f0-4ae7-4aa2-a7c1-db9baa2d20ae@googlegroups.com> |
| In reply to | #41313 |
On Friday, August 14, 2015 at 12:30:54 PM UTC-7, Bernd Paysan wrote: > Anton Ertl wrote: > > > mhx@iae.nl writes: > >>By setting the whole array to CONST-DATA the expected happens, > >>but initializing becomes a bit of a challenge. > > > > How about doing CONST-DATA only after initializiation? > > I probably would do that stuff region-based, as with a cross-compiler that > can compile into ROM. I have been saying since 2009 that cross-compiling makes everything easier. There is a clear distinction between HOST code and TARG code, there is a clear distinction between host memory and targ memory, within targ memory there is a clear distinction between RAM and ROM. What I said way back in 2009 when I joined Forth-200x is that the standard should be for a cross-compiler --- it is a bad idea to make the standard for a traditional on-board system and then tack the cross-compiler onto it. Anyway, all of this talk about cross-compilers is a distraction --- you are trying to avoid the major issue here, which is that Elizabeth Rather is incapable of writing an array definer in ANS-Forth: 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 + ; So long as you are on the Forth-200x committee, then you are working for Elizabeth Rather --- Forth-200x is owned entirely by Forth Inc. --- this is why you divert the discussion away from her idiocy. Come on Bernd --- be a loyal cult-member! --- tell everybody that it is a good idea to start the indices at 1 rather than 0, just like in COBOL...
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-08-15 16:57 +0000 |
| Message-ID | <2015Aug15.185758@mips.complang.tuwien.ac.at> |
| In reply to | #41313 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> mhx@iae.nl writes:
>>>By setting the whole array to CONST-DATA the expected happens,
>>>but initializing becomes a bit of a challenge.
>>
>> How about doing CONST-DATA only after initializiation?
>
>I probably would do that stuff region-based, as with a cross-compiler that
>can compile into ROM.
>
>: 3array ( dim1 dim2 dim3 sizeu -- )
> get-region >r const-data: ( or ROM or how that region is called )
> Create dup , >r rot r> * dup , rot * dup , * allot
> r> set-region
> DOES> ... ;
>
>The compile can now pretty easy detect what is constant data (everything in
>the const-data section),
Again, initialization becomes a bit of a challenge, as you specify the
region as const-data: before initializing it.
> and if you want to enforce the read-only attribute
>of that section, you can use mprotect - mprotect R/W it when it is active,
>and R/O when another region is active.
Active?
mprotect() has page granularity, and is not conservative when taking
away rights, so when you change protection for c-addr u from RW to RO,
also everything around until the page boundary becomes RO. If you
implement a conservative variant of mprotect, a part of the RO region
will be RO and a part will be RW. Does not look to me that the
benefits outweigh the costs.
What might be more like it would be a read-only section, where
everything up to a point is read-only and stays read-only. Once you
have initialized your latest array, you make everything but the part
in the last page read-only; and if you want to force it, you make the
last page read-only, too, and set the DP for that section to the start
of the next page.
- 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-08-16 00:12 +0200 |
| Message-ID | <mqodcu$69f$1@dont-email.me> |
| In reply to | #41320 |
Anton Ertl wrote: > Again, initialization becomes a bit of a challenge, as you specify the > region as const-data: before initializing it. No, this is just a region where everything that's in there is treated as constant. >> and if you want to enforce the read-only attribute >>of that section, you can use mprotect - mprotect R/W it when it is active, >>and R/O when another region is active. > > Active? You really should try to understand a bit of cross.fs, especially the embedded part. If you compile for an embedded controller, you set up regions. Regions for RAM, and for nonvolatile memory, which is essentially constant (write-once, but the image is already loaded, so you can't write again). These memory regions all have a name, and by executing the name during compilation, you select the region into which your data goes. > mprotect() has page granularity, and is not conservative when taking > away rights, so when you change protection for c-addr u from RW to RO, > also everything around until the page boundary becomes RO. If you > implement a conservative variant of mprotect, a part of the RO region > will be RO and a part will be RW. Does not look to me that the > benefits outweigh the costs. You would make the entire region r/w when active, and r/o when other regions are active. That way you can detect when your code actually writes to an r/o region. Call it "section", if you like, in cross.fs, it's called "memory region" (short: region). > What might be more like it would be a read-only section, where > everything up to a point is read-only and stays read-only. Once you > have initialized your latest array, you make everything but the part > in the last page read-only; and if you want to force it, you make the > last page read-only, too, and set the DP for that section to the start > of the next page. I don't really care about what the programmer does to a region when it is active, and he's defining stuff in there - this is Forth, you can shoot into your foot. The protection should be for normal application runtime, when the read-only section is not active. Then, it can be protected to detect bugs like writing to it. Several controllers have similar protection schemes with Flash: You need to open it for writing, but when you have done so, you can write anywhere (but you can just flip 1 bits to 0, not the other way round). After loading your program, you can close the flash down, and then you can't write anything. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-08-16 09:44 +0000 |
| Message-ID | <2015Aug16.114425@mips.complang.tuwien.ac.at> |
| In reply to | #41322 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> Again, initialization becomes a bit of a challenge, as you specify the
>> region as const-data: before initializing it.
>
>No, this is just a region where everything that's in there is treated as
>constant.
Yes. So how do you initialize it?
>>> and if you want to enforce the read-only attribute
>>>of that section, you can use mprotect - mprotect R/W it when it is active,
>>>and R/O when another region is active.
>>
>> Active?
>
>You really should try to understand a bit of cross.fs, especially the
>embedded part.
I will, once it is documented. Things like that:
>Call it "section", if you like, in cross.fs, it's called
>"memory region" (short: region).
...
>> What might be more like it would be a read-only section, where
>> everything up to a point is read-only and stays read-only. Once you
>> have initialized your latest array, you make everything but the part
>> in the last page read-only; and if you want to force it, you make the
>> last page read-only, too, and set the DP for that section to the start
>> of the next page.
>
>I don't really care about what the programmer does to a region when it is
>active, and he's defining stuff in there - this is Forth, you can shoot into
>your foot. The protection should be for normal application runtime, when
>the read-only section is not active. Then, it can be protected to detect
>bugs like writing to it.
But if this is Forth, we do not have a hard line between compile-time
and run-time.
Anyway, it seems that what you were thinking of is not that far from
what I described as read-only section above.
- 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-08-17 00:06 +0200 |
| Message-ID | <mqr1es$h5i$1@dont-email.me> |
| In reply to | #41332 |
Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>Anton Ertl wrote: >>> Again, initialization becomes a bit of a challenge, as you specify the >>> region as const-data: before initializing it. >> >>No, this is just a region where everything that's in there is treated as >>constant. > > Yes. So how do you initialize it? You write to it. What's so difficult about understanding "treated as constant": This is a convention. You can actually write to it, as long as it is active, but it's meant to be write-once-before-use. If you don't follow that convention, the compiler (or the real flash) is allowed to screw you. >>>> and if you want to enforce the read-only attribute >>>>of that section, you can use mprotect - mprotect R/W it when it is >>>>active, and R/O when another region is active. >>> >>> Active? >> >>You really should try to understand a bit of cross.fs, especially the >>embedded part. > > I will, once it is documented. Things like that: This part actually is. Jens (who added that code) did write a glossary entry for each line. > But if this is Forth, we do not have a hard line between compile-time > and run-time. Sure. However, as this is Forth, discipline is up to the programmer. And when you do mprotect of the entire section when it's not the currently active section, you even get errors when writing to it. > Anyway, it seems that what you were thinking of is not that far from > what I described as read-only section above. Seems to be. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-08-18 09:13 +0000 |
| Message-ID | <2015Aug18.111303@mips.complang.tuwien.ac.at> |
| In reply to | #41348 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>Anton Ertl wrote:
>>>> Again, initialization becomes a bit of a challenge, as you specify the
>>>> region as const-data: before initializing it.
>>>
>>>No, this is just a region where everything that's in there is treated as
>>>constant.
>>
>> Yes. So how do you initialize it?
>
>You write to it. What's so difficult about understanding "treated as
>constant": This is a convention. You can actually write to it,
That's the opposite of treating it as a constant.
> as long as
>it is active, but it's meant to be write-once-before-use.
Ah, a previously unwritten constraint. And I guess "use" could also
benefit from more exactness.
>>>>> and if you want to enforce the read-only attribute
>>>>>of that section, you can use mprotect - mprotect R/W it when it is
>>>>>active, and R/O when another region is active.
>>>>
>>>> Active?
>>>
>>>You really should try to understand a bit of cross.fs, especially the
>>>embedded part.
>>
>> I will, once it is documented. Things like that:
>
>This part actually is. Jens (who added that code) did write a glossary
>entry for each line.
: activate ( region -- )
\G next code goes to this region
Wow, that tells me everything there is to know about "active regions".
Other glossary comments I looked at (where they exist) are not more
enlightening. Better than nothing, but not sufficient. You also need
to explain the concepts somewhere, and how they fit together.
>> But if this is Forth, we do not have a hard line between compile-time
>> and run-time.
>
>Sure. However, as this is Forth, discipline is up to the programmer.
Yes. Of course, if you expect the programmer to keep to some usage
regime, you need to document that. Using mprotect() at some subset of
the memory, or during some time to enforce the discipline without
documenting what discipline you expect is very programmer-unfriendly.
- 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-18 09:02 -0700 |
| Message-ID | <f6037458-5657-449d-b227-15d6e7ee324c@googlegroups.com> |
| In reply to | #41370 |
On Tuesday, August 18, 2015 at 2:27:55 AM UTC-7, Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: > >Anton Ertl wrote: > > > >> Bernd Paysan <bernd.paysan@gmx.de> writes: > >>>Anton Ertl wrote: > >>>> Again, initialization becomes a bit of a challenge, as you specify the > >>>> region as const-data: before initializing it. > >>> > >>>No, this is just a region where everything that's in there is treated as > >>>constant. > >> > >> Yes. So how do you initialize it? > > > >You write to it. What's so difficult about understanding "treated as > >constant": This is a convention. You can actually write to it, > > That's the opposite of treating it as a constant. > > > as long as > >it is active, but it's meant to be write-once-before-use. > > Ah, a previously unwritten constraint. And I guess "use" could also > benefit from more exactness. > > >>>>> and if you want to enforce the read-only attribute > >>>>>of that section, you can use mprotect - mprotect R/W it when it is > >>>>>active, and R/O when another region is active. > >>>> > >>>> Active? > >>> > >>>You really should try to understand a bit of cross.fs, especially the > >>>embedded part. > >> > >> I will, once it is documented. Things like that: > > > >This part actually is. Jens (who added that code) did write a glossary > >entry for each line. > > : activate ( region -- ) > \G next code goes to this region > > Wow, that tells me everything there is to know about "active regions". > Other glossary comments I looked at (where they exist) are not more > enlightening. Better than nothing, but not sufficient. You also need > to explain the concepts somewhere, and how they fit together. > > >> But if this is Forth, we do not have a hard line between compile-time > >> and run-time. > > > >Sure. However, as this is Forth, discipline is up to the programmer. > > Yes. Of course, if you expect the programmer to keep to some usage > regime, you need to document that. Using mprotect() at some subset of > the memory, or during some time to enforce the discipline without > documenting what discipline you expect is very programmer-unfriendly. > > - anton The Forth-200x committee makes everything sooooooo complicated! As I recall, we were discussing how to write array definers --- I have them in the novice-package (see ARY and 3ARRAY etc.) --- in the year 2015 I would hope that we could finally begin writing application programs, and stop dinking around with figuring out how to define an array. The subject of array definers was somewhat amusing when I was 18 years old and reading "Starting Forth," but it is getting rather wearisome 30 years later --- I think a big part of why nobody is volunteering to learn ANS-Forth is that they get bogged down in defining their own data-structures, and they quit before they have ever written a program that did anything --- to maintain interest, students need to succeed at something, but writing an array definer is boring and doesn't count as a success by anybody's standard (how many people think that writing code like SLOW-3ARRAY is fun? zero?). BTW: Neither of you have answered my question about whether Alex McDonald is on the Forth-200x committee or not. If he isn't on the committee, just go ahead and put him on the committee --- this is obviously what he wants --- if he gets what he wants, he will hopefully stop attacking me in his effort to impress you with his loyalty.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-08-19 00:02 +0100 |
| Message-ID | <mr0der$lrf$1@dont-email.me> |
| In reply to | #41373 |
on 18/08/2015 17:02:06, wrote: > > BTW: Neither of you have answered my question about whether Alex > McDonald i s on the Forth-200x committee or not. If he isn't on the No, since there are criteria that I can't meet. > committee, just go ahead and put him on the committee --- this is > obviously what he wants --- if he gets what he wants, he will I want to enjoy myself & have some interesting conversations on clf without you getting your panties in a bunch.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-08-18 14:20 -1000 |
| Message-ID | <DfSdnbbkW7dCVk7InZ2dnUU7-V2dnZ2d@supernews.com> |
| In reply to | #41386 |
On 8/18/15 1:02 PM, Alex McDonald wrote: > on 18/08/2015 17:02:06, wrote: > >> >> BTW: Neither of you have answered my question about whether Alex >> McDonald i s on the Forth-200x committee or not. If he isn't on the > > No, since there are criteria that I can't meet. > >> committee, just go ahead and put him on the committee --- this is >> obviously what he wants --- if he gets what he wants, he will > > I want to enjoy myself & have some interesting conversations on clf > without you getting your panties in a bunch. > The members are listed on p. x-xi (introductory section in the front). Alex and I and a number of others are thanked as contributors, but have not been voting members. 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-08-19 03:12 +0200 |
| Message-ID | <mr0l33$c3j$1@dont-email.me> |
| In reply to | #41370 |
Anton Ertl wrote:
>>> But if this is Forth, we do not have a hard line between compile-time
>>> and run-time.
>>
>>Sure. However, as this is Forth, discipline is up to the programmer.
>
> Yes. Of course, if you expect the programmer to keep to some usage
> regime, you need to document that. Using mprotect() at some subset of
> the memory, or during some time to enforce the discipline without
> documenting what discipline you expect is very programmer-unfriendly.
Hm, I think you really should go out and get one of those small controllers
to get a grip of embedded Forth. There, we have to deal with these sections
which have different write regimes all the time: Flash is write-once, RAM is
write-many.
A "const-data:" section contains data that is supposed to be constant when
the program is running. As we need to initialize, it must be writeable when
we initialize.
Therefore, the rule is: When the section is the current section ("current"
means: you can , into it and HERE points to it), then it must be writeable,
so mprotect(region, RWX) happened before. If it's not active, and the
normal RAM section is active, you can't (just R-X protection).
The compiler itself can assume that all data fetched from that section is
constant and initialized before any attempt to use it.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2015-08-14 13:09 -0700 |
| Message-ID | <95e387b1-a469-42b8-ab71-14d86cd5b39a@googlegroups.com> |
| In reply to | #41311 |
On Friday, August 14, 2015 at 2:15:15 PM UTC+2, Anton Ertl wrote: > mhx@iae.nl writes: > >By setting the whole array to CONST-DATA the expected happens, > >but initializing becomes a bit of a challenge. > > How about doing CONST-DATA only after initializiation? FORTH> : slow-3array ( dim1 dim2 dim3 siz1 -- ) <3>[FORTH>] create <3>[FORTH>] here >R <3>[FORTH>] dup , <3>[FORTH>] >r rot r> * dup , <3>[FORTH>] rot * dup , <3>[FORTH>] R> 3 CELLS CONST-DATA <3>[FORTH>] * allot <3>[FORTH>] does> <3>[FORTH>] >r <3>[FORTH>] r@ 2 cells + @ * swap <3>[FORTH>] r@ 1 cells + @ * + swap <3>[FORTH>] r@ @ * + r> 3 cells + + ; ok FORTH> ok FORTH> 5 6 7 8 slow-3array foo ok FORTH> #22 1 2 3 foo ! ok FORTH> ok FORTH> 0 0 0 foo 5 6 * 7 * 8 * CONST-DATA ok ( from now on we have an immutable array of constants ) FORTH> 1 2 3 foo CONST? . -1 ok ( You have to make sure that the array is initialized before *compiling* access to it ) FORTH> : bar 1 2 3 foo @ 2* 1+ ; ok FORTH> see bar $01224340 : bar $0122434A push #45 b# $0122434C ; A bit clumsy and error-prone. Maybe something like foo mem-open and foo mem-close might work. Another trap is e.g. 22 1 2 3 foo +! . -marcel
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-08-14 13:43 -0700 |
| Message-ID | <4a2d6e82-b41d-4a90-9b82-c9a543d853c1@googlegroups.com> |
| In reply to | #41315 |
On Friday, August 14, 2015 at 1:09:17 PM UTC-7, m...@iae.nl wrote: > On Friday, August 14, 2015 at 2:15:15 PM UTC+2, Anton Ertl wrote: > > mhx@iae.nl writes: > > >By setting the whole array to CONST-DATA the expected happens, > > >but initializing becomes a bit of a challenge. > > > > How about doing CONST-DATA only after initializiation? > > FORTH> : slow-3array ( dim1 dim2 dim3 siz1 -- ) > <3>[FORTH>] create > <3>[FORTH>] here >R > <3>[FORTH>] dup , > <3>[FORTH>] >r rot r> * dup , > <3>[FORTH>] rot * dup , > <3>[FORTH>] R> 3 CELLS CONST-DATA > <3>[FORTH>] * allot > <3>[FORTH>] does> > <3>[FORTH>] >r > <3>[FORTH>] r@ 2 cells + @ * swap > <3>[FORTH>] r@ 1 cells + @ * + swap > <3>[FORTH>] r@ @ * + r> 3 cells + + ; ok > FORTH> ok > FORTH> 5 6 7 8 slow-3array foo ok > FORTH> #22 1 2 3 foo ! ok > FORTH> ok > FORTH> 0 0 0 foo 5 6 * 7 * 8 * CONST-DATA ok > ( from now on we have an immutable array of constants ) > FORTH> 1 2 3 foo CONST? . -1 ok > ( You have to make sure that the array is initialized > before *compiling* access to it ) > FORTH> : bar 1 2 3 foo @ 2* 1+ ; ok > FORTH> see bar > $01224340 : bar > $0122434A push #45 b# > $0122434C ; > > A bit clumsy and error-prone. Maybe > something like foo mem-open and foo mem-close might work. > > Another trap is e.g. 22 1 2 3 foo +! . > > -marcel SLOW-3ARRAY is just some throwaway code that I wrote to demonstrate how a student with one week of experience would write an array definer --- it was not intended to be something that you take seriously --- just use 3ARRAY or ARY as provided in the novice package.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-08-15 17:10 +0000 |
| Message-ID | <2015Aug15.191046@mips.complang.tuwien.ac.at> |
| In reply to | #41315 |
mhx@iae.nl writes:
>On Friday, August 14, 2015 at 2:15:15 PM UTC+2, Anton Ertl wrote:
>> mhx@iae.nl writes:
>> >By setting the whole array to CONST-DATA the expected happens,
>> >but initializing becomes a bit of a challenge.
>>
>> How about doing CONST-DATA only after initializiation?
>
>FORTH> : slow-3array ( dim1 dim2 dim3 siz1 -- )
><3>[FORTH>] create
><3>[FORTH>] here >R
><3>[FORTH>] dup ,
><3>[FORTH>] >r rot r> * dup ,
><3>[FORTH>] rot * dup ,
><3>[FORTH>] R> 3 CELLS CONST-DATA
><3>[FORTH>] * allot
><3>[FORTH>] does>
><3>[FORTH>] >r
><3>[FORTH>] r@ 2 cells + @ * swap
><3>[FORTH>] r@ 1 cells + @ * + swap
><3>[FORTH>] r@ @ * + r> 3 cells + + ; ok
>FORTH> ok
>FORTH> 5 6 7 8 slow-3array foo ok
>FORTH> #22 1 2 3 foo ! ok
>FORTH> ok
>FORTH> 0 0 0 foo 5 6 * 7 * 8 * CONST-DATA ok
>( from now on we have an immutable array of constants )
>FORTH> 1 2 3 foo CONST? . -1 ok
>( You have to make sure that the array is initialized
> before *compiling* access to it )
>FORTH> : bar 1 2 3 foo @ 2* 1+ ; ok
>FORTH> see bar
>$01224340 : bar
>$0122434A push #45 b#
>$0122434C ;
>
>A bit clumsy and error-prone.
If you store the element size in the array, too, you can make a word:
: 3array-ro ( xt -- )
>body dup >r r@ @ r@ cell+ @ * ... const-data ;
and then use it as follows:
' foo 3array-ro
Does not look clumsy or error-prone to me.
>Maybe
>something like foo mem-open and foo mem-close might work.
Example?
>Another trap is e.g. 22 1 2 3 foo +! .
Sure, once you specify a piece of memory const-data, it's not a good
idea to change it. But +! does not appear to be more of a trap than
!.
- 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-12 21:16 -0700 |
| Message-ID | <dc5d72d2-4fd4-41fd-af2c-65d0818be430@googlegroups.com> |
| In reply to | #41296 |
On Wednesday, August 12, 2015 at 5:51:50 AM UTC-7, 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: > > > 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. VFX seems to be similar to SwiftForth in that it does a CALL to the code after (;CODE) and then uses the return-address on the return-stack as the pointer to the data after the CREATE. This was a clever technique in the late 1970s and early 1980s, but it is not so clever now. One problem, is that this requires that code and data be intermixed which results in a lot of cache-thrashing because modern machines have a separate data-cache and code-cache, but when data and code are juxtaposed you end up with data in the code-cache and code in the data-cache. Another problem is that modern machines (the x86 anyway) do CALL prediction, meaning that when a CALL is done the return-address is held in a register internally in addition to being held on the return-stack, and the RET is faster because it gets the return-address from the register rather than from memory. This works to 16 levels deep IIRC. If the program pulls the return-address from the return-stack however, then the whole thing goes haywire and all that information is lost. This is what both VFX and SwiftForth do in the code after the (;CODE) because it is not a return-address and won't be given to RET but it is actually a pointer to data. The result in VFX is: 15+1 = 16 instructions for SLOW-3ARRAY 9 instructions for 3ARRAY 8 instructions for ARY This is about the same ratio as in SwiftForth --- twice as fast for my 3ARRAY and ARY as compared to SLOW-3ARRAY --- but VFX code is about three times as fast as SwiftForth code. Note that this whole subject has been discussed before in 2009 when I first wrote it: https://groups.google.com/forum/#!searchin/comp.lang.forth/don$27t$20use$20create$20does%3E$20hugh/comp.lang.forth/TTvONOrHvI4/X63CXcZYaPgJ In this thread, Stephen Pelc insisted that his CREATE DOES> did not have to fetch immutable data from memory at run-time (my complaint against CREATE DOES>). He showed disassembled code to prove this, but he mysteriously wouldn't show the source-code for the array definer. Finally (after much insistence by me) he showed the source-code for the array definer. Somewhat predictably, it wasn't ANS-Forth. He had some compile-time declarations that indicate that data comma'd is immutable. So, VFX can get better efficiency with CREATE DOES> comparable to my code, but at the cost of abandoning ANS-Forth compliance (my novice package is totally ANS-Forth compliant). This seems to be typical of Stephen Pelc --- he tries to get his users trapped in vendor lock-in by giving them better performance at the cost of losing ANS-Forth compliance --- so, I am actually more faithful to ANS-Forth than Stephen Pelc is, yet he is on the Forth-200x committee that has a mandate to be 100% compatible with ANS-Forth --- he is going to continue with the same vendor lock-in tricks after Forth-200x becomes the new "standard," which is why he doesn't really care how screwed up Forth-200x is and is willing to vote however Leon Wagner tells him to vote. Stephen Pelc is jumping on the band-wagon for the purpose of being better positioned to stick a tree branch in the wheel! Anyway, here is the code (VFX eval 4.60): see slow-3array SLOW-3ARRAY ( 004DCB10 E89B81F6FF ) CALL 00444CB0 CREATE ( 004DCB15 8B1524214000 ) MOV EDX, [00402124] ( 004DCB1B 891A ) MOV 0 [EDX], EBX ( 004DCB1D 83C204 ) ADD EDX, 04 ( 004DCB20 891524214000 ) MOV [00402124], EDX ( 004DCB26 53 ) PUSH EBX ( 004DCB27 5B ) POP EBX ( 004DCB28 0FAF5D08 ) IMUL EBX, [EBP+08] ( 004DCB2C 8B1524214000 ) MOV EDX, [00402124] ( 004DCB32 891A ) MOV 0 [EDX], EBX ( 004DCB34 83C204 ) ADD EDX, 04 ( 004DCB37 891524214000 ) MOV [00402124], EDX ( 004DCB3D 0FAF5D04 ) IMUL EBX, [EBP+04] ( 004DCB41 8B1524214000 ) MOV EDX, [00402124] ( 004DCB47 891A ) MOV 0 [EDX], EBX ( 004DCB49 83C204 ) ADD EDX, 04 ( 004DCB4C 891524214000 ) MOV [00402124], EDX ( 004DCB52 0FAF5D00 ) IMUL EBX, [EBP] ( 004DCB56 011D24214000 ) ADD [00402124], EBX ( 004DCB5C 8B5D0C ) MOV EBX, [EBP+0C] ( 004DCB5F 8D6D10 ) LEA EBP, [EBP+10] ( 004DCB62 E8F1A9F6FF0ACB4D00 ) CALL 00447558 DOES_SIN 004DCB0A ( 004DCB6B E8B081F6FF ) CALL 00444D20 NO-COMPILER ( 004DCB70 E88F32F3FF ) CALL 0040FE04 (;CODE) ( 004DCB75 8B1424 ) MOV EDX, [ESP] ( 004DCB78 0FAF5A08 ) IMUL EBX, [EDX+08] ( 004DCB7C 8B1424 ) MOV EDX, [ESP] ( 004DCB7F 8B4A04 ) MOV ECX, [EDX+04] ( 004DCB82 0FAF4D00 ) IMUL ECX, [EBP] ( 004DCB86 03D9 ) ADD EBX, ECX ( 004DCB88 8B1424 ) MOV EDX, [ESP] ( 004DCB8B 8B0A ) MOV ECX, 0 [EDX] ( 004DCB8D 0FAF4D04 ) IMUL ECX, [EBP+04] ( 004DCB91 03D9 ) ADD EBX, ECX ( 004DCB93 5A ) POP EDX ( 004DCB94 83C20C ) ADD EDX, 0C ( 004DCB97 03DA ) ADD EBX, EDX ( 004DCB99 8D6D08 ) LEA EBP, [EBP+08] ( 004DCB9C C3 ) NEXT, ( 141 bytes, 39 instructions ) false to bounds-check? ok 10 10 10 16 3array aaa ok see aaa AAA ( 004E2F40 69DB40060000 ) IMUL EBX, EBX, # 00000640 ( 004E2F46 695500A0000000 ) IMUL EDX, [EBP], # 000000A0 ( 004E2F4D 03DA ) ADD EBX, EDX ( 004E2F4F 8B5504 ) MOV EDX, [EBP+04] ( 004E2F52 C1E204 ) SHL EDX, 04 ( 004E2F55 03DA ) ADD EBX, EDX ( 004E2F57 81C398F04D00 ) ADD EBX, 004DF098 ( 004E2F5D 8D6D08 ) LEA EBP, [EBP+08] ( 004E2F60 C3 ) NEXT, ( 33 bytes, 9 instructions ) 16 0 10 10 10 ary vvv ok see vvv VVV ( 004E70C0 8B1C9D6C304E00 ) MOV EBX, [004E306C+EBX*4] ( 004E70C7 8B5500 ) MOV EDX, [EBP] ( 004E70CA 8B1493 ) MOV EDX, [EBX+EDX*4] ( 004E70CD 8B5D04 ) MOV EBX, [EBP+04] ( 004E70D0 C1E304 ) SHL EBX, 04 ( 004E70D3 03DA ) ADD EBX, EDX ( 004E70D5 8D6D08 ) LEA EBP, [EBP+08] ( 004E70D8 C3 ) NEXT, ( 25 bytes, 8 instructions ) ok
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-08-12 21:31 -0700 |
| Message-ID | <67daa397-226d-4837-8439-fc01f87c6dfe@googlegroups.com> |
| In reply to | #41304 |
On Wednesday, August 12, 2015 at 9:16:57 PM UTC-7, hughag...@gmail.com wrote: > Anyway, here is the code (VFX eval 4.60): > > see slow-3array > SLOW-3ARRAY > ( 004DCB10 E89B81F6FF ) CALL 00444CB0 CREATE > ( 004DCB15 8B1524214000 ) MOV EDX, [00402124] > ( 004DCB1B 891A ) MOV 0 [EDX], EBX > ( 004DCB1D 83C204 ) ADD EDX, 04 > ( 004DCB20 891524214000 ) MOV [00402124], EDX > ( 004DCB26 53 ) PUSH EBX > ( 004DCB27 5B ) POP EBX > ( 004DCB28 0FAF5D08 ) IMUL EBX, [EBP+08] > ( 004DCB2C 8B1524214000 ) MOV EDX, [00402124] > ( 004DCB32 891A ) MOV 0 [EDX], EBX > ( 004DCB34 83C204 ) ADD EDX, 04 > ( 004DCB37 891524214000 ) MOV [00402124], EDX > ( 004DCB3D 0FAF5D04 ) IMUL EBX, [EBP+04] > ( 004DCB41 8B1524214000 ) MOV EDX, [00402124] > ( 004DCB47 891A ) MOV 0 [EDX], EBX > ( 004DCB49 83C204 ) ADD EDX, 04 > ( 004DCB4C 891524214000 ) MOV [00402124], EDX > ( 004DCB52 0FAF5D00 ) IMUL EBX, [EBP] > ( 004DCB56 011D24214000 ) ADD [00402124], EBX > ( 004DCB5C 8B5D0C ) MOV EBX, [EBP+0C] > ( 004DCB5F 8D6D10 ) LEA EBP, [EBP+10] > ( 004DCB62 E8F1A9F6FF0ACB4D00 ) CALL 00447558 DOES_SIN 004DCB0A > ( 004DCB6B E8B081F6FF ) CALL 00444D20 NO-COMPILER > ( 004DCB70 E88F32F3FF ) CALL 0040FE04 (;CODE) > ( 004DCB75 8B1424 ) MOV EDX, [ESP] > ( 004DCB78 0FAF5A08 ) IMUL EBX, [EDX+08] > ( 004DCB7C 8B1424 ) MOV EDX, [ESP] > ( 004DCB7F 8B4A04 ) MOV ECX, [EDX+04] > ( 004DCB82 0FAF4D00 ) IMUL ECX, [EBP] > ( 004DCB86 03D9 ) ADD EBX, ECX > ( 004DCB88 8B1424 ) MOV EDX, [ESP] > ( 004DCB8B 8B0A ) MOV ECX, 0 [EDX] > ( 004DCB8D 0FAF4D04 ) IMUL ECX, [EBP+04] > ( 004DCB91 03D9 ) ADD EBX, ECX > ( 004DCB93 5A ) POP EDX > ( 004DCB94 83C20C ) ADD EDX, 0C > ( 004DCB97 03DA ) ADD EBX, EDX > ( 004DCB99 8D6D08 ) LEA EBP, [EBP+08] > ( 004DCB9C C3 ) NEXT, > ( 141 bytes, 39 instructions ) > > > false to bounds-check? ok > 10 10 10 16 3array aaa ok > see aaa > AAA > ( 004E2F40 69DB40060000 ) IMUL EBX, EBX, # 00000640 > ( 004E2F46 695500A0000000 ) IMUL EDX, [EBP], # 000000A0 > ( 004E2F4D 03DA ) ADD EBX, EDX > ( 004E2F4F 8B5504 ) MOV EDX, [EBP+04] > ( 004E2F52 C1E204 ) SHL EDX, 04 > ( 004E2F55 03DA ) ADD EBX, EDX > ( 004E2F57 81C398F04D00 ) ADD EBX, 004DF098 > ( 004E2F5D 8D6D08 ) LEA EBP, [EBP+08] > ( 004E2F60 C3 ) NEXT, > ( 33 bytes, 9 instructions ) > > > 16 0 10 10 10 ary vvv ok > see vvv > VVV > ( 004E70C0 8B1C9D6C304E00 ) MOV EBX, [004E306C+EBX*4] > ( 004E70C7 8B5500 ) MOV EDX, [EBP] > ( 004E70CA 8B1493 ) MOV EDX, [EBX+EDX*4] > ( 004E70CD 8B5D04 ) MOV EBX, [EBP+04] > ( 004E70D0 C1E304 ) SHL EBX, 04 > ( 004E70D3 03DA ) ADD EBX, EDX > ( 004E70D5 8D6D08 ) LEA EBP, [EBP+08] > ( 004E70D8 C3 ) NEXT, > ( 25 bytes, 8 instructions ) > ok BTW: Notice that my 3ARRAY and ARY don't use any multiply because the element-size (4) and the dimension-size (16) are both powers of 2 --- they only use shift instructions --- by comparison, SLOW-3ARRAY uses IMUL (this doesn't make a lot of difference on the x86, but on less powerful processors multiplication can be significantly slower than shifting). This is why I say in the documentation that with 3ARRAY and ARY it is best to make the dimensions a power of 2 if possible for speed, even though this may waste some memory. Both xARRAY and ARY use LIT*, internally --- it is smart about what kind of literal value it is given, and will compile a shift rather than a multiply if the literal value is a power of two --- this is one of the reasons why the novice-package generates efficient code while yet retaining ANS-Forth compliance.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-08-12 21:39 -0700 |
| Message-ID | <21e50276-b8b3-4ed3-8a42-abe9582bcc63@googlegroups.com> |
| In reply to | #41305 |
On Wednesday, August 12, 2015 at 9:31:04 PM UTC-7, hughag...@gmail.com wrote: > On Wednesday, August 12, 2015 at 9:16:57 PM UTC-7, hughag...@gmail.com wrote: > > Anyway, here is the code (VFX eval 4.60): > > > > see slow-3array > > SLOW-3ARRAY > > ( 004DCB10 E89B81F6FF ) CALL 00444CB0 CREATE > > ( 004DCB15 8B1524214000 ) MOV EDX, [00402124] > > ( 004DCB1B 891A ) MOV 0 [EDX], EBX > > ( 004DCB1D 83C204 ) ADD EDX, 04 > > ( 004DCB20 891524214000 ) MOV [00402124], EDX > > ( 004DCB26 53 ) PUSH EBX > > ( 004DCB27 5B ) POP EBX > > ( 004DCB28 0FAF5D08 ) IMUL EBX, [EBP+08] > > ( 004DCB2C 8B1524214000 ) MOV EDX, [00402124] > > ( 004DCB32 891A ) MOV 0 [EDX], EBX > > ( 004DCB34 83C204 ) ADD EDX, 04 > > ( 004DCB37 891524214000 ) MOV [00402124], EDX > > ( 004DCB3D 0FAF5D04 ) IMUL EBX, [EBP+04] > > ( 004DCB41 8B1524214000 ) MOV EDX, [00402124] > > ( 004DCB47 891A ) MOV 0 [EDX], EBX > > ( 004DCB49 83C204 ) ADD EDX, 04 > > ( 004DCB4C 891524214000 ) MOV [00402124], EDX > > ( 004DCB52 0FAF5D00 ) IMUL EBX, [EBP] > > ( 004DCB56 011D24214000 ) ADD [00402124], EBX > > ( 004DCB5C 8B5D0C ) MOV EBX, [EBP+0C] > > ( 004DCB5F 8D6D10 ) LEA EBP, [EBP+10] > > ( 004DCB62 E8F1A9F6FF0ACB4D00 ) CALL 00447558 DOES_SIN 004DCB0A > > ( 004DCB6B E8B081F6FF ) CALL 00444D20 NO-COMPILER > > ( 004DCB70 E88F32F3FF ) CALL 0040FE04 (;CODE) > > ( 004DCB75 8B1424 ) MOV EDX, [ESP] > > ( 004DCB78 0FAF5A08 ) IMUL EBX, [EDX+08] > > ( 004DCB7C 8B1424 ) MOV EDX, [ESP] > > ( 004DCB7F 8B4A04 ) MOV ECX, [EDX+04] > > ( 004DCB82 0FAF4D00 ) IMUL ECX, [EBP] > > ( 004DCB86 03D9 ) ADD EBX, ECX > > ( 004DCB88 8B1424 ) MOV EDX, [ESP] > > ( 004DCB8B 8B0A ) MOV ECX, 0 [EDX] > > ( 004DCB8D 0FAF4D04 ) IMUL ECX, [EBP+04] > > ( 004DCB91 03D9 ) ADD EBX, ECX > > ( 004DCB93 5A ) POP EDX > > ( 004DCB94 83C20C ) ADD EDX, 0C > > ( 004DCB97 03DA ) ADD EBX, EDX > > ( 004DCB99 8D6D08 ) LEA EBP, [EBP+08] > > ( 004DCB9C C3 ) NEXT, > > ( 141 bytes, 39 instructions ) > > > > > > false to bounds-check? ok > > 10 10 10 16 3array aaa ok > > see aaa > > AAA > > ( 004E2F40 69DB40060000 ) IMUL EBX, EBX, # 00000640 > > ( 004E2F46 695500A0000000 ) IMUL EDX, [EBP], # 000000A0 > > ( 004E2F4D 03DA ) ADD EBX, EDX > > ( 004E2F4F 8B5504 ) MOV EDX, [EBP+04] > > ( 004E2F52 C1E204 ) SHL EDX, 04 > > ( 004E2F55 03DA ) ADD EBX, EDX > > ( 004E2F57 81C398F04D00 ) ADD EBX, 004DF098 > > ( 004E2F5D 8D6D08 ) LEA EBP, [EBP+08] > > ( 004E2F60 C3 ) NEXT, > > ( 33 bytes, 9 instructions ) > > > > > > 16 0 10 10 10 ary vvv ok > > see vvv > > VVV > > ( 004E70C0 8B1C9D6C304E00 ) MOV EBX, [004E306C+EBX*4] > > ( 004E70C7 8B5500 ) MOV EDX, [EBP] > > ( 004E70CA 8B1493 ) MOV EDX, [EBX+EDX*4] > > ( 004E70CD 8B5D04 ) MOV EBX, [EBP+04] > > ( 004E70D0 C1E304 ) SHL EBX, 04 > > ( 004E70D3 03DA ) ADD EBX, EDX > > ( 004E70D5 8D6D08 ) LEA EBP, [EBP+08] > > ( 004E70D8 C3 ) NEXT, > > ( 25 bytes, 8 instructions ) > > ok > > BTW: Notice that my 3ARRAY and ARY don't use any multiply because the element-size (4) and the dimension-size (16) are both powers of 2 --- they only use shift instructions --- by comparison, SLOW-3ARRAY uses IMUL (this doesn't make a lot of difference on the x86, but on less powerful processors multiplication can be significantly slower than shifting). > > This is why I say in the documentation that with 3ARRAY and ARY it is best to make the dimensions a power of 2 if possible for speed, even though this may waste some memory. > > Both xARRAY and ARY use LIT*, internally --- it is smart about what kind of literal value it is given, and will compile a shift rather than a multiply if the literal value is a power of two --- this is one of the reasons why the novice-package generates efficient code while yet retaining ANS-Forth compliance. OOPS! I actually had a dimension size of 10 (not a power of two) in that code I showed above (also, I said the element size was 4 and it was actually 16). Here it is with a dimension size of 16 (now it is a power of two) and with the element-size still 16 as before: 16 16 16 16 3array aaap2 ok see aaap2 AAAP2 ( 005072B0 C1E30C ) SHL EBX, 0C ( 005072B3 8B5500 ) MOV EDX, [EBP] ( 005072B6 C1E208 ) SHL EDX, 08 ( 005072B9 03DA ) ADD EBX, EDX ( 005072BB 8B5504 ) MOV EDX, [EBP+04] ( 005072BE C1E204 ) SHL EDX, 04 ( 005072C1 03DA ) ADD EBX, EDX ( 005072C3 81C38C724F00 ) ADD EBX, 004F728C ( 005072C9 8D6D08 ) LEA EBP, [EBP+08] ( 005072CC C3 ) NEXT, ( 29 bytes, 10 instructions ) ok 16 0 16 16 16 ary vvvp2 ok see vvvp2 VVVP2 ( 00517840 8B1C9DDC735000 ) MOV EBX, [005073DC+EBX*4] ( 00517847 8B5500 ) MOV EDX, [EBP] ( 0051784A 8B1493 ) MOV EDX, [EBX+EDX*4] ( 0051784D 8B5D04 ) MOV EBX, [EBP+04] ( 00517850 C1E304 ) SHL EBX, 04 ( 00517853 03DA ) ADD EBX, EDX ( 00517855 8D6D08 ) LEA EBP, [EBP+08] ( 00517858 C3 ) NEXT, ( 25 bytes, 8 instructions ) ok
[toc] | [prev] | [next] | [standalone]
Page 4 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