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 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-03-27 10:56 +1000 |
| Message-ID | <ob9kip$igu$1@gioia.aioe.org> |
| In reply to | #56268 |
Anton Ertl wrote:
> "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.
16-bit environments may still have the need.
>
> 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
Using Marcel's benchmark the difference between stack vs. locals implementation:
16-bit x86 - insignificant
emulated Z80 - locals 1.2 faster
VFX - locals 2.6 faster
VFX - values 3.2 faster
In practice the application would mask both speed and size differences.
My point however was that as much as PICK and ROLL are maligned,
a reasonable use for them can always be found. In this case I would
consider use of variables overkill. I don't need to know how DUM* works,
only that it does and it's competitive.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-03-28 10:07 +1000 |
| Message-ID | <obc62d$10f4$1@gioia.aioe.org> |
| In reply to | #56268 |
Anton Ertl wrote:
> "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
Found a routine in FSL that appears to work. Compared to PICK/ROLL
version, it does better on VFX than SwiftForth.
: umd* ( ud ud -- uq )
( ul uh vl vh)
2 PICK OVER UM* 2>R ( ul uh vl vh R: x3 .)
3 PICK UM* 2>R ( ul uh vl R: x3 . x2 .)
TUCK UM* 2>R ( ul vl R: x3 . x2 . x1)
UM* ( x0 . R: x3 . x2 . x1)
0 2R> D+ ( x0 x1 . R: x3 . x2 .)
2R@ D+
2DUP 2R> DU< IF ( x0 x1 . R: x3 .)
R> 1+ >R
THEN
0 2R> D+ ( x0 x1 x3 .)
;
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2017-03-27 16:46 -0700 |
| Message-ID | <d7a640dd-915b-45dc-9fb6-b88e29e8786a@googlegroups.com> |
| In reply to | #56405 |
On Tuesday, March 28, 2017 at 1:09:08 AM UTC+2, HAA wrote:
> Anton Ertl wrote:
> > "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
>
> Found a routine in FSL that appears to work. Compared to PICK/ROLL
> version, it does better on VFX than SwiftForth.
>
> : umd* ( ud ud -- uq )
> ( ul uh vl vh)
> 2 PICK OVER UM* 2>R ( ul uh vl vh R: x3 .)
> 3 PICK UM* 2>R ( ul uh vl R: x3 . x2 .)
> TUCK UM* 2>R ( ul vl R: x3 . x2 . x1)
> UM* ( x0 . R: x3 . x2 . x1)
> 0 2R> D+ ( x0 x1 . R: x3 . x2 .)
> 2R@ D+
> 2DUP 2R> DU< IF ( x0 x1 . R: x3 .)
> R> 1+ >R
> THEN
> 0 2R> D+ ( x0 x1 x3 .)
> ;
FORTH> NEEDS -quads
Creating --- Quadword Toolkit Version 1.02 ---
ok
FORTH> : BENCH1 ( times -- )
<3>[FORTH>] TIMER-RESET CR
<3>[FORTH>] 0 ?DO 1. 2. UDM* 4DROP
[3]<3>[FORTH>] -1. -1. UDM* 4DROP
[3]<3>[FORTH>] 0. 0. UDM* 4DROP
[3]<3>[FORTH>] 0. -1. UDM* 4DROP
[3]<3>[FORTH>] LOOP
<3>[FORTH>] .ELAPSED ; ok
FORTH> ok
FORTH> 100000000 bench1
4.824 seconds elapsed. ok
FORTH> \ 5.059 seconds elapsed. ok ok
FORTH> ok
FORTH> ok
FORTH> : umd* ( ud ud -- uq )
<3>[FORTH>] ( ul uh vl vh)
<3>[FORTH>] 2 PICK OVER UM* 2>R ( ul uh vl vh R: x3 .)
<3>[FORTH>] 3 PICK UM* 2>R ( ul uh vl R: x3 . x2 .)
<3>[FORTH>] TUCK UM* 2>R ( ul vl R: x3 . x2 . x1)
<3>[FORTH>] UM* ( x0 . R: x3 . x2 . x1)
<3>[FORTH>] 0 2R> D+ ( x0 x1 . R: x3 . x2 .)
<3>[FORTH>] 2R@ D+
<3>[FORTH>] 2DUP 2R> DU< IF ( x0 x1 . R: x3 .)
[3]<3>[FORTH>] R> 1+ >R
[3]<3>[FORTH>] THEN
<3>[FORTH>] 0 2R> D+ ( x0 x1 x3 .)
<3>[FORTH>] ; ok
FORTH> : BENCH2 ( times -- )
<3>[FORTH>] TIMER-RESET CR
<3>[FORTH>] 0 ?DO 1. 2. UMd* 4DROP
[3]<3>[FORTH>] -1. -1. UMD* 4DROP
[3]<3>[FORTH>] 0. 0. UMD* 4DROP
[3]<3>[FORTH>] 0. -1. UMD* 4DROP
[3]<3>[FORTH>] LOOP
<3>[FORTH>] .ELAPSED ; ok
FORTH> ok
FORTH> 100000000 bench2
3.416 seconds elapsed. ok
FORTH> 4824 100 3416 */ . 141 ok
So stack-only / no-ROLL is 1.4 times faster,
quite a bit more than I expected.
-marcel
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-03-27 18:51 -0700 |
| Message-ID | <87zig6tbgm.fsf@nightsong.com> |
| In reply to | #56405 |
"HAA" <someone@microsoft.com> writes: > : umd* ( ud ud -- uq ) All the Forth versions of this word seem painful. This should really be done with CODE.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-03-27 17:21 -1000 |
| Message-ID | <qe6dnTf_M-hKS0TFnZ2dnUU7-dGdnZ2d@supernews.com> |
| In reply to | #56412 |
On 3/27/17 3:51 PM, Paul Rubin wrote: > "HAA" <someone@microsoft.com> writes: >> : umd* ( ud ud -- uq ) > > All the Forth versions of this word seem painful. This should really be > done with CODE. > Or at least factors done in code. All high level is pretty ugly. Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-28 10:57 -0700 |
| Message-ID | <6e5379da-8173-4832-a9a8-12bf62941ad9@googlegroups.com> |
| In reply to | #56413 |
On Monday, March 27, 2017 at 8:22:04 PM UTC-7, Elizabeth D. Rather wrote: > On 3/27/17 3:51 PM, Paul Rubin wrote: > > "HAA" <someone@microsoft.com> writes: > >> : umd* ( ud ud -- uq ) > > > > All the Forth versions of this word seem painful. This should really be > > done with CODE. > > > Or at least factors done in code. All high level is pretty ugly. If the best that you can do is tell people to write their low-level fundamental functions in assembly-language, then you have no qualification to be writing the standard for Forth.
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-03-28 01:16 -0700 |
| Message-ID | <a13616ea-792e-41f2-af84-3a9d7af99bbe@googlegroups.com> |
| In reply to | #56412 |
Am Dienstag, 28. März 2017 03:51:55 UTC+2 schrieb Paul Rubin: > "HAA" <someone@microsoft.com> writes: > > : umd* ( ud ud -- uq ) > > All the Forth versions of this word seem painful. This should really be > done with CODE. Yes, when there are more powerful asm instructions for your particular processor. Similarly I can't remember having seen any asm code for M*/ in the past in other Forths that I know of. It doesn't hurt because in my domain it is never used. Anyhow here is my own version in hilevel: : M*/ \ ( d1 n1 n2 -- d2 ) d1*n1/n2 with intermediate triple number result pluck pluck pluck xor xor >r abs >r abs >r dabs \ |d1| r: sign |n2| |n1| r@ um* rot r> um* swap >r m+ r> -rot r@ um/mod -rot r> um/mod -rot drop r> 0< IF dnegate THEN ; It just mimicks the pen and paper math. How could this be optimized?
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-28 03:36 -0500 |
| Message-ID | <D8KdnXFg6oYJvUfFnZ2dnUU7-TXNnZ2d@supernews.com> |
| In reply to | #56416 |
minforth@arcor.de wrote: > Am Dienstag, 28. M?rz 2017 03:51:55 UTC+2 schrieb Paul Rubin: >> "HAA" <someone@microsoft.com> writes: >> > : umd* ( ud ud -- uq ) >> >> All the Forth versions of this word seem painful. This should really be >> done with CODE. > > Yes, when there are more powerful asm instructions for your particular processor. > > Similarly I can't remember having seen any asm code for M*/ in the > past in other Forths that I know of. It doesn't hurt because in my > domain it is never used. Anyhow here is my own version in hilevel: > > : M*/ \ ( d1 n1 n2 -- d2 ) d1*n1/n2 with intermediate triple number result > pluck pluck pluck xor xor >r abs >r abs >r dabs \ |d1| r: sign |n2| |n1| > r@ um* rot r> um* swap >r m+ r> -rot r@ um/mod -rot r> um/mod -rot drop > r> 0< IF dnegate THEN ; I can't understand that stack manipulation at all. > It just mimicks the pen and paper math. How could this be optimized? It's worth factoring out the multiplication and division as : m*/ ( d n1 n2 -- d2) >r t* r> t/ ; People sometimes make T/ take a positive divisor: this saves a little effort with no significant loss of functionality. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-03-28 01:54 -0700 |
| Message-ID | <b78274da-6bd8-437f-aeac-c7628cc10ef6@googlegroups.com> |
| In reply to | #56417 |
Am Dienstag, 28. März 2017 10:36:42 UTC+2 schrieb Andrew Haley: > minforth@arcor.de wrote: > > Am Dienstag, 28. M?rz 2017 03:51:55 UTC+2 schrieb Paul Rubin: > >> "HAA" <someone@microsoft.com> writes: > >> > : umd* ( ud ud -- uq ) > >> > >> All the Forth versions of this word seem painful. This should really be > >> done with CODE. > > > > Yes, when there are more powerful asm instructions for your particular processor. > > > > Similarly I can't remember having seen any asm code for M*/ in the > > past in other Forths that I know of. It doesn't hurt because in my > > domain it is never used. Anyhow here is my own version in hilevel: > > > > : M*/ \ ( d1 n1 n2 -- d2 ) d1*n1/n2 with intermediate triple number result > > pluck pluck pluck xor xor >r abs >r abs >r dabs \ |d1| r: sign |n2| |n1| > > r@ um* rot r> um* swap >r m+ r> -rot r@ um/mod -rot r> um/mod -rot drop > > r> 0< IF dnegate THEN ; > > I can't understand that stack manipulation at all. > > > It just mimicks the pen and paper math. How could this be optimized? > > It's worth factoring out the multiplication and division as > > : m*/ ( d n1 n2 -- d2) >r t* r> t/ ; > > People sometimes make T/ take a positive divisor: this saves a little > effort with no significant loss of functionality. > > Andrew. But M*/ is a standard word. T* T/ are not. The so-called stack manipulation is just for shifting things out of the way to the return stack for multiplication, addition and division. The algorithm itself is straightforward and simple. Using locals would have been more readable perhaps but won't buy you anything in this case.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-03-28 12:57 -1000 |
| Message-ID | <2dadnRSF3Meid0fFnZ2dnUU7-QmdnZ2d@supernews.com> |
| In reply to | #56419 |
On 3/27/17 10:54 PM, minforth@arcor.de wrote: > Am Dienstag, 28. März 2017 10:36:42 UTC+2 schrieb Andrew Haley: >> minforth@arcor.de wrote: >>> Am Dienstag, 28. M?rz 2017 03:51:55 UTC+2 schrieb Paul Rubin: >>>> "HAA" <someone@microsoft.com> writes: >>>>> : umd* ( ud ud -- uq ) >>>> >>>> All the Forth versions of this word seem painful. This should really be >>>> done with CODE. >>> >>> Yes, when there are more powerful asm instructions for your particular processor. >>> >>> Similarly I can't remember having seen any asm code for M*/ in the >>> past in other Forths that I know of. It doesn't hurt because in my >>> domain it is never used. Anyhow here is my own version in hilevel: >>> >>> : M*/ \ ( d1 n1 n2 -- d2 ) d1*n1/n2 with intermediate triple number result >>> pluck pluck pluck xor xor >r abs >r abs >r dabs \ |d1| r: sign |n2| |n1| >>> r@ um* rot r> um* swap >r m+ r> -rot r@ um/mod -rot r> um/mod -rot drop >>> r> 0< IF dnegate THEN ; >> >> I can't understand that stack manipulation at all. >> >>> It just mimicks the pen and paper math. How could this be optimized? >> >> It's worth factoring out the multiplication and division as >> >> : m*/ ( d n1 n2 -- d2) >r t* r> t/ ; >> >> People sometimes make T/ take a positive divisor: this saves a little >> effort with no significant loss of functionality. >> >> Andrew. > > But M*/ is a standard word. > > T* T/ are not. > > The so-called stack manipulation is just for shifting things out of the way to the return stack for multiplication, addition and division. The algorithm itself is straightforward and simple. Using locals would have been more readable perhaps but won't buy you anything in this case. Lower level factors of standard words don't have to be standard. Systems are free to factor their standard words however they wish; the lower-level words may or may not be visible to user applications (they usually are, but that's not required). An application that uses non-standard lower-level factors such as T* have a dependency on those words, but are not otherwise non-standard. Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-28 03:51 -0500 |
| Message-ID | <D8KdnXBg6oaLuUfFnZ2dnUU7-TWdnZ2d@supernews.com> |
| In reply to | #56412 |
Paul Rubin <no.email@nospam.invalid> wrote: > "HAA" <someone@microsoft.com> writes: >> : umd* ( ud ud -- uq ) > > All the Forth versions of this word seem painful. This should really be > done with CODE. Yes, probably. Novix had +c, which is add with carry. You had to be careful with intermediate operations, of course. ARM has add with optional carry-in and carry-out: you can have none, either, or both. This is very convenient. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-03-29 10:29 +1000 |
| Message-ID | <obesf3$1fh9$1@gioia.aioe.org> |
| In reply to | #56412 |
Paul Rubin wrote: > "HAA" <someone@microsoft.com> writes: > > : umd* ( ud ud -- uq ) > > All the Forth versions of this word seem painful. This should really be > done with CODE. Did that and found it more trouble than it was worth. For a 16-bit x86 DTC: 5712 mS \ pick/roll 1153 mS \ asm 5602 mS \ FSL Quad isn't something that's used everyday and it's the precision it offers that's of primary interest. Speed is just icing on the cake.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-21 03:33 -0500 |
| Message-ID | <hYudnTHDPbn-eE3FnZ2dnUU7-fPNnZ2d@supernews.com> |
| In reply to | #55970 |
Helmar Wodtke <helmwo@gmail.com> wrote: > Am Montag, 20. M?rz 2017 18:34:42 UTC+1 schrieb Paul Rubin: > >> > 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... There seems to be an odd misunderstanding about the meaning of "core". Some people think that because a word is in CORE it has to be in the set of words which is always loaded into the system, and it must be present in the predefined dictionary when Forth starts. But this is not true: there is no reason why some words can't be loaded from source as required. It is true that the system won't be standard until they are loaded, but this doesn't matter to anyone. Therefore, people complaining that the CORE wordset is "too large for small systems" are not making any sense. If you don't need all of CORE and are short of space, don't load all of CORE. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Helmar Wodtke <helmwo@gmail.com> |
|---|---|
| Date | 2017-03-21 05:17 -0700 |
| Message-ID | <49462cff-1626-4261-9efe-aa74141c9950@googlegroups.com> |
| In reply to | #55995 |
Am Dienstag, 21. März 2017 09:33:45 UTC+1 schrieb Andrew Haley: > Helmar Wodtke <helmwo@gmail.com> wrote: > > Am Montag, 20. M?rz 2017 18:34:42 UTC+1 schrieb Paul Rubin: > > > >> > 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... > > There seems to be an odd misunderstanding about the meaning of "core". > Some people think that because a word is in CORE it has to be in the > set of words which is always loaded into the system, and it must be > present in the predefined dictionary when Forth starts. But this is > not true: there is no reason why some words can't be loaded from > source as required. It is true that the system won't be standard > until they are loaded, but this doesn't matter to anyone. Therefore, > people complaining that the CORE wordset is "too large for small > systems" are not making any sense. If you don't need all of CORE and > are short of space, don't load all of CORE. > > Andrew. Some kind of "odd" is that 2OVER could be defined by: : 2OVER 3 PICK 3 PICK ; But, now, well, "PICK" is CORE-EXT ;) I think it has historical reasons, as before DPANS that "PICK" was a bit of ambiguous, as some systems implemented it one- or zero-based. But it would in general be more useful to put the more "universal" words into core than some - well, "optimizations". If there would be "PICK" inside CORE, you could put "2OVER" into CORE-EXT. Regards, -Helmar
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-21 09:42 -0500 |
| Message-ID | <QZ-dnbHA7NQkpkzFnZ2dnUU7-KnNnZ2d@supernews.com> |
| In reply to | #56000 |
Helmar Wodtke <helmwo@gmail.com> wrote: > Am Dienstag, 21. M?rz 2017 09:33:45 UTC+1 schrieb Andrew Haley: >> >> There seems to be an odd misunderstanding about the meaning of "core". >> Some people think that because a word is in CORE it has to be in the >> set of words which is always loaded into the system, and it must be >> present in the predefined dictionary when Forth starts. But this is >> not true: there is no reason why some words can't be loaded from >> source as required. It is true that the system won't be standard >> until they are loaded, but this doesn't matter to anyone. Therefore, >> people complaining that the CORE wordset is "too large for small >> systems" are not making any sense. If you don't need all of CORE and >> are short of space, don't load all of CORE. > > Some kind of "odd" is that 2OVER could be defined by: > > : 2OVER 3 PICK 3 PICK ; > > But, now, well, "PICK" is CORE-EXT ;) I think it has historical > reasons, as before DPANS that "PICK" was a bit of ambiguous, as some > systems implemented it one- or zero-based. But it would in general > be more useful to put the more "universal" words into core than some > - well, "optimizations". If there would be "PICK" inside CORE, you > could put "2OVER" into CORE-EXT. That might make sense when designing a very small Forth system, but I can think of no reason to structure a standard in that way. But even from te viewpoint of designing a system, there may well be better ways to write 2OVER than using PICK. And if I was to design an extremely small Forth today it certainly wouldn't have PICK in its nucleus! But, of course, we are talking about matters of taste. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Helmar Wodtke <helmwo@gmail.com> |
|---|---|
| Date | 2017-03-21 09:49 -0700 |
| Message-ID | <a399552f-7a9c-4bdf-81ae-540f0912f2f2@googlegroups.com> |
| In reply to | #56007 |
Am Dienstag, 21. März 2017 15:42:07 UTC+1 schrieb Andrew Haley: > Helmar Wodtke <helmwo@gmail.com> wrote: > > Am Dienstag, 21. M?rz 2017 09:33:45 UTC+1 schrieb Andrew Haley: > >> > >> There seems to be an odd misunderstanding about the meaning of "core". > >> Some people think that because a word is in CORE it has to be in the > >> set of words which is always loaded into the system, and it must be > >> present in the predefined dictionary when Forth starts. But this is > >> not true: there is no reason why some words can't be loaded from > >> source as required. It is true that the system won't be standard > >> until they are loaded, but this doesn't matter to anyone. Therefore, > >> people complaining that the CORE wordset is "too large for small > >> systems" are not making any sense. If you don't need all of CORE and > >> are short of space, don't load all of CORE. > > > > Some kind of "odd" is that 2OVER could be defined by: > > > > : 2OVER 3 PICK 3 PICK ; > > > > But, now, well, "PICK" is CORE-EXT ;) I think it has historical > > reasons, as before DPANS that "PICK" was a bit of ambiguous, as some > > systems implemented it one- or zero-based. But it would in general > > be more useful to put the more "universal" words into core than some > > - well, "optimizations". If there would be "PICK" inside CORE, you > > could put "2OVER" into CORE-EXT. > > That might make sense when designing a very small Forth system, but I > can think of no reason to structure a standard in that way. > > But even from te viewpoint of designing a system, there may well be > better ways to write 2OVER than using PICK. And if I was to design an > extremely small Forth today it certainly wouldn't have PICK in its > nucleus! But, of course, we are talking about matters of taste. > > Andrew. OK, what else than a kind of "PICK" you would use for accessing the stack? Just think about separating compilation/data from things like a stack... OK, in a very simple system you do not have own stack memory, but a pointer to the top of the stack. I think in terms of stack beeing a kind of "black box" behind the scenes. I do so for application of Forth to some other systems... Just imagine, that the compiler has only 16 bit wide "cells", but the data on stack might be arbitrary numbers. Why not? Even DPANS makes differences between compiling time and execution... Regards, -Helmar
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-21 12:12 -0500 |
| Message-ID | <_KCdnZW2_qxgw0zFnZ2dnUU7-a-dnZ2d@supernews.com> |
| In reply to | #56015 |
Helmar Wodtke <helmwo@gmail.com> wrote: > Am Dienstag, 21. M?rz 2017 15:42:07 UTC+1 schrieb Andrew Haley: >> Helmar Wodtke <helmwo@gmail.com> wrote: >> > Am Dienstag, 21. M?rz 2017 09:33:45 UTC+1 schrieb Andrew Haley: >> >> But even from te viewpoint of designing a system, there may well be >> better ways to write 2OVER than using PICK. And if I was to design an >> extremely small Forth today it certainly wouldn't have PICK in its >> nucleus! But, of course, we are talking about matters of taste. > > OK, what else than a kind of "PICK" you would use for accessing the > stack? Me? No kind of PICK. PICK is something of a Hail Mary, only to be used in times of desperation. > Just think about separating compilation/data from things like > a stack... OK, in a very simple system you do not have own stack > memory, but a pointer to the top of the stack. That's right: it's what makes it a stack, as opposed to an array. > I think in terms of stack beeing a kind of "black box" behind the > scenes. I do so for application of Forth to some other systems... I do not know what you are talking about. > Just imagine, that the compiler has only 16 bit wide "cells", but > the data on stack might be arbitrary numbers. Why not? Because writing programs on such a system would be hard. > Even DPANS makes differences between compiling time and execution... Well, yes, obviously, but what is your point? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Helmar Wodtke <helmwo@gmail.com> |
|---|---|
| Date | 2017-03-21 10:28 -0700 |
| Message-ID | <2ddc9313-5040-4404-b4c3-671452f66fbe@googlegroups.com> |
| In reply to | #56017 |
> > I think in terms of stack beeing a kind of "black box" behind the > > scenes. I do so for application of Forth to some other systems... > > I do not know what you are talking about. The stack could be implemented better for example, if you use it as an array inside the target system. An array not bound to usual memory accessible by Forth itself. (I know, this is probably complicated...) Regards, -Helmar
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-03-21 16:43 -0400 |
| Message-ID | <20170321164342.048da9ec@_> |
| In reply to | #56007 |
On Tue, 21 Mar 2017 09:42:01 -0500 Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Helmar Wodtke <helmwo@gmail.com> wrote: > > Some kind of "odd" is that 2OVER could be defined by: > > > > : 2OVER 3 PICK 3 PICK ; > > > > That might make sense when designing a very small Forth system, but I > can think of no reason to structure a standard in that way. > DUP DROP SWAP >R R> and their two word equivalents are faster or more efficient than PICK and ROLL for coding stack words, but if you're attempting to minimize the set of "primitive" words for a smaller Forth, then PICK and ROLL are effective: : DUP 0 PICK ; : SWAP 1 ROLL ; : OVER 1 PICK ; : ROT 2 ROLL ; : -ROT 2 ROLL 2 ROLL ; : NIP 1 ROLL DROP ; : TUCK 1 ROLL 1 PICK ; : DIP DROP 0 PICK ; : DRIP 1 ROLL DROP 0 PICK ; : TAKE DROP 1 ROLL ; : NUP 1 PICK 1 ROLL ; : 2DUP 1 PICK 1 PICK ; : 2SWAP 3 ROLL 3 ROLL ; : 2OVER 3 PICK 3 PICK ; : 2ROT 5 ROLL 5 ROLL ; : -2ROT 5 ROLL 5 ROLL 5 ROLL 5 ROLL ; : 2NIP 2 ROLL DROP 2 ROLL DROP ; : 2NIP 3 ROLL 3 ROLL DROP DROP ; : 2TUCK 3 ROLL 3 ROLL 3 PICK 3 PICK ; (incomplete) Rod Pemberton -- All it takes for humanity to conquer the world's toughest problems is to hope, to believe, to share, and to do, in cooperation.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-03-21 14:11 -1000 |
| Message-ID | <h--dnfBUpuypXEzFnZ2dnUU7-dXNnZ2d@supernews.com> |
| In reply to | #56056 |
On 3/21/17 10:43 AM, Rod Pemberton wrote: > On Tue, 21 Mar 2017 09:42:01 -0500 > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > >> Helmar Wodtke <helmwo@gmail.com> wrote: > >>> Some kind of "odd" is that 2OVER could be defined by: >>> >>> : 2OVER 3 PICK 3 PICK ; >>> >> >> That might make sense when designing a very small Forth system, but I >> can think of no reason to structure a standard in that way. >> > > DUP DROP SWAP >R R> and their two word equivalents are faster or more > efficient than PICK and ROLL for coding stack words, but if you're > attempting to minimize the set of "primitive" words for a smaller Forth, > then PICK and ROLL are effective: > > : DUP 0 PICK ; > : SWAP 1 ROLL ; > : OVER 1 PICK ; > : ROT 2 ROLL ; > : -ROT 2 ROLL 2 ROLL ; > > : NIP 1 ROLL DROP ; > : TUCK 1 ROLL 1 PICK ; > : DIP DROP 0 PICK ; > : DRIP 1 ROLL DROP 0 PICK ; > : TAKE DROP 1 ROLL ; > : NUP 1 PICK 1 ROLL ; > > : 2DUP 1 PICK 1 PICK ; > : 2SWAP 3 ROLL 3 ROLL ; > : 2OVER 3 PICK 3 PICK ; > : 2ROT 5 ROLL 5 ROLL ; > : -2ROT 5 ROLL 5 ROLL 5 ROLL 5 ROLL ; > > : 2NIP 2 ROLL DROP 2 ROLL DROP ; > : 2NIP 3 ROLL 3 ROLL DROP DROP ; > : 2TUCK 3 ROLL 3 ROLL 3 PICK 3 PICK ; > (incomplete) If you want a "smaller Forth" you can dispense with a lot of these words altogether: DIP, DRIP, TAKE, NUP, 2ROT, -2ROT, 2NIP, and 2TUCK, for a start (they don't even exist in most Forths I know). Many of the others (DUP, etc.) are just as easy to define in code as in Forth, and their memory footprint as well as execution time will be smaller. Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
Back to top | Article view | comp.lang.forth
csiph-web