Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #55968 > unrolled thread
| Started by | Helmar Wodtke <helmwo@gmail.com> |
|---|---|
| First post | 2017-03-20 09:58 -0700 |
| Last post | 2017-03-24 17:52 -0700 |
| Articles | 20 on this page of 212 — 28 participants |
Back to article view | Back to comp.lang.forth
Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-20 09:58 -0700
Re: Make Forth Small Again! Paul Rubin <no.email@nospam.invalid> - 2017-03-20 10:34 -0700
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-20 10:51 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-20 18:08 +0000
Re: Make Forth Small Again! NN <november.nihal@gmail.com> - 2017-03-20 12:19 -0700
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 05:51 -0700
Re: Make Forth Small Again! Coos Haak <htrofhc@gmail.com> - 2017-03-21 15:04 +0100
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-21 11:22 -1000
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 14:47 -0700
Re: Make Forth Small Again! Coos Haak <htrofhc@gmail.com> - 2017-03-22 01:34 +0100
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-25 17:27 +1100
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-25 00:06 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-25 01:02 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-25 01:05 -0700
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-27 12:11 +1000
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-27 15:53 +1000
Re: Make Forth Small Again! Paul Rubin <no.email@nospam.invalid> - 2017-03-26 22:12 -0700
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-29 10:30 +1000
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-25 09:34 +0000
Re: Make Forth Small Again! mhx@iae.nl - 2017-03-25 03:46 -0700
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-27 10:56 +1000
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-28 10:07 +1000
Re: Make Forth Small Again! mhx@iae.nl - 2017-03-27 16:46 -0700
Re: Make Forth Small Again! Paul Rubin <no.email@nospam.invalid> - 2017-03-27 18:51 -0700
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-27 17:21 -1000
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-28 10:57 -0700
Re: Make Forth Small Again! minforth@arcor.de - 2017-03-28 01:16 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-28 03:36 -0500
Re: Make Forth Small Again! minforth@arcor.de - 2017-03-28 01:54 -0700
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-28 12:57 -1000
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-28 03:51 -0500
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-29 10:29 +1000
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-21 03:33 -0500
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 05:17 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-21 09:42 -0500
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 09:49 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-21 12:12 -0500
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 10:28 -0700
Re: Make Forth Small Again! Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-03-21 16:43 -0400
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-21 14:11 -1000
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-21 16:46 +0000
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-21 12:32 -0500
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 10:57 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-21 14:10 -0500
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 12:50 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-21 15:29 -0500
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 14:01 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-22 03:23 -0500
Re: Make Forth Small Again! Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-07 09:26 +0200
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-04-07 10:10 -1000
Re: Make Forth Small Again! Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-03-21 16:42 -0400
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-22 13:10 +0000
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 06:38 -0700
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-22 15:24 +0000
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-22 08:52 -0500
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-25 13:55 +0000
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-25 17:41 -0500
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-22 07:43 -0700
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 08:06 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-22 10:01 -0700
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 10:19 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-22 10:59 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-22 18:31 +0000
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-22 13:55 -0700
Re: Make Forth Small Again! Mark Wills <markwills1970@gmail.com> - 2017-03-23 05:50 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-23 08:05 -0500
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-23 13:47 +0000
Re: Make Forth Small Again! Coos Haak <htrofhc@gmail.com> - 2017-03-23 15:31 +0100
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-23 10:25 -0500
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-24 18:07 +0000
Re: Make Forth Small Again! john <anon@example.com> - 2017-05-03 10:45 +0100
Re: Make Forth Small Again! Mark Wills <markwills1970@gmail.com> - 2017-05-03 03:50 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 05:57 -0500
Re: Make Forth Small Again! john <anon@example.com> - 2017-05-03 12:08 +0100
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-05-03 12:26 +0100
Re: Make Forth Small Again! john <anon@example.com> - 2017-05-03 16:02 +0100
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-05-03 16:08 +0100
Re: Make Forth Small Again! john <anon@example.com> - 2017-05-03 16:35 +0100
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-05-03 18:28 +0100
Re: Make Forth Small Again! john <anon@example.com> - 2017-05-04 10:14 +0100
Re: Make Forth Small Again! Coos Haak <htrofhc@gmail.com> - 2017-05-04 12:44 +0200
Re: Make Forth Small Again! john <anon@example.com> - 2017-05-04 12:32 +0100
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 06:49 -0500
Re: Make Forth Small Again! crc <charles.childers@gmail.com> - 2017-05-04 04:50 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-05-04 13:14 +0100
Re: Make Forth Small Again! john <anon@example.com> - 2017-05-05 11:19 +0100
Re: Make Forth Small Again! Julian Fondren <julian.fondren@gmail.com> - 2017-05-05 04:16 -0700
Re: Make Forth Small Again! john <anon@example.com> - 2017-05-05 12:35 +0100
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-05-03 13:55 -0700
Re: Make Forth Small Again! Cecil Bayona <cbayona@cbayona.com> - 2017-05-03 17:04 -0500
Re: Make Forth Small Again! Ron Aaron <rambamist@gmail.com> - 2017-05-04 07:29 +0300
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:52 -0500
Re: Make Forth Small Again! Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-05-04 05:08 -0400
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 06:34 -0500
Re: Make Forth Small Again! Cecil Bayona <cbayona@cbayona.com> - 2017-05-04 11:17 -0500
Re: Make Forth Small Again! Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-05-03 19:03 +0100
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-24 18:12 +0000
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-25 13:49 +0000
Re: Make Forth Small Again! Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-03-23 00:58 -0400
Re: Make Forth Small Again! Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-03-23 00:57 -0400
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-22 20:55 -1000
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-23 18:05 -0700
Re: Make Forth Small Again! rickman <gnuarm@gmail.com> - 2017-03-22 15:57 -0400
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-25 10:29 +0000
Re: Make Forth Small Again! Julian Fondren <julian.fondren@gmail.com> - 2017-03-25 04:00 -0700
Re: Make Forth Small Again! rickman <gnuarm@gmail.com> - 2017-05-03 08:01 -0400
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 16:06 +0000
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-22 14:02 -0700
Re: Make Forth Small Again! Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-03-23 00:57 -0400
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-22 20:59 -1000
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-23 12:14 +0000
Re: Make Forth Small Again! albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-23 14:45 +0100
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-23 12:24 -1000
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-28 10:55 +1000
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-27 17:24 -1000
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-29 10:49 +1000
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-28 15:05 -1000
Re: Make Forth Small Again! Julian Fondren <julian.fondren@gmail.com> - 2017-03-28 19:06 -0700
Re: Make Forth Small Again! Ron Aaron <rambamist@gmail.com> - 2017-03-29 06:43 +0300
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-30 10:37 +1000
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-29 19:34 -1000
Re: Make Forth Small Again! stephen@mpeforth.com (Stephen Pelc) - 2017-03-23 10:36 +0000
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-23 11:33 +0000
Re: Make Forth Small Again! albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-23 14:58 +0100
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-24 17:57 +0000
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-24 22:32 +0000
Re: Make Forth Small Again! Mark Wills <markwills1970@gmail.com> - 2017-03-24 17:10 -0700
Re: Make Forth Small Again! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-25 07:31 +0000
Re: Make Forth Small Again! Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-07 08:50 +0200
Re: Make Forth Small Again! rickman <gnuarm@gmail.com> - 2017-03-20 17:57 -0400
Re: Make Forth Small Again! john <anon@example.com> - 2017-05-03 10:09 +0100
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-05-03 10:28 +0100
Re: Make Forth Small Again! rickman <gnuarm@gmail.com> - 2017-05-03 07:57 -0400
Re: Make Forth Small Again! stephen@mpeforth.com (Stephen Pelc) - 2017-05-03 13:07 +0000
Re: Make Forth Small Again! john <anon@example.com> - 2017-05-03 16:03 +0100
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-20 14:08 -1000
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-20 17:51 -0700
Re: Make Forth Small Again! minforth@arcor.de - 2017-03-20 13:12 -0700
Re: Make Forth Small Again! bruehlconsult@gmail.com - 2017-03-20 17:22 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-20 19:12 -0700
Re: Make Forth Small Again! Mark Wills <markwills1970@gmail.com> - 2017-03-21 02:30 -0700
Re: Make Forth Small Again! minforth@arcor.de - 2017-03-21 02:47 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-21 05:56 -0500
Re: Make Forth Small Again! rickman <gnuarm@gmail.com> - 2017-03-21 16:07 -0400
Re: Make Forth Small Again! "Elizabeth D. Rather" <erather@forth.com> - 2017-03-21 14:28 -1000
Re: Make Forth Small Again! "HAA" <someone@microsoft.com> - 2017-03-28 11:30 +1000
Re: Make Forth Small Again! Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-03-21 16:42 -0400
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-21 22:56 -0700
Re: Make Forth Small Again! Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 04:04 -0700
Re: Make Forth Small Again! Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-03-23 00:57 -0400
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-24 02:32 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-24 10:00 +0000
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-24 06:46 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-24 14:41 +0000
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-25 15:32 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-25 23:10 +0000
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-25 17:29 -0700
Re: Make Forth Small Again! Paul Rubin <no.email@nospam.invalid> - 2017-03-25 18:08 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-26 08:30 +0100
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-26 08:50 +0100
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-26 15:14 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-27 08:32 +0100
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-30 13:21 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-27 15:31 +0100
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-27 09:04 -0700
Re: Make Forth Small Again! Cecil Bayona <cbayona@cbayona.com> - 2017-03-27 11:52 -0500
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-27 18:41 +0100
Re: Make Forth Small Again! Cecil Bayona <cbayona@cbayona.com> - 2017-03-27 12:58 -0500
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-27 12:07 -0700
Re: Make Forth Small Again! foxaudioresearch@gmail.com - 2017-03-27 13:06 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-28 11:30 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-28 20:06 +0100
Re: Make Forth Small Again! albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-29 14:54 +0200
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-30 19:13 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-27 21:18 +0100
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-28 10:54 -0700
Re: Make Forth Small Again! Ron Aaron <rambamist@gmail.com> - 2017-03-27 21:53 +0300
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-27 22:29 +0100
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-30 14:07 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-30 16:03 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-31 09:28 +0100
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-31 03:36 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-31 19:29 -0700
Re: Make Forth Small Again! Mark Wills <markwills1970@gmail.com> - 2017-04-01 04:37 -0700
Re: Make Forth Small Again! Paul Rubin <no.email@nospam.invalid> - 2017-04-01 09:23 -0700
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-01 10:37 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-01 11:55 -0500
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-04-01 14:15 -0700
Re: Make Forth Small Again! Brad Eckert <hwfwguy@gmail.com> - 2017-05-06 12:55 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-05-07 12:08 +0100
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-05-07 09:04 -0700
Re: Make Forth Small Again! Coos Haak <htrofhc@gmail.com> - 2017-04-01 21:35 +0200
Re: Make Forth Small Again! Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-01 20:35 -0400
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-01 11:52 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-04-01 16:31 -0700
Re: Make Forth Small Again! Julian Fondren <julian.fondren@gmail.com> - 2017-04-01 20:54 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-04-01 21:13 -0700
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-05 16:06 -0700
Re: Make Forth Small Again! Alex <alex@rivadpm.com> - 2017-03-31 09:42 +0100
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-31 03:52 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-30 20:26 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-27 04:55 -0500
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-27 08:49 -0700
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-30 13:35 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-30 14:23 -0700
Re: Make Forth Small Again! Julian Fondren <julian.fondren@gmail.com> - 2017-03-30 15:28 -0700
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-30 23:20 -0700
Re: Make Forth Small Again! Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-31 02:29 -0700
Re: Make Forth Small Again! Julian Fondren <julian.fondren@gmail.com> - 2017-03-31 03:20 -0700
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-31 03:38 -0500
Re: Make Forth Small Again! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-24 09:17 -0500
Re: Make Forth Small Again! hughaguilar96@gmail.com - 2017-03-24 17:52 -0700
Page 1 of 11 [1] 2 3 … 11 Next page →
| From | Helmar Wodtke <helmwo@gmail.com> |
|---|---|
| Date | 2017-03-20 09:58 -0700 |
| Subject | Make Forth Small Again! |
| Message-ID | <b78c6e56-758d-475e-8973-d0e4a9112105@googlegroups.com> |
Well, I did not reply to BIG/GREAT ;) Most people think that GREAT is some BIGger advanture, what a Forth system has to offer. What do you expect? A GUI-API? What number of GUIs has Forth survived? How complicated it is, to connect Forth to any user interface? Do you really want a "BUTTON" ( gui x y w h s -- gui' ) word defined in standard? Forth has to become SMALL again. Something basic. Well, even if this is not convenient to some commercial vendors: Forth lost with its complexity. Instead of DPAN94 there should be something that *only* defines DUP DROP SWAP etc. Inside "core"-word of DPANS is for example 2OVER... Why? Today? 64bit... Or all these 8-bit-memory access? All crap. Nobody needs this. Americans can use it. But to get U-Umlaut is a problem in current "standards". Regards, -Helmar
[toc] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-03-20 10:34 -0700 |
| Message-ID | <87pohbhmxc.fsf@nightsong.com> |
| In reply to | #55968 |
Helmar Wodtke <helmwo@gmail.com> writes: > Forth has to become SMALL again. Something basic. Well, even if this > is not convenient to some commercial vendors: Forth lost with its > complexity. Instead of DPAN94 there should be something that *only* > defines DUP DROP SWAP etc. Would you use it? What would use it for? > Inside "core"-word of DPANS is for example 2OVER... Why? Today? That does surprise me but I checked and you're right. I would have expected 2over to be in the optional double-number extension.
[toc] | [prev] | [next] | [standalone]
| From | Helmar Wodtke <helmwo@gmail.com> |
|---|---|
| Date | 2017-03-20 10:51 -0700 |
| Message-ID | <380124c4-7591-4c55-a262-3d92b5bd4333@googlegroups.com> |
| In reply to | #55969 |
Am Montag, 20. März 2017 18:34:42 UTC+1 schrieb Paul Rubin: > Helmar Wodtke <helmwo@gmail.com> writes: > > Forth has to become SMALL again. Something basic. Well, even if this > > is not convenient to some commercial vendors: Forth lost with its > > complexity. Instead of DPAN94 there should be something that *only* > > defines DUP DROP SWAP etc. > > Would you use it? What would use it for? I use it for analysis of texts. For me, Forth needs KEY and EMIT as operating system bounds, "filter"-applications in Un*xoides. I like Forth for to have everything under control. No big dependencies to some non-understood libraries. I'm in a way "forced" to do it by myself. That's a good thing for what I want to do. Why I want to have standards? Because I want that in 10 years people can do the same using my program - may be using another Forth than what I actually tailored for my needs. > > Inside "core"-word of DPANS is for example 2OVER... Why? Today? > > That does surprise me but I checked and you're right. I would have > expected 2over to be in the optional double-number extension. Yes... Regards, -Helmar
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-20 18:08 +0000 |
| Message-ID | <oap5lo$6eg$1@dont-email.me> |
| In reply to | #55970 |
On 3/20/2017 17:51, Helmar Wodtke wrote: > Am Montag, 20. März 2017 18:34:42 UTC+1 schrieb Paul Rubin: >> Helmar Wodtke <helmwo@gmail.com> writes: >>> Inside "core"-word of DPANS is for example 2OVER... Why? Today? >> >> That does surprise me but I checked and you're right. I would have >> expected 2over to be in the optional double-number extension. > > Yes... > Then it would have been DOVER. 2 indicates 2 cells, not a double, and it's required for managing strings of the address length variety. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | NN <november.nihal@gmail.com> |
|---|---|
| Date | 2017-03-20 12:19 -0700 |
| Message-ID | <61eecd28-ac22-4961-bcc1-1505a39c4b96@googlegroups.com> |
| In reply to | #55970 |
You may not like 2drop, 2dup, 2swap and 2over but handling string as (addr len) pairs on the stack would become a lot harder. If you are aware of a better way that doesnt involve using global/local variables then I would be interest to know how. NN
[toc] | [prev] | [next] | [standalone]
| From | Helmar Wodtke <helmwo@gmail.com> |
|---|---|
| Date | 2017-03-21 05:51 -0700 |
| Message-ID | <24c2151a-5dca-4233-920f-1b192ea73de0@googlegroups.com> |
| In reply to | #55973 |
Am Montag, 20. März 2017 20:19:54 UTC+1 schrieb NN: > You may not like 2drop, 2dup, 2swap and 2over but handling string as (addr len) pairs on the stack would become a lot harder. > > If you are aware of a better way that doesnt involve using global/local variables then I would be interest to know how. > > NN : 2DROP DROP DROP ; : 2DUP OVER OVER ; : 2SWAP 3 ROLL 3 ROLL ; : 2OVER 3 PICK 3 PICK ; If "ROLL" and "PICK" would be inside CORE, and not in CORE-EXT, you would not need to have these words inside CORE. You always have to implement PICK and ROLL usually. These 2xxx-words are kind of optimizations. Even "SWAP", "OVER" and "ROT" could be inside CORE-EXT (you would always implement this). Regards, -Helmar
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <htrofhc@gmail.com> |
|---|---|
| Date | 2017-03-21 15:04 +0100 |
| Message-ID | <stkuw1kczvae.1cdvydn8y22gn.dlg@40tude.net> |
| In reply to | #56003 |
Op Tue, 21 Mar 2017 05:51:51 -0700 (PDT) schreef Helmar Wodtke: > Am Montag, 20. März 2017 20:19:54 UTC+1 schrieb NN: >> You may not like 2drop, 2dup, 2swap and 2over but handling string as (addr len) pairs on the stack would become a lot harder. >> >> If you are aware of a better way that doesnt involve using global/local variables then I would be interest to know how. >> >> NN > >: 2DROP DROP DROP ; >: 2DUP OVER OVER ; >: 2SWAP 3 ROLL 3 ROLL ; >: 2OVER 3 PICK 3 PICK ; > > If "ROLL" and "PICK" would be inside CORE, and not in CORE-EXT, you would not need to have these words inside CORE. You always have to implement PICK and ROLL usually. These 2xxx-words are kind of optimizations. Even "SWAP", "OVER" and "ROT" could be inside CORE-EXT (you would always implement this). > > Regards, > -Helmar I never use PICK or ROLL. I always have to count on my fingers to devine what the magic number must be. groet Coos
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-03-21 11:22 -1000 |
| Message-ID | <c5mdneSqTtUdBEzFnZ2dnUU7-enNnZ2d@supernews.com> |
| In reply to | #56005 |
On 3/21/17 4:04 AM, Coos Haak wrote: > Op Tue, 21 Mar 2017 05:51:51 -0700 (PDT) schreef Helmar Wodtke: > >> Am Montag, 20. März 2017 20:19:54 UTC+1 schrieb NN: >>> You may not like 2drop, 2dup, 2swap and 2over but handling string as (addr len) pairs on the stack would become a lot harder. >>> >>> If you are aware of a better way that doesnt involve using global/local variables then I would be interest to know how. >>> >>> NN >> >> : 2DROP DROP DROP ; >> : 2DUP OVER OVER ; >> : 2SWAP 3 ROLL 3 ROLL ; >> : 2OVER 3 PICK 3 PICK ; >> >> If "ROLL" and "PICK" would be inside CORE, and not in CORE-EXT, you would not need to have these words inside CORE. You always have to implement PICK and ROLL usually. These 2xxx-words are kind of optimizations. Even "SWAP", "OVER" and "ROT" could be inside CORE-EXT (you would always implement this). >> >> Regards, >> -Helmar > > I never use PICK or ROLL. I always have to count on my fingers to > devine what the magic number must be. PICK and ROLL are indicators of poor stack management, which is why they're in CORE-EXT. And all these implementations of the 2's words are grossly inefficient. Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | Helmar Wodtke <helmwo@gmail.com> |
|---|---|
| Date | 2017-03-21 14:47 -0700 |
| Message-ID | <5dd213be-6c05-4932-90c8-46e902143d04@googlegroups.com> |
| In reply to | #56060 |
Am Dienstag, 21. März 2017 22:22:14 UTC+1 schrieb Elizabeth D. Rather:
> PICK and ROLL are indicators of poor stack management, which is why
> they're in CORE-EXT. And all these implementations of the 2's words are
> grossly inefficient.
Indeed. But sorting what's in CORE-EXT you did by judging in claiming, it's always a poor stack management? But these words like PICK and ROLL are tools to generate - not to use of course. Say with PICK:
VARIABLE PICKED
: PICK
PICKED OFF
BEGIN ?DUP WHILE
1- SWAP >R 1 PICKED +!
REPEAT
DUP
BEGIN PICKED @ WHILE -1 PICKED +!
R> SWAP
REPEAT ;
In assembly or from a "core" point of view, this is much easier to implement.
Regards,
-Helmar
>
> Cheers,
> Elizabeth
>
> --
> Elizabeth R. Conklin
> FORTH, Inc.
> 6080 Center Drive, Suite 600
> Los Angeles, CA 90045
> USA
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <htrofhc@gmail.com> |
|---|---|
| Date | 2017-03-22 01:34 +0100 |
| Message-ID | <xew9oyk6uyi8$.6xa3r81ej5h5$.dlg@40tude.net> |
| In reply to | #56063 |
Op Tue, 21 Mar 2017 14:47:01 -0700 (PDT) schreef Helmar Wodtke:
> Am Dienstag, 21. März 2017 22:22:14 UTC+1 schrieb Elizabeth D. Rather:
>
>> PICK and ROLL are indicators of poor stack management, which is why
>> they're in CORE-EXT. And all these implementations of the 2's words are
>> grossly inefficient.
>
> Indeed. But sorting what's in CORE-EXT you did by judging in claiming, it's always a poor stack management? But these words like PICK and ROLL are tools to generate - not to use of course. Say with PICK:
>
> VARIABLE PICKED
>: PICK
> PICKED OFF
> BEGIN ?DUP WHILE
> 1- SWAP >R 1 PICKED +!
> REPEAT
> DUP
> BEGIN PICKED @ WHILE -1 PICKED +!
> R> SWAP
> REPEAT ;
>
> In assembly or from a "core" point of view, this is much easier to implement.
>
> Regards,
> -Helmar
These are much shorter. Probably faster too:
: PICK
DUP
IF SWAP >R 1- RECURSE R> SWAP EXIT
THEN
DROP DUP
;
: ROLL
DUP
IF SWAP >R 1- RECURSE R> SWAP EXIT
THEN
DROP
;
groet Coos
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-03-25 17:27 +1100 |
| Message-ID | <ob52ge$p7c$1@gioia.aioe.org> |
| In reply to | #56060 |
Elizabeth D. Rather wrote: > On 3/21/17 4:04 AM, Coos Haak wrote: > > Op Tue, 21 Mar 2017 05:51:51 -0700 (PDT) schreef Helmar Wodtke: > > > >> Am Montag, 20. März 2017 20:19:54 UTC+1 schrieb NN: > >>> You may not like 2drop, 2dup, 2swap and 2over but handling string as (addr len) > >>> pairs on the stack would become a lot harder. > >>> > >>> If you are aware of a better way that doesnt involve using global/local variables > >>> then I would be interest to know how. > >>> > >>> NN > >> > >> : 2DROP DROP DROP ; > >> : 2DUP OVER OVER ; > >> : 2SWAP 3 ROLL 3 ROLL ; > >> : 2OVER 3 PICK 3 PICK ; > >> > >> If "ROLL" and "PICK" would be inside CORE, and not in CORE-EXT, you would not need > >> to have these words inside CORE. You always have to implement PICK and ROLL usually. > >> These 2xxx-words are kind of optimizations. Even "SWAP", "OVER" and "ROT" could be > >> inside CORE-EXT (you would always implement this). > >> > >> Regards, > >> -Helmar > > > > I never use PICK or ROLL. I always have to count on my fingers to > > devine what the magic number must be. > > PICK and ROLL are indicators of poor stack management, which is why > they're in CORE-EXT. And all these implementations of the 2's words are > grossly inefficient. > > Cheers, > Elizabeth : DUM* ( ud1 ud2 -- uq ) over 4 pick um* 2 pick 6 roll um* rot 0 d+ >r 3 roll 4 pick um* rot 0 d+ 3 roll 4 roll um* rot 0 d+ r> 0 d+ ; Anyone with a faster version in high-level?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-25 00:06 -0700 |
| Message-ID | <8d2cea2d-68fe-4e40-850d-9d19cc28740c@googlegroups.com> |
| In reply to | #56258 |
On Friday, March 24, 2017 at 11:25:22 PM UTC-7, HAA wrote: > Elizabeth D. Rather wrote: > > On 3/21/17 4:04 AM, Coos Haak wrote: > > > Op Tue, 21 Mar 2017 05:51:51 -0700 (PDT) schreef Helmar Wodtke: > > > > > >> Am Montag, 20. März 2017 20:19:54 UTC+1 schrieb NN: > > >>> You may not like 2drop, 2dup, 2swap and 2over but handling string as (addr len) > > >>> pairs on the stack would become a lot harder. > > >>> > > >>> If you are aware of a better way that doesnt involve using global/local variables > > >>> then I would be interest to know how. > > >>> > > >>> NN > > >> > > >> : 2DROP DROP DROP ; > > >> : 2DUP OVER OVER ; > > >> : 2SWAP 3 ROLL 3 ROLL ; > > >> : 2OVER 3 PICK 3 PICK ; > > >> > > >> If "ROLL" and "PICK" would be inside CORE, and not in CORE-EXT, you would not need > > >> to have these words inside CORE. You always have to implement PICK and ROLL usually. > > >> These 2xxx-words are kind of optimizations. Even "SWAP", "OVER" and "ROT" could be > > >> inside CORE-EXT (you would always implement this). > > >> > > >> Regards, > > >> -Helmar > > > > > > I never use PICK or ROLL. I always have to count on my fingers to > > > devine what the magic number must be. > > > > PICK and ROLL are indicators of poor stack management, which is why > > they're in CORE-EXT. And all these implementations of the 2's words are > > grossly inefficient. > > > > Cheers, > > Elizabeth > > : DUM* ( ud1 ud2 -- uq ) > over 4 pick um* 2 pick 6 roll um* rot 0 d+ >r > 3 roll 4 pick um* rot 0 d+ 3 roll 4 roll um* > rot 0 d+ r> 0 d+ ; > > Anyone with a faster version in high-level? That code is terrible in both SwiftForth and VFX. The problem is that ROLL is inefficient. PICK isn't bad though. VFX: see dum* DUM* ( 004E1BD0 8B4508 ) MOV EAX, [EBP+08] ( 004E1BD3 F76500 ) MUL [EBP] ( 004E1BD6 8D6DF0 ) LEA EBP, [EBP+-10] ( 004E1BD9 895D00 ) MOV [EBP], EBX ( 004E1BDC 895504 ) MOV [EBP+04], EDX ( 004E1BDF 894508 ) MOV [EBP+08], EAX ( 004E1BE2 895D0C ) MOV [EBP+0C], EBX ( 004E1BE5 BB06000000 ) MOV EBX, 00000006 ( 004E1BEA E86D5FF2FF ) CALL 00407B5C ROLL ( 004E1BEF 8BC3 ) MOV EAX, EBX ( 004E1BF1 F76500 ) MUL [EBP] ( 004E1BF4 034504 ) ADD EAX, [EBP+04] ( 004E1BF7 83D200 ) ADC EDX, 00 ( 004E1BFA 52 ) PUSH EDX ( 004E1BFB BB03000000 ) MOV EBX, 00000003 ( 004E1C00 894504 ) MOV [EBP+04], EAX ( 004E1C03 8D6D04 ) LEA EBP, [EBP+04] ( 004E1C06 E8515FF2FF ) CALL 00407B5C ROLL ( 004E1C0B 8B450C ) MOV EAX, [EBP+0C] ( 004E1C0E F7E3 ) MUL EBX ( 004E1C10 034500 ) ADD EAX, [EBP] ( 004E1C13 83D200 ) ADC EDX, 00 ( 004E1C16 8D6DFC ) LEA EBP, [EBP+-04] ( 004E1C19 BB03000000 ) MOV EBX, 00000003 ( 004E1C1E 895500 ) MOV [EBP], EDX ( 004E1C21 894504 ) MOV [EBP+04], EAX ( 004E1C24 E8335FF2FF ) CALL 00407B5C ROLL ( 004E1C29 8D6DFC ) LEA EBP, [EBP+-04] ( 004E1C2C 895D00 ) MOV [EBP], EBX ( 004E1C2F BB04000000 ) MOV EBX, 00000004 ( 004E1C34 E8235FF2FF ) CALL 00407B5C ROLL ( 004E1C39 8BC3 ) MOV EAX, EBX ( 004E1C3B F76500 ) MUL [EBP] ( 004E1C3E 034504 ) ADD EAX, [EBP+04] ( 004E1C41 83D200 ) ADC EDX, 00 ( 004E1C44 5B ) POP EBX ( 004E1C45 03D8 ) ADD EBX, EAX ( 004E1C47 83D200 ) ADC EDX, 00 ( 004E1C4A 895D04 ) MOV [EBP+04], EBX ( 004E1C4D 8BDA ) MOV EBX, EDX ( 004E1C4F 8D6D04 ) LEA EBP, [EBP+04] ( 004E1C52 C3 ) NEXT, ( 131 bytes, 42 instructions ) ok see roll ROLL ( 00407B5C 53 ) PUSH EBX ( 00407B5D 8B5C9D00 ) MOV EBX, [EBP+EBX*4] ( 00407B61 83ED04 ) SUB EBP, 04 ( 00407B64 895D00 ) MOV [EBP], EBX ( 00407B67 8BDD ) MOV EBX, EBP ( 00407B69 8BD3 ) MOV EDX, EBX ( 00407B6B 83C304 ) ADD EBX, 04 ( 00407B6E 59 ) POP ECX ( 00407B6F 41 ) INC ECX ( 00407B70 C1E102 ) SHL ECX, 02 ( 00407B73 8D6DF8 ) LEA EBP, [EBP+-08] ( 00407B76 895D00 ) MOV [EBP], EBX ( 00407B79 895504 ) MOV [EBP+04], EDX ( 00407B7C 8BD9 ) MOV EBX, ECX ( 00407B7E E859CFFFFF ) CALL 00404ADC CMOVE> ( 00407B83 8B5D00 ) MOV EBX, [EBP] ( 00407B86 8D6D04 ) LEA EBP, [EBP+04] ( 00407B89 C3 ) NEXT, ( 46 bytes, 18 instructions ) ok see cmove> CMOVE> ( 00404ADC 8B4D04 ) MOV ECX, [EBP+04] ( 00404ADF 8B5500 ) MOV EDX, [EBP] ( 00404AE2 53 ) PUSH EBX ( 00404AE3 8D4C19FC ) LEA ECX, [ECX+EBX+-04] ( 00404AE7 8D541AFC ) LEA EDX, [EDX+EBX+-04] ( 00404AEB C1EB02 ) SHR EBX, 02 ( 00404AEE 740F ) JZ/E 00404AFF ( 00404AF0 8B01 ) MOV EAX, 0 [ECX] ( 00404AF2 83EB01 ) SUB EBX, 01 ( 00404AF5 8D49FC ) LEA ECX, [ECX+-04] ( 00404AF8 8902 ) MOV 0 [EDX], EAX ( 00404AFA 8D52FC ) LEA EDX, [EDX+-04] ( 00404AFD 75F1 ) JNZ/NE 00404AF0 ( 00404AFF 5B ) POP EBX ( 00404B00 83E303 ) AND EBX, 03 ( 00404B03 8D4903 ) LEA ECX, [ECX+03] ( 00404B06 8D5203 ) LEA EDX, [EDX+03] ( 00404B09 740F ) JZ/E 00404B1A ( 00404B0B 8A01 ) MOV AL, 0 [ECX] ( 00404B0D 83EB01 ) SUB EBX, 01 ( 00404B10 8D49FF ) LEA ECX, [ECX+-01] ( 00404B13 8802 ) MOV 0 [EDX], AL ( 00404B15 8D52FF ) LEA EDX, [EDX+-01] ( 00404B18 75F1 ) JNZ/NE 00404B0B ( 00404B1A 8B5D08 ) MOV EBX, [EBP+08] ( 00404B1D 8D6D0C ) LEA EBP, [EBP+0C] ( 00404B20 C3 ) NEXT, ( 69 bytes, 27 instructions ) ok ---------------------------------------------------------------------------- SwiftForth: see dum* 492D5F 4 # EBP SUB 83ED04 492D62 EBX 0 [EBP] MOV 895D00 492D65 4 [EBP] EBX MOV 8B5D04 492D68 4 # EBP SUB 83ED04 492D6B EBX 0 [EBP] MOV 895D00 492D6E 10 [EBP] EBX MOV 8B5D10 492D71 0 [EBP] EAX MOV 8B4500 492D74 EBX MUL F7E3 492D76 EAX 0 [EBP] MOV 894500 492D79 EDX EBX MOV 8BDA 492D7B 4 # EBP SUB 83ED04 492D7E EBX 0 [EBP] MOV 895D00 492D81 8 [EBP] EBX MOV 8B5D08 492D84 4 # EBP SUB 83ED04 492D87 EBX 0 [EBP] MOV 895D00 492D8A 6 # EBX MOV BB06000000 492D8F 40658F ( ROLL ) CALL E8FB37F7FF 492D94 0 [EBP] EAX MOV 8B4500 492D97 EBX MUL F7E3 492D99 EAX 0 [EBP] MOV 894500 492D9C EDX EBX MOV 8BDA 492D9E EBX ECX MOV 8BCB 492DA0 4 [EBP] EBX MOV 8B5D04 492DA3 0 [EBP] EAX MOV 8B4500 492DA6 EAX 4 [EBP] MOV 894504 492DA9 ECX 0 [EBP] MOV 894D00 492DAC 4 # EBP SUB 83ED04 492DAF EBX 0 [EBP] MOV 895D00 492DB2 0 # EBX MOV BB00000000 492DB7 0 [EBP] EAX MOV 8B4500 492DBA 8 [EBP] EAX ADD 034508 492DBD 4 [EBP] EBX ADC 135D04 492DC0 EAX 8 [EBP] MOV 894508 492DC3 8 # EBP ADD 83C508 492DC6 EBX PUSH 53 492DC7 3 # EBX MOV BB03000000 492DCC 40658F ( ROLL ) CALL E8BE37F7FF 492DD1 4 # EBP SUB 83ED04 492DD4 EBX 0 [EBP] MOV 895D00 492DD7 10 [EBP] EBX MOV 8B5D10 492DDA 0 [EBP] EAX MOV 8B4500 492DDD EBX MUL F7E3 492DDF EAX 0 [EBP] MOV 894500 492DE2 EDX EBX MOV 8BDA 492DE4 EBX ECX MOV 8BCB 492DE6 4 [EBP] EBX MOV 8B5D04 492DE9 0 [EBP] EAX MOV 8B4500 492DEC EAX 4 [EBP] MOV 894504 492DEF ECX 0 [EBP] MOV 894D00 492DF2 4 # EBP SUB 83ED04 492DF5 EBX 0 [EBP] MOV 895D00 492DF8 0 # EBX MOV BB00000000 492DFD 0 [EBP] EAX MOV 8B4500 492E00 8 [EBP] EAX ADD 034508 492E03 4 [EBP] EBX ADC 135D04 492E06 EAX 8 [EBP] MOV 894508 492E09 8 # EBP ADD 83C508 492E0C 4 # EBP SUB 83ED04 492E0F EBX 0 [EBP] MOV 895D00 492E12 3 # EBX MOV BB03000000 492E17 40658F ( ROLL ) CALL E87337F7FF 492E1C 4 # EBP SUB 83ED04 492E1F EBX 0 [EBP] MOV 895D00 492E22 4 # EBX MOV BB04000000 492E27 40658F ( ROLL ) CALL E86337F7FF 492E2C 0 [EBP] EAX MOV 8B4500 492E2F EBX MUL F7E3 492E31 EAX 0 [EBP] MOV 894500 492E34 EDX EBX MOV 8BDA 492E36 EBX ECX MOV 8BCB 492E38 4 [EBP] EBX MOV 8B5D04 492E3B 0 [EBP] EAX MOV 8B4500 492E3E EAX 4 [EBP] MOV 894504 492E41 ECX 0 [EBP] MOV 894D00 492E44 4 # EBP SUB 83ED04 492E47 EBX 0 [EBP] MOV 895D00 492E4A 0 # EBX MOV BB00000000 492E4F 0 [EBP] EAX MOV 8B4500 492E52 8 [EBP] EAX ADD 034508 492E55 4 [EBP] EBX ADC 135D04 492E58 EAX 8 [EBP] MOV 894508 492E5B 8 # EBP ADD 83C508 492E5E 4 # EBP SUB 83ED04 492E61 EBX 0 [EBP] MOV 895D00 492E64 EBX POP 5B 492E65 4 # EBP SUB 83ED04 492E68 EBX 0 [EBP] MOV 895D00 492E6B 0 # EBX MOV BB00000000 492E70 0 [EBP] EAX MOV 8B4500 492E73 8 [EBP] EAX ADD 034508 492E76 4 [EBP] EBX ADC 135D04 492E79 EAX 8 [EBP] MOV 894508 492E7C 8 # EBP ADD 83C508 492E7F RET C3 ok see roll 40658F 0 [EBP] [EBX*4] EAX MOV 8B449D00 406593 EBX EBX TEST 85DB 406595 4065A2 JZ 740B 406597 -4 [EBP] [EBX*4] ECX MOV 8B4C9DFC 40659B ECX 0 [EBP] [EBX*4] MOV 894C9D00 40659F EBX DEC 4B 4065A0 406597 JNZ 75F5 4065A2 4 # EBP ADD 83C504 4065A5 EAX EBX MOV 8BD8 4065A7 RET C3 ok
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-25 01:02 -0700 |
| Message-ID | <9f14227c-bc99-495f-9c0f-f04321e76e57@googlegroups.com> |
| In reply to | #56261 |
On Saturday, March 25, 2017 at 12:06:21 AM UTC-7, hughag...@gmail.com wrote:
> On Friday, March 24, 2017 at 11:25:22 PM UTC-7, HAA wrote:
> > : DUM* ( ud1 ud2 -- uq )
> > over 4 pick um* 2 pick 6 roll um* rot 0 d+ >r
> > 3 roll 4 pick um* rot 0 d+ 3 roll 4 roll um*
> > rot 0 d+ r> 0 d+ ;
> >
> > Anyone with a faster version in high-level?
>
> That code is terrible in both SwiftForth and VFX. The problem is that ROLL is inefficient. PICK isn't bad though.
Here is a version using locals:
\ H2L2
\ H1L1
\ -----------
\ H1L1
\ H2L1
\ H1L2
\ H2L2
\ -----------
\ C4C3C2C1
: dum* ( ud1 ud2 -- uq )
{ L1 H1 L2 H2 | C4 C3 C2 C1 -- uq }
L1 L2 um* to C2 to C1
L1 H2 um* to C3 +to C2
H1 L2 um* +to C3 +to C2
H1 H2 um* to C4 +to C3
C1 C2 C3 C4 ;
This works out okay under VFX. It is terrible under SwiftForth because SwiftForth doesn't have a register for the local-frame pointer but instead has a user variable.
Here is the code (not including the code to initialize the locals):
VFX:
see dum*
DUM*
( 004DA040 8D6DF0 ) LEA EBP, [EBP+-10]
( 004DA043 C7450000000000 ) MOV DWord Ptr [EBP], 00000000
( 004DA04A C7450400000000 ) MOV DWord Ptr [EBP+04], 00000000
( 004DA051 C7450800000000 ) MOV DWord Ptr [EBP+08], 00000000
( 004DA058 895D0C ) MOV [EBP+0C], EBX
( 004DA05B BB00000000 ) MOV EBX, 00000000
( 004DA060 E81FA5F2FF08000000 ) CALL 00404584 MAKELVS #args = 0008, #locals = 0000 cells
( 004DA069 8B471C ) MOV EAX, [EDI+1C]
( 004DA06C F76724 ) MUL [EDI+24]
( 004DA06F 89570C ) MOV [EDI+0C], EDX
( 004DA072 894708 ) MOV [EDI+08], EAX
( 004DA075 8B4718 ) MOV EAX, [EDI+18]
( 004DA078 F76724 ) MUL [EDI+24]
( 004DA07B 895710 ) MOV [EDI+10], EDX
( 004DA07E 03470C ) ADD EAX, [EDI+0C]
( 004DA081 89470C ) MOV [EDI+0C], EAX
( 004DA084 8B471C ) MOV EAX, [EDI+1C]
( 004DA087 F76720 ) MUL [EDI+20]
( 004DA08A 035710 ) ADD EDX, [EDI+10]
( 004DA08D 895710 ) MOV [EDI+10], EDX
( 004DA090 03470C ) ADD EAX, [EDI+0C]
( 004DA093 89470C ) MOV [EDI+0C], EAX
( 004DA096 8B4718 ) MOV EAX, [EDI+18]
( 004DA099 F76720 ) MUL [EDI+20]
( 004DA09C 895714 ) MOV [EDI+14], EDX
( 004DA09F 034710 ) ADD EAX, [EDI+10]
( 004DA0A2 894710 ) MOV [EDI+10], EAX
( 004DA0A5 8D6DF0 ) LEA EBP, [EBP+-10]
( 004DA0A8 8B5710 ) MOV EDX, [EDI+10]
( 004DA0AB 895500 ) MOV [EBP], EDX
( 004DA0AE 8B570C ) MOV EDX, [EDI+0C]
( 004DA0B1 895504 ) MOV [EBP+04], EDX
( 004DA0B4 8B5708 ) MOV EDX, [EDI+08]
( 004DA0B7 895508 ) MOV [EBP+08], EDX
( 004DA0BA 895D0C ) MOV [EBP+0C], EBX
( 004DA0BD 8B5F14 ) MOV EBX, [EDI+14]
( 004DA0C0 8B6704 ) MOV ESP, [EDI+04]
( 004DA0C3 8B3F ) MOV EDI, 0 [EDI]
( 004DA0C5 C3 ) NEXT,
( 134 bytes, 39 instructions )
ok
---------------------------------------------------------------------------
SwiftForth:
see dum*
48A26F 8 # EBP SUB 83ED08
48A272 EBX 4 [EBP] MOV 895D04
48A275 0 # 0 [EBP] MOV C7450000000000
48A27C 0 # EBX MOV BB00000000
48A281 8 # EBP SUB 83ED08
48A284 EBX 4 [EBP] MOV 895D04
48A287 0 # 0 [EBP] MOV C7450000000000
48A28E 0 # EBX MOV BB00000000
48A293 4 # EBP SUB 83ED04
48A296 EBX 0 [EBP] MOV 895D00
48A299 20 # EBX MOV BB20000000
48A29E 42948F ( LSPACE ) CALL E8ECF1F9FF
48A2A3 9C [ESI] EAX MOV 8B869C000000
48A2A9 EBX 0 [EAX] MOV 8918
48A2AB 0 [EBP] EBX MOV 8B5D00
48A2AE 4 # EBP ADD 83C504
48A2B1 9C [ESI] EAX MOV 8B869C000000
48A2B7 EBX 4 [EAX] MOV 895804
48A2BA 0 [EBP] EBX MOV 8B5D00
48A2BD 4 # EBP ADD 83C504
48A2C0 9C [ESI] EAX MOV 8B869C000000
48A2C6 EBX 8 [EAX] MOV 895808
48A2C9 0 [EBP] EBX MOV 8B5D00
48A2CC 4 # EBP ADD 83C504
48A2CF 9C [ESI] EAX MOV 8B869C000000
48A2D5 EBX C [EAX] MOV 89580C
48A2D8 0 [EBP] EBX MOV 8B5D00
48A2DB 4 # EBP ADD 83C504
48A2DE 9C [ESI] EAX MOV 8B869C000000
48A2E4 EBX 10 [EAX] MOV 895810
48A2E7 0 [EBP] EBX MOV 8B5D00
48A2EA 4 # EBP ADD 83C504
48A2ED 9C [ESI] EAX MOV 8B869C000000
48A2F3 EBX 14 [EAX] MOV 895814
48A2F6 0 [EBP] EBX MOV 8B5D00
48A2F9 4 # EBP ADD 83C504
48A2FC 9C [ESI] EAX MOV 8B869C000000
48A302 EBX 18 [EAX] MOV 895818
48A305 0 [EBP] EBX MOV 8B5D00
48A308 4 # EBP ADD 83C504
48A30B 9C [ESI] EAX MOV 8B869C000000
48A311 EBX 1C [EAX] MOV 89581C
48A314 0 [EBP] EBX MOV 8B5D00
48A317 4 # EBP ADD 83C504
48A31A 4 # EBP SUB 83ED04
48A31D EBX 0 [EBP] MOV 895D00
48A320 9C [ESI] EBX MOV 8B9E9C000000
48A326 1C [EBX] EBX MOV 8B5B1C
48A329 4 # EBP SUB 83ED04
48A32C EBX 0 [EBP] MOV 895D00
48A32F 9C [ESI] EBX MOV 8B9E9C000000
48A335 14 [EBX] EBX MOV 8B5B14
48A338 0 [EBP] EAX MOV 8B4500
48A33B EBX MUL F7E3
48A33D EAX 0 [EBP] MOV 894500
48A340 EDX EBX MOV 8BDA
48A342 9C [ESI] EAX MOV 8B869C000000
48A348 EBX 4 [EAX] MOV 895804
48A34B 0 [EBP] EBX MOV 8B5D00
48A34E 4 # EBP ADD 83C504
48A351 9C [ESI] EAX MOV 8B869C000000
48A357 EBX 0 [EAX] MOV 8918
48A359 0 [EBP] EBX MOV 8B5D00
48A35C 4 # EBP ADD 83C504
48A35F 4 # EBP SUB 83ED04
48A362 EBX 0 [EBP] MOV 895D00
48A365 9C [ESI] EBX MOV 8B9E9C000000
48A36B 1C [EBX] EBX MOV 8B5B1C
48A36E 4 # EBP SUB 83ED04
48A371 EBX 0 [EBP] MOV 895D00
48A374 9C [ESI] EBX MOV 8B9E9C000000
48A37A 10 [EBX] EBX MOV 8B5B10
48A37D 0 [EBP] EAX MOV 8B4500
48A380 EBX MUL F7E3
48A382 EAX 0 [EBP] MOV 894500
48A385 EDX EBX MOV 8BDA
48A387 9C [ESI] EAX MOV 8B869C000000
48A38D EBX 8 [EAX] MOV 895808
48A390 0 [EBP] EBX MOV 8B5D00
48A393 4 # EBP ADD 83C504
48A396 4 # EBP SUB 83ED04
48A399 EBX 0 [EBP] MOV 895D00
48A39C 9C [ESI] EBX MOV 8B9E9C000000
48A3A2 4 [EBX] EBX MOV 8B5B04
48A3A5 0 [EBP] EBX ADD 035D00
48A3A8 4 # EBP ADD 83C504
48A3AB 9C [ESI] EAX MOV 8B869C000000
48A3B1 EBX 4 [EAX] MOV 895804
48A3B4 0 [EBP] EBX MOV 8B5D00
48A3B7 4 # EBP ADD 83C504
48A3BA 4 # EBP SUB 83ED04
48A3BD EBX 0 [EBP] MOV 895D00
48A3C0 9C [ESI] EBX MOV 8B9E9C000000
48A3C6 18 [EBX] EBX MOV 8B5B18
48A3C9 4 # EBP SUB 83ED04
48A3CC EBX 0 [EBP] MOV 895D00
48A3CF 9C [ESI] EBX MOV 8B9E9C000000
48A3D5 14 [EBX] EBX MOV 8B5B14
48A3D8 0 [EBP] EAX MOV 8B4500
48A3DB EBX MUL F7E3
48A3DD EAX 0 [EBP] MOV 894500
48A3E0 EDX EBX MOV 8BDA
48A3E2 4 # EBP SUB 83ED04
48A3E5 EBX 0 [EBP] MOV 895D00
48A3E8 9C [ESI] EBX MOV 8B9E9C000000
48A3EE 8 [EBX] EBX MOV 8B5B08
48A3F1 0 [EBP] EBX ADD 035D00
48A3F4 4 # EBP ADD 83C504
48A3F7 9C [ESI] EAX MOV 8B869C000000
48A3FD EBX 8 [EAX] MOV 895808
48A400 0 [EBP] EBX MOV 8B5D00
48A403 4 # EBP ADD 83C504
48A406 4 # EBP SUB 83ED04
48A409 EBX 0 [EBP] MOV 895D00
48A40C 9C [ESI] EBX MOV 8B9E9C000000
48A412 4 [EBX] EBX MOV 8B5B04
48A415 0 [EBP] EBX ADD 035D00
48A418 4 # EBP ADD 83C504
48A41B 9C [ESI] EAX MOV 8B869C000000
48A421 EBX 4 [EAX] MOV 895804
48A424 0 [EBP] EBX MOV 8B5D00
48A427 4 # EBP ADD 83C504
48A42A 4 # EBP SUB 83ED04
48A42D EBX 0 [EBP] MOV 895D00
48A430 9C [ESI] EBX MOV 8B9E9C000000
48A436 18 [EBX] EBX MOV 8B5B18
48A439 4 # EBP SUB 83ED04
48A43C EBX 0 [EBP] MOV 895D00
48A43F 9C [ESI] EBX MOV 8B9E9C000000
48A445 10 [EBX] EBX MOV 8B5B10
48A448 0 [EBP] EAX MOV 8B4500
48A44B EBX MUL F7E3
48A44D EAX 0 [EBP] MOV 894500
48A450 EDX EBX MOV 8BDA
48A452 9C [ESI] EAX MOV 8B869C000000
48A458 EBX C [EAX] MOV 89580C
48A45B 0 [EBP] EBX MOV 8B5D00
48A45E 4 # EBP ADD 83C504
48A461 4 # EBP SUB 83ED04
48A464 EBX 0 [EBP] MOV 895D00
48A467 9C [ESI] EBX MOV 8B9E9C000000
48A46D 8 [EBX] EBX MOV 8B5B08
48A470 0 [EBP] EBX ADD 035D00
48A473 4 # EBP ADD 83C504
48A476 9C [ESI] EAX MOV 8B869C000000
48A47C EBX 8 [EAX] MOV 895808
48A47F 0 [EBP] EBX MOV 8B5D00
48A482 4 # EBP ADD 83C504
48A485 4 # EBP SUB 83ED04
48A488 EBX 0 [EBP] MOV 895D00
48A48B 9C [ESI] EBX MOV 8B9E9C000000
48A491 0 [EBX] EBX MOV 8B1B
48A493 4 # EBP SUB 83ED04
48A496 EBX 0 [EBP] MOV 895D00
48A499 9C [ESI] EBX MOV 8B9E9C000000
48A49F 4 [EBX] EBX MOV 8B5B04
48A4A2 4 # EBP SUB 83ED04
48A4A5 EBX 0 [EBP] MOV 895D00
48A4A8 9C [ESI] EBX MOV 8B9E9C000000
48A4AE 8 [EBX] EBX MOV 8B5B08
48A4B1 4 # EBP SUB 83ED04
48A4B4 EBX 0 [EBP] MOV 895D00
48A4B7 9C [ESI] EBX MOV 8B9E9C000000
48A4BD C [EBX] EBX MOV 8B5B0C
48A4C0 RET C3 ok
ok
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-25 01:05 -0700 |
| Message-ID | <a722a738-c35e-4361-ac59-1d261d49ea96@googlegroups.com> |
| In reply to | #56263 |
On Saturday, March 25, 2017 at 1:02:09 AM UTC-7, hughag...@gmail.com wrote:
> On Saturday, March 25, 2017 at 12:06:21 AM UTC-7, hughag...@gmail.com wrote:
> > On Friday, March 24, 2017 at 11:25:22 PM UTC-7, HAA wrote:
> > > : DUM* ( ud1 ud2 -- uq )
> > > over 4 pick um* 2 pick 6 roll um* rot 0 d+ >r
> > > 3 roll 4 pick um* rot 0 d+ 3 roll 4 roll um*
> > > rot 0 d+ r> 0 d+ ;
> > >
> > > Anyone with a faster version in high-level?
> >
> > That code is terrible in both SwiftForth and VFX. The problem is that ROLL is inefficient. PICK isn't bad though.
>
> Here is a version using locals:
>
> \ H2L2
> \ H1L1
> \ -----------
> \ H1L1
> \ H2L1
> \ H1L2
> \ H2L2
> \ -----------
> \ C4C3C2C1
>
> : dum* ( ud1 ud2 -- uq )
> { L1 H1 L2 H2 | C4 C3 C2 C1 -- uq }
> L1 L2 um* to C2 to C1
> L1 H2 um* to C3 +to C2
> H1 L2 um* +to C3 +to C2
> H1 H2 um* to C4 +to C3
> C1 C2 C3 C4 ;
My comments were messed up --- here is a version with the comments corrected:
\ H2L2
\ H1L1
\ -----------
\ L2L1
\ H2L1
\ L2L2
\ H2L2
\ -----------
\ C4C3C2C1
: dum* ( ud1 ud2 -- uq )
{ L1 H1 L2 H2 | C4 C3 C2 C1 -- uq }
L1 L2 um* to C2 to C1
L1 H2 um* to C3 +to C2
H1 L2 um* +to C3 +to C2
H1 H2 um* to C4 +to C3
C1 C2 C3 C4 ;
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-03-27 12:11 +1000 |
| Message-ID | <ob9out$n5o$1@gioia.aioe.org> |
| In reply to | #56261 |
hughaguilar96@gmail.com wrote: > On Friday, March 24, 2017 at 11:25:22 PM UTC-7, HAA wrote: > > ... > > : DUM* ( ud1 ud2 -- uq ) > > over 4 pick um* 2 pick 6 roll um* rot 0 d+ >r > > 3 roll 4 pick um* rot 0 d+ 3 roll 4 roll um* > > rot 0 d+ r> 0 d+ ; > > > > Anyone with a faster version in high-level? > > That code is terrible in both SwiftForth and VFX. The problem is that ROLL is > inefficient. PICK isn't bad though. > ... ROLL isn't inefficient relative to the multiply operations involved. The figures I quote elsewhere suggest variables have the edge but that's due to the benchmark which favors small numbers including zero. Feed DUM* some numbers typical of a quad multiply and most of the time is spent multiplying, not obtaining the arguments.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-03-27 15:53 +1000 |
| Message-ID | <oba60d$1706$1@gioia.aioe.org> |
| In reply to | #56363 |
HAA wrote: > hughaguilar96@gmail.com wrote: > > On Friday, March 24, 2017 at 11:25:22 PM UTC-7, HAA wrote: > > > ... > > > : DUM* ( ud1 ud2 -- uq ) > > > over 4 pick um* 2 pick 6 roll um* rot 0 d+ >r > > > 3 roll 4 pick um* rot 0 d+ 3 roll 4 roll um* > > > rot 0 d+ r> 0 d+ ; > > > > > > Anyone with a faster version in high-level? > > > > That code is terrible in both SwiftForth and VFX. The problem is that ROLL is > > inefficient. PICK isn't bad though. > > ... > > ROLL isn't inefficient relative to the multiply operations involved. The figures > I quote elsewhere suggest variables have the edge but that's due to the > benchmark which favors small numbers including zero. Feed DUM* some > numbers typical of a quad multiply and most of the time is spent multiplying, > not obtaining the arguments. Correction on that. Changing the data does not affect multiplication time. A transcription error on my part made it appear so :( So yes, using PICK ROLL tested slower than variables depending on the target but IMO unlikely to be noticed in practice.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-03-26 22:12 -0700 |
| Message-ID | <878tnruwuc.fsf@nightsong.com> |
| In reply to | #56363 |
"HAA" <someone@microsoft.com> writes: > Feed DUM* some numbers typical of a quad multiply and most of the time > is spent multiplying, not obtaining the arguments. That would depend on the hardware--I haven't heard of a cpu with a serial multiplier in quite a while.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-03-29 10:30 +1000 |
| Message-ID | <obesf6$1fh9$2@gioia.aioe.org> |
| In reply to | #56261 |
hughaguilar96@gmail.com wrote: > On Friday, March 24, 2017 at 11:25:22 PM UTC-7, HAA wrote: > > ... > > : DUM* ( ud1 ud2 -- uq ) > > over 4 pick um* 2 pick 6 roll um* rot 0 d+ >r > > 3 roll 4 pick um* rot 0 d+ 3 roll 4 roll um* > > rot 0 d+ r> 0 d+ ; > > > > Anyone with a faster version in high-level? > > That code is terrible in both SwiftForth and VFX. The problem is that ROLL is > inefficient. PICK isn't bad though. > > VFX: > ... > see roll > ROLL > ( 00407B5C 53 ) PUSH EBX > ( 00407B5D 8B5C9D00 ) MOV EBX, [EBP+EBX*4] > ( 00407B61 83ED04 ) SUB EBP, 04 > ( 00407B64 895D00 ) MOV [EBP], EBX > ( 00407B67 8BDD ) MOV EBX, EBP > ( 00407B69 8BD3 ) MOV EDX, EBX > ( 00407B6B 83C304 ) ADD EBX, 04 > ( 00407B6E 59 ) POP ECX > ( 00407B6F 41 ) INC ECX > ( 00407B70 C1E102 ) SHL ECX, 02 > ( 00407B73 8D6DF8 ) LEA EBP, [EBP+-08] > ( 00407B76 895D00 ) MOV [EBP], EBX > ( 00407B79 895504 ) MOV [EBP+04], EDX > ( 00407B7C 8BD9 ) MOV EBX, ECX > ( 00407B7E E859CFFFFF ) CALL 00404ADC CMOVE> > ( 00407B83 8B5D00 ) MOV EBX, [EBP] > ( 00407B86 8D6D04 ) LEA EBP, [EBP+04] > ( 00407B89 C3 ) NEXT, > ( 46 bytes, 18 instructions ) > ok Probably came from a high-level definition similar to this: : ROLL (S n1 n2 .. nk n -- wierd ) >R R@ PICK SP@ DUP 2+ R> 1+ 2* CMOVE> DROP ; ROLL deserves to be a primitive as in SwiftForth. code roll mov eax, 0 [ebp] [ebx*4] test ebx, ebx jz l$2 l$1: mov ecx, -4 [ebp] [ebx*4] mov 0 [ebp] [ebx*4] , ecx dec ebx jnz l$1 l$2: add ebp, # 4 mov ebx, eax next, end-code
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-03-25 09:34 +0000 |
| Message-ID | <2017Mar25.103404@mips.complang.tuwien.ac.at> |
| In reply to | #56258 |
"HAA" <someone@microsoft.com> writes:
>: DUM* ( ud1 ud2 -- uq )
> over 4 pick um* 2 pick 6 roll um* rot 0 d+ >r
> 3 roll 4 pick um* rot 0 d+ 3 roll 4 roll um*
> rot 0 d+ r> 0 d+ ;
>
>Anyone with a faster version in high-level?
Do we want quad-cells on the stack? The discussion on the
memory-access words indicated that we don't.
Anyway, here's a version that conforms with your stack comment. You
can measure yourself whether it is faster:
: udx+ ( ud1 ud2 -- ut )
>r 0 d+ \ good enough for dum* because the range of ud1 prevents overflow
0 r> 0 d+ ;
: dum* { l1 h1 l2 h2 -- uq }
l2 l2 um* 0
l1 h2 um* d+
l2 h1 um* udx+
l2 h2 um* d+ ;
Having to implement a limited UDX+ with two D+ instead of using ADC
instruction for a complete UDX+ is not very satisfactory, however.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2017-03-25 03:46 -0700 |
| Message-ID | <cc3f5b2c-5024-437c-a5eb-d95cb2a30a4b@googlegroups.com> |
| In reply to | #56268 |
On Saturday, March 25, 2017 at 11:00:02 AM UTC+1, Anton Ertl wrote:
[..]
> Do we want quad-cells on the stack? The discussion on the
> memory-access words indicated that we don't.
>
> Anyway, here's a version that conforms with your stack comment. You
> can measure yourself whether it is faster:
>
> : udx+ ( ud1 ud2 -- ut )
> >r 0 d+ \ good enough for dum* because the range of ud1 prevents overflow
> 0 r> 0 d+ ;
>
> : dum* { l1 h1 l2 h2 -- uq }
> l2 l2 um* 0
> l1 h2 um* d+
> l2 h1 um* udx+
> l2 h2 um* d+ ;
>
> Having to implement a limited UDX+ with two D+ instead of using ADC
> instruction for a complete UDX+ is not very satisfactory, however.
>
> - anton
In iForth I call this word UDM* .
This is from 2009 (128b * 128b -> 256bit):
NEEDS -quads
: BENCH ( times -- )
TIMER-RESET CR
0 ?DO 1. 2. UDM* 4DROP
-1. -1. UDM* 4DROP
0. 0. UDM* 4DROP
0. -1. UDM* 4DROP
LOOP
.ELAPSED ;
100000000 bench
5.059 seconds elapsed. ok
=> 5 seconds for 400,000,000 multiplications
or ~12.5ns per multiplication.
-marcel
[toc] | [prev] | [next] | [standalone]
Page 1 of 11 [1] 2 3 … 11 Next page →
Back to top | Article view | comp.lang.forth
csiph-web