Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #54064 > unrolled thread
| Started by | "HAA" <someone@microsoft.com> |
|---|---|
| First post | 2017-01-17 12:17 +1100 |
| Last post | 2017-03-26 01:52 -0700 |
| Articles | 20 on this page of 269 — 27 participants |
Back to article view | Back to comp.lang.forth
EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-17 12:17 +1100
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-16 18:27 -0800
Re: EXIT THEN Pablo Hugo Reda <pabloreda@gmail.com> - 2017-01-16 18:28 -0800
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-16 20:56 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-19 13:05 +1100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-18 23:29 -0500
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-20 11:46 +1100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-19 22:28 -0500
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-22 18:45 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-25 09:57 +1100
Re: EXIT THEN JennyB <jennybrien@googlemail.com> - 2017-01-25 23:56 -0800
Re: EXIT THEN Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-26 03:35 -0600
Re: EXIT THEN Coos Haak <htrofhc@gmail.com> - 2017-01-26 11:31 +0100
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-26 11:07 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-02-05 19:15 +1100
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-07 17:54 +0000
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-02-07 21:14 +0000
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-13 16:52 +0000
Recognizer using CATCH/THROW [was Re: EXIT THEN] Alex <alex@rivadpm.com> - 2017-02-15 23:49 +0000
Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] Alex <alex@rivadpm.com> - 2017-02-16 14:41 +0000
Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] Alex <alex@rivadpm.com> - 2017-02-16 16:59 +0000
Recognizer using CATCH/THROW [was Re: EXIT THEN] Alex <alex@rivadpm.com> - 2017-03-11 15:05 +0000
Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] Matthias Trute <matthias.trute@gmail.com> - 2017-03-13 12:37 -0700
Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] Alex <alex@rivadpm.com> - 2017-03-13 21:32 +0000
Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-14 04:42 -0500
Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] Alex <alex@rivadpm.com> - 2017-03-14 11:45 +0000
Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] Alex <alex@rivadpm.com> - 2017-03-14 12:41 +0000
Re: Recognizer using CATCH/THROW [was Re: EXIT THEN] albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-14 14:20 +0100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-02-07 16:15 -0500
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-13 16:49 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-02-08 19:43 +1100
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-13 16:31 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-02-14 11:12 +1100
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-15 17:22 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-02-17 10:16 +1100
Re: EXIT THEN JennyB <jennybrien@googlemail.com> - 2017-01-26 09:11 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-28 11:07 +1100
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-27 18:31 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-29 12:07 +1100
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-28 17:37 -0800
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-28 21:40 -0500
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-29 19:56 -0800
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-30 00:30 -0500
Re: EXIT THEN Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-31 04:22 -0600
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-31 14:42 -0800
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-31 19:16 -0500
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-31 21:00 -0800
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-02-01 17:35 -0500
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-02-02 01:31 -0500
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-02-02 20:09 -0500
Re: EXIT THEN hughaguilar96@gmail.com - 2017-02-02 18:03 -0800
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-02-02 22:04 -0500
Re: EXIT THEN Mark Wills <markwills1970@gmail.com> - 2017-02-01 03:15 -0800
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-02-01 17:32 -0500
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-01-30 13:30 +0000
Re: EXIT THEN Mark Wills <markwills1970@gmail.com> - 2017-01-30 05:56 -0800
Re: EXIT THEN Howerd <howerdo@yahoo.co.uk> - 2017-01-30 12:13 -0800
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-01-30 22:25 +0000
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-26 10:48 +0000
Re: EXIT THEN JennyB <jennybrien@googlemail.com> - 2017-01-26 08:41 -0800
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-27 21:36 -0800
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-17 17:06 +0000
Re: EXIT THEN "Elizabeth D. Rather" <erather@forth.com> - 2017-01-16 16:31 -1000
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-16 20:59 -0800
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-17 06:11 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-18 10:36 +1100
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-20 07:33 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-20 23:02 +1100
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-20 13:47 +0000
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-20 18:55 -0800
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-22 09:15 +0000
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-22 14:30 -0800
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-22 20:58 -0500
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-23 10:47 +0000
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-23 06:20 -0500
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-23 13:09 +0000
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-23 14:41 -0500
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-23 20:52 +0000
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-23 16:21 -0500
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-24 06:55 +0000
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-24 03:56 -0500
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-24 09:46 +0000
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-01-22 22:38 -0500
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-23 15:09 +1100
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-23 10:16 +0000
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-23 05:53 -0500
Re: EXIT THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-23 12:14 +0000
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-23 14:53 -0500
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-24 21:37 +1100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-24 19:54 -0500
Re: EXIT THEN Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-25 03:38 -0600
Re: EXIT THEN Mark Wills <markwills1970@gmail.com> - 2017-01-17 08:01 -0800
Re: EXIT THEN hughaguilar96@gmail.com - 2017-01-17 10:27 -0800
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-01-17 11:34 -0800
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-18 14:35 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-18 10:37 +1100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-17 20:53 -0500
Re: EXIT THEN "Elizabeth D. Rather" <erather@forth.com> - 2017-01-17 18:02 -1000
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-18 00:15 -0500
Re: EXIT THEN "Elizabeth D. Rather" <erather@forth.com> - 2017-01-17 19:34 -1000
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-18 03:33 -0500
Re: EXIT THEN Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-18 03:45 -0600
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-18 14:43 -0500
Re: EXIT THEN albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-18 13:17 +0100
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-19 13:46 +1100
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-18 13:56 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-19 13:04 +1100
Re: EXIT THEN "Elizabeth D. Rather" <erather@forth.com> - 2017-01-18 18:10 -1000
Re: EXIT THEN Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-19 03:51 -0600
Re: EXIT THEN hheinrich.hohl@gmail.com - 2017-01-19 02:28 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-20 22:23 +1100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-20 13:32 -0500
Re: EXIT THEN "Elizabeth D. Rather" <erather@forth.com> - 2017-01-20 18:18 -1000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-23 12:00 +1100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-22 21:10 -0500
Re: EXIT THEN Mark Wills <markwills1970@gmail.com> - 2017-01-23 01:22 -0800
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-23 06:03 -0500
Re: EXIT THEN Coos Haak <htrofhc@gmail.com> - 2017-01-24 02:27 +0100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-24 04:00 -0500
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-01-24 07:49 -0500
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-24 20:04 -0500
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-01-24 20:23 -0500
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-24 21:32 -0500
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-24 23:04 -0500
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-01-25 00:45 -0500
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-25 07:16 +0000
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-25 02:57 -0500
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-25 16:55 +0000
Re: EXIT THEN "Elizabeth D. Rather" <erather@forth.com> - 2017-01-25 09:53 -1000
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-26 22:40 -0500
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-26 10:55 +1100
Re: EXIT THEN JennyB <jennybrien@googlemail.com> - 2017-01-26 10:17 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-27 13:09 +1100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-26 21:54 -0500
Re: EXIT THEN Coos Haak <htrofhc@gmail.com> - 2017-01-27 14:12 +0100
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-28 12:32 +1100
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-29 10:35 +1100
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-01-22 21:35 -0500
Re: EXIT THEN Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-23 04:15 -0600
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-01-23 10:29 -0500
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-23 21:48 +1100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-23 06:18 -0500
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-26 11:34 +1100
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-01-25 22:04 -0500
Re: EXIT THEN "Elizabeth D. Rather" <erather@forth.com> - 2017-01-25 17:22 -1000
Re: EXIT THEN Mark Wills <markwills1970@gmail.com> - 2017-01-26 00:55 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-27 13:40 +1100
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-01-20 11:44 +1100
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-18 08:02 -0500
Re: EXIT THEN Coos Haak <htrofhc@gmail.com> - 2017-01-18 17:45 +0100
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-19 20:02 -0500
Re: EXIT THEN Julian Fondren <julian.fondren@gmail.com> - 2017-01-22 18:23 -0800
Re: EXIT THEN albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-02 12:24 +0100
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-02-10 12:15 +1100
Re: EXIT THEN mhx@iae.nl - 2017-02-10 10:57 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-02-11 12:45 +1100
Re: EXIT THEN hughaguilar96@gmail.com - 2017-02-10 18:13 -0800
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-02-11 07:55 -0500
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-02-11 13:16 +0000
Re: EXIT THEN "Elizabeth D. Rather" <erather@forth.com> - 2017-02-11 11:28 -1000
Re: EXIT THEN Paul Rubin <no.email@nospam.invalid> - 2017-02-11 13:40 -0800
Re: EXIT THEN hughaguilar96@gmail.com - 2017-02-11 18:52 -0800
Re: EXIT THEN Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-02-12 12:09 +0000
Re: EXIT THEN hughaguilar96@gmail.com - 2017-02-12 07:24 -0800
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-02-12 16:42 -0500
Re: EXIT THEN Julian Fondren <julian.fondren@gmail.com> - 2017-02-12 13:52 -0800
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-02-13 00:02 -0500
Re: EXIT THEN Julian Fondren <julian.fondren@gmail.com> - 2017-02-12 21:27 -0800
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-13 07:53 +0000
Re: EXIT THEN Michael Barry <barrym95838@yahoo.com> - 2017-02-12 16:25 -0800
Re: EXIT THEN hughaguilar96@gmail.com - 2017-02-12 17:11 -0800
Re: EXIT THEN Michael Barry <barrym95838@yahoo.com> - 2017-02-12 18:49 -0800
Re: EXIT THEN Michael Barry <barrym95838@yahoo.com> - 2017-02-12 18:59 -0800
Re: EXIT THEN hughaguilar96@gmail.com - 2017-02-12 21:18 -0800
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-12 14:39 +0000
Re: EXIT THEN hughaguilar96@gmail.com - 2017-02-11 18:47 -0800
Re: EXIT THEN rickman <gnuarm@gmail.com> - 2017-02-12 00:49 -0500
Re: EXIT THEN Paul Rubin <no.email@nospam.invalid> - 2017-02-11 23:07 -0800
Re: EXIT THEN Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-02-12 12:36 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-02-13 11:08 +1100
Re: EXIT THEN hughaguilar96@gmail.com - 2017-02-12 17:04 -0800
Re: EXIT THEN hughaguilar96@gmail.com - 2017-02-12 17:08 -0800
Re: EXIT THEN jacko <jackokring@gmail.com> - 2017-02-16 17:24 -0800
Re: EXIT THEN jacko <jackokring@gmail.com> - 2017-02-17 16:32 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-02-19 10:47 +1100
Re: EXIT THEN jacko <jackokring@gmail.com> - 2017-02-18 16:07 -0800
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-02-19 13:54 +1100
Re: EXIT THEN Heinrich Hohl <hheinrich.hohl@gmail.com> - 2017-02-17 02:40 -0800
Re: EXIT THEN Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-02-17 19:25 -0500
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-02-19 12:36 +1100
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-20 06:32 -0700
Re: EXIT THEN Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-03-21 08:33 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-03-22 02:21 +1100
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 09:57 -0700
Re: EXIT THEN Coos Haak <htrofhc@gmail.com> - 2017-03-21 18:17 +0100
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 10:22 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-21 17:56 +0000
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 11:59 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-21 19:16 +0000
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 12:24 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-21 19:26 +0000
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 12:32 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-21 19:51 +0000
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 12:56 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-21 21:02 +0000
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 14:15 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-21 21:36 +0000
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 15:12 -0700
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 16:13 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-22 09:16 +0000
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 03:35 -0700
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 13:33 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-21 17:51 +0000
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-21 18:59 +0000
Re: EXIT THEN Mark Wills <markwills1970@gmail.com> - 2017-03-21 12:07 -0700
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-21 12:17 -0700
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-03-22 20:08 +1100
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-22 09:18 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-03-22 22:25 +1100
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 04:46 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-22 12:23 +0000
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 05:27 -0700
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 05:36 -0700
Re: EXIT THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-22 13:14 +0000
Re: EXIT THEN Coos Haak <htrofhc@gmail.com> - 2017-03-22 13:43 +0100
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-22 13:04 +0000
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-22 11:49 +0000
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 05:24 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-22 13:00 +0000
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 06:12 -0700
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-22 07:00 -0700
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 07:14 -0700
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-22 10:43 -0700
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 11:09 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-22 18:22 +0000
Re: EXIT THEN Julian Fondren <julian.fondren@gmail.com> - 2017-03-22 11:42 -0700
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-22 15:45 -0700
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-22 15:57 -0700
Re: EXIT THEN Julian Fondren <julian.fondren@gmail.com> - 2017-03-22 16:17 -0700
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 12:03 -0700
Re: EXIT THEN Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-22 14:27 -0500
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-22 14:31 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-23 14:41 +0000
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-22 14:57 +0000
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-26 01:11 -0700
Re: EXIT THEN Ron Aaron <rambamist@gmail.com> - 2017-03-26 11:40 +0300
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-26 01:57 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-26 09:50 +0100
Re: EXIT THEN foxaudioresearch@gmail.com - 2017-03-22 09:14 -0700
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-03-23 00:48 +1100
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-22 13:59 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-03-23 09:52 +1100
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-22 16:13 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-23 14:39 +0000
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-23 16:33 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-24 14:17 +0000
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-03-24 11:49 +1100
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-23 18:12 -0700
Re: EXIT THEN Alex <alex@rivadpm.com> - 2017-03-24 08:55 +0000
Re: EXIT THEN Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-24 09:14 -0500
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-03-25 13:00 +1100
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-24 20:25 -0700
Re: EXIT THEN Mark Wills <markwills1970@gmail.com> - 2017-03-25 02:10 -0700
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-25 12:08 -0700
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-22 06:59 -0700
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-03-23 09:53 +1100
Re: EXIT THEN Helmar Wodtke <helmwo@gmail.com> - 2017-03-25 07:52 -0700
Re: EXIT THEN "HAA" <someone@microsoft.com> - 2017-03-26 16:31 +1000
Re: EXIT THEN hughaguilar96@gmail.com - 2017-03-26 01:52 -0700
Page 9 of 14 — ← Prev page 1 … 7 8 [9] 10 11 … 14 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-02-11 13:40 -0800 |
| Message-ID | <877f4wv22e.fsf@nightsong.com> |
| In reply to | #54795 |
"Elizabeth D. Rather" <erather@forth.com> writes: > One could argue that if NIP and TUCK were primitives, and hence didn't > have the overhead of an extra layer, they would be more widely > used. But the fact is, most programmers I know just don't think of > them. I use them when the occasion arises. It's just not that often.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-02-11 18:52 -0800 |
| Message-ID | <88caa00e-b9e6-4620-95a2-fd232a8f49a9@googlegroups.com> |
| In reply to | #54796 |
On Saturday, February 11, 2017 at 2:40:27 PM UTC-7, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
> > One could argue that if NIP and TUCK were primitives, and hence didn't
> > have the overhead of an extra layer, they would be more widely
> > used. But the fact is, most programmers I know just don't think of
> > them.
>
> I use them when the occasion arises. It's just not that often.
I use NIP and TUCK quite a lot --- that is because I write a lot of Forth code --- I use everything a lot.
I also use ROVER quite a lot.
For example, here is the original version of SLOW-SWITCH> that used ROT internally:
: jt-direction ( target mid-element -- -1|0|1 ) \ for use by BSEARCH
@ \ -- target mid-value
2dup = if 2drop 0 end \ note for HAA: I used your END rather than EXIT THEN
< if -1 else 1 then ;
: slow-switch> { head default | adr size -- } \ stream: name
align here to adr
head length to size
head each[ dup .targ @ , .xt @ , ]each
: ( selector -- )
adr lit, size lit, rot, d lit, ['] jt-direction lit, postpone bsearch
0=, if, drop, default lit, execute, end,
w lit, +, @, execute, ;,
head kill-jt ;
And here is the new version that keeps the selector on the stack so the executed code has to explicitly DROP it:
: slow-switch> { head default | adr size -- } \ stream: name
align here to adr
head length to size
head each[ dup .targ @ , .xt @ , ]each
: ( selector -- )
adr lit, size lit, rover, d lit, ['] jt-direction lit, postpone bsearch
0=, if, drop, default lit, execute, end,
w lit, +, @, execute, ;,
head kill-jt ;
It was just a matter of changing ROT into ROVER so the value is kept rather than discarded.
[toc] | [prev] | [next] | [standalone]
| From | Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> |
|---|---|
| Date | 2017-02-12 12:09 +0000 |
| Message-ID | <20170212120909.5e42585f@t530.lan> |
| In reply to | #54799 |
On Sat, 11 Feb 2017 18:52:25 -0800 (PST) hughaguilar96@gmail.com wrote: > It was just a matter of changing ROT into ROVER so the value > is kept rather than discarded. What is the stack effect of ROVER? I could guess, but am busy. I've not seen the name ROVER before. Are there any other names it might be recognised better? Jan Coombs
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-02-12 07:24 -0800 |
| Message-ID | <a1bf9577-6734-4bed-ad3b-1f5be6856dd3@googlegroups.com> |
| In reply to | #54807 |
On Sunday, February 12, 2017 at 5:09:10 AM UTC-7, Jan Coombs wrote:
> On Sat, 11 Feb 2017 18:52:25 -0800 (PST)
> hughaguilar96@gmail.com wrote:
>
> > It was just a matter of changing ROT into ROVER so the value
> > is kept rather than discarded.
>
> What is the stack effect of ROVER? I could guess, but am busy.
>
> I've not seen the name ROVER before. Are there any other names
> it might be recognised better?
>
> Jan Coombs
ROVER is in the novice package:
: rover ( a b c -- a b c a )
state @ if 2 postpone literal postpone pick
else 2 pick then ;
immediate
I also have some more which are rarely used:
: third ( a b c -- a b c a ) \ same as ROVER
2 pick ;
: fourth ( a b c d -- a b c d a )
3 pick ;
: fifth ( a b c d e -- a b c d e a )
4 pick ;
: sixth ( a b c d e f -- a b c d e f a )
5 pick ;
: roll-third ( a b c -- b c a ) \ same as ROT
rot ;
: roll-fourth ( a b c d -- b c d a )
3 roll ;
: roll-fifth ( a b c d e -- b c d e a )
4 roll ;
: roll-sixth ( a b c d e f -- b c d e f a )
5 roll ;
These used to be defined with MACRO: but now that MACRO: does early-binding MACRO: words can no longer be used in interpretive mode, which is why I redefined them as colon words. In VFX short colon words get inlined anyway, so they don't have to be late-binding macros to get inlined --- the use of late-binding macros to provide inlining was a concession to SwiftForth that lacks this feature --- but I am not interested in supporting SwiftForth anymore so I'm removing a lot of the concessions that I made to SwiftForth previously.
I'll have the next novice-package release out soon --- hopefully today.
The code is not going to run as fast under SwiftForth as it did previously, because I have removed a lot of the SwiftForth-specific code. I was going to remove all of my SwiftForth assembly-language, but I haven't gotten around to doing so yet. For example:
SwiftForth? [if]
icode length ( head -- count )
zero(eax)
begin non-zero? while [@] eax inc repeat
eax ebx mov ret end-code
[else]
: length ( head -- count )
0 0 do
dup 0= if I nip unloop exit then
.fore @ loop ;
[then]
This is my hand-written assembly-language that supports SwiftForth:
see length
4900BF EAX EAX XOR 31C0
4900C1 EBX EBX OR 09DB
4900C3 4900CA JZ 7405
4900C5 0 [EBX] EBX MOV 8B1B
4900C7 EAX INC 40
4900C8 4900C1 JMP EBF7
4900CA EAX EBX MOV 8BD8
4900CC RET C3 ok
This is what SwiftForth compiles the ANS-Forth code into:
see length
48FE3F -80000000 # PUSH 6800000080
48FE44 -80000000 # PUSH 6800000080
48FE49 EBX EBX OR 09DB
48FE4B 48FE65 JNZ 0F8514000000
48FE51 4 # EBP SUB 83ED04
48FE54 EBX 0 [EBP] MOV 895D00
48FE57 0 [ESP] EBX MOV 8B1C24
48FE5A 4 [ESP] EBX ADD 035C2404
48FE5E 4 # EBP ADD 83C504
48FE61 8 # ESP ADD 83C408
48FE64 RET C3
48FE65 0 [EBX] EBX MOV 8B1B
48FE67 0 [ESP] INC FF0424
48FE6A 48FE49 JNO 0F81D9FFFFFF
48FE70 8 # ESP ADD 83C408
48FE73 RET C3 ok
I may get rid of the hand-written assembly-language so SwiftForth can go back to generating inefficient code again.
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-02-12 16:42 -0500 |
| Message-ID | <20170212164250.22867950@_> |
| In reply to | #54810 |
On Sun, 12 Feb 2017 07:24:04 -0800 (PST) hughaguilar96@gmail.com wrote: > ROVER is in the novice package: > > : rover ( a b c -- a b c a ) > state @ if 2 postpone literal postpone pick > else 2 pick then ; > immediate > Apparently, you have objections to the following? : ROVER >R OVER R> SWAP ; 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 | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-02-12 13:52 -0800 |
| Message-ID | <6177f3b6-c5f1-4909-871a-2f4c533413d6@googlegroups.com> |
| In reply to | #54814 |
On Sunday, February 12, 2017 at 3:42:04 PM UTC-6, Rod Pemberton wrote: > > Apparently, you have objections to the following? > > : ROVER >R OVER R> SWAP ; > VFX Forth doesn't do as well with return-stack ops. : third >r over r> swap ; ok see third THIRD ( 080C0A30 53 ) PUSH EBX ( 080C0A31 5B ) POP EBX ( 080C0A32 8D6DFC ) LEA EBP, [EBP+-04] ( 080C0A35 895D00 ) MOV [EBP], EBX ( 080C0A38 8B5D08 ) MOV EBX, [EBP+08] ( 080C0A3B C3 ) NEXT, ( 12 bytes, 6 instructions ) ok : third 2 pick ; THIRD is redefined ok see third THIRD ( 080C0A60 8D6DFC ) LEA EBP, [EBP+-04] ( 080C0A63 895D00 ) MOV [EBP], EBX ( 080C0A66 8B5D08 ) MOV EBX, [EBP+08] ( 080C0A69 C3 ) NEXT, ( 10 bytes, 4 instructions ) ok : third dup 2over drop nip ; THIRD is redefined ok see third THIRD ( 080C0A90 8D6DFC ) LEA EBP, [EBP+-04] ( 080C0A93 895D00 ) MOV [EBP], EBX ( 080C0A96 8B5D08 ) MOV EBX, [EBP+08] ( 080C0A99 C3 ) NEXT, ( 10 bytes, 4 instructions ) ok
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-13 00:02 -0500 |
| Message-ID | <o7reh0$js7$1@dont-email.me> |
| In reply to | #54815 |
On 2/12/2017 4:52 PM, Julian Fondren wrote: > On Sunday, February 12, 2017 at 3:42:04 PM UTC-6, Rod Pemberton wrote: >> >> Apparently, you have objections to the following? >> >> : ROVER >R OVER R> SWAP ; >> > > VFX Forth doesn't do as well with return-stack ops. > > : third >r over r> swap ; ok > see third > THIRD > ( 080C0A30 53 ) PUSH EBX > ( 080C0A31 5B ) POP EBX > ( 080C0A32 8D6DFC ) LEA EBP, [EBP+-04] > ( 080C0A35 895D00 ) MOV [EBP], EBX > ( 080C0A38 8B5D08 ) MOV EBX, [EBP+08] > ( 080C0A3B C3 ) NEXT, > ( 12 bytes, 6 instructions ) > ok > : third 2 pick ; > THIRD is redefined ok > see third > THIRD > ( 080C0A60 8D6DFC ) LEA EBP, [EBP+-04] > ( 080C0A63 895D00 ) MOV [EBP], EBX > ( 080C0A66 8B5D08 ) MOV EBX, [EBP+08] > ( 080C0A69 C3 ) NEXT, > ( 10 bytes, 4 instructions ) > ok > : third dup 2over drop nip ; > THIRD is redefined ok > see third > THIRD > ( 080C0A90 8D6DFC ) LEA EBP, [EBP+-04] > ( 080C0A93 895D00 ) MOV [EBP], EBX > ( 080C0A96 8B5D08 ) MOV EBX, [EBP+08] > ( 080C0A99 C3 ) NEXT, > ( 10 bytes, 4 instructions ) > ok The "third" example of third is a bit much isn't it? What about just : third 2over nip ; But I guess that doesn't know if there is a fourth item on the stack and could cause an error? It wouldn't on the GA144, lol. Odd that the third third is compiled efficiently. Odder is that VFX adds pointless instructions to the first third. I'd say that rises to the level of being a bug. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-02-12 21:27 -0800 |
| Message-ID | <30294f11-1343-4c7f-84f0-35f10cfcde51@googlegroups.com> |
| In reply to | #54829 |
On Sunday, February 12, 2017 at 11:02:08 PM UTC-6, rickman wrote: > Odd that the third third is compiled efficiently. I assume there's some stack analysis going on. It doesn't extend to 3dup... : third 3dup drop drop ; ok see third THIRD ( 080C0A30 E827E5F8FF ) CALL 0804EF5C 3DUP ( 080C0A35 8B5D04 ) MOV EBX, [EBP+04] ( 080C0A38 8D6D08 ) LEA EBP, [EBP+08] ( 080C0A3B C3 ) NEXT, ( 12 bytes, 4 instructions ) But if you inline 3dup's definition, you get the optimized version again: : third 2 pick 2 pick 2 pick drop drop ; see third THIRD ( 080C0A60 8D6DFC ) LEA EBP, [EBP+-04] ( 080C0A63 895D00 ) MOV [EBP], EBX ( 080C0A66 8B5D08 ) MOV EBX, [EBP+08] ( 080C0A69 C3 ) NEXT, ( 10 bytes, 4 instructions ) Incidentally the 2 PICK definition of THIRD is also the best in iForth and SwiftForth. This is all just another way that optimizers can encourage cleaner code, as with \ I don't want a runtime calcuation of 3 CELLS ... [ 3 cells ] literal * ... \ I don't have to worry about that ... 3 cells * ... -- Julian
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-02-13 07:53 +0000 |
| Message-ID | <2017Feb13.085315@mips.complang.tuwien.ac.at> |
| In reply to | #54829 |
rickman <gnuarm@gmail.com> writes:
>> : third >r over r> swap ; ok
>> see third
>> THIRD
>> ( 080C0A30 53 ) PUSH EBX
>> ( 080C0A31 5B ) POP EBX
>> ( 080C0A32 8D6DFC ) LEA EBP, [EBP+-04]
>> ( 080C0A35 895D00 ) MOV [EBP], EBX
>> ( 080C0A38 8B5D08 ) MOV EBX, [EBP+08]
>> ( 080C0A3B C3 ) NEXT,
>> ( 12 bytes, 6 instructions )
[this is the "first THIRD referred to below]
[...]
>Odder is that VFX
>adds pointless instructions to the first third. I'd say that rises to
>the level of being a bug.
Does the word behave incorrectly? If not, it is not a bug.
As for the instructions being "pointless", there is an optimization
opportunity here that the compiler does not exploit, but you can
explain nicely what happens by assuming that VFX tracks the data stack
during compilation, but not the return stack:
At the start, the stack is in canonical representation:
TOS is in EBX, and EBP points to the second item
>R generates PUSH EBX, EBP now points to TOS
OVER generates nothing, [EBP+4] is now TOS and third, [EBP] is now second.
R> generates POP EBX, TOS is in EBX, everything else is now one deeper
SWAP generates nothing, second:EBX, TOS,fourth: [EBP+4], third: [EBP]
; generates the code for getting the stack into its canonical
representation (see above) and then generates RET
- 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 | Michael Barry <barrym95838@yahoo.com> |
|---|---|
| Date | 2017-02-12 16:25 -0800 |
| Message-ID | <18d6676d-a975-4db1-9ac2-aa406ef882f1@googlegroups.com> |
| In reply to | #54814 |
On Sunday, February 12, 2017 at 1:42:04 PM UTC-8, Rod Pemberton wrote:
> ...
> Apparently, you have objections to the following?
>
> : ROVER >R OVER R> SWAP ;
>
>
> Rod Pemberton
65m32 (a 32-bit wide retro-cross between the 6502 and 6809, and
still a figment of my over-worked imagination):
\
PICK: \ ( ... w0 +n -- ... w0 wn ) \ Copy nth stack item to TOS
add #,s
lda ,a \ @
jmp (,y+) \ NEXT
\
ROVER: \ ( 2 1 0 -- 2 1 0 2 ) \ Copy the 3rd stack item to TOS
pda 1,s
jmp (,y+) \ NEXT
\
EXIT: \ ( -- ) \ Terminate a colon definition.
ldy ,x+ \ discard current IP and pop the
jmp (,y+) \ previous IP from R:
\
QEXIT: \ ( f -- ) \ EXIT a colon def if flag is 0
cdd #1 \ set carry only if flag is 0
pla \ DROP the flag
ldy [cs],x+ \ discard current IP and pop the
jmp (,y+) \ previous IP from R:
\
:-) Mike B.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-02-12 17:11 -0800 |
| Message-ID | <415ce57e-599b-47f6-943e-610b989c426c@googlegroups.com> |
| In reply to | #54819 |
On Sunday, February 12, 2017 at 5:25:22 PM UTC-7, Michael Barry wrote: > On Sunday, February 12, 2017 at 1:42:04 PM UTC-8, Rod Pemberton wrote: > > ... > > Apparently, you have objections to the following? > > > > : ROVER >R OVER R> SWAP ; > > > > > > Rod Pemberton > > 65m32 (a 32-bit wide retro-cross between the 6502 and 6809, and > still a figment of my over-worked imagination): > \ > PICK: \ ( ... w0 +n -- ... w0 wn ) \ Copy nth stack item to TOS > add #,s > lda ,a \ @ > jmp (,y+) \ NEXT > \ > ROVER: \ ( 2 1 0 -- 2 1 0 2 ) \ Copy the 3rd stack item to TOS > pda 1,s > jmp (,y+) \ NEXT > \ > EXIT: \ ( -- ) \ Terminate a colon definition. > ldy ,x+ \ discard current IP and pop the > jmp (,y+) \ previous IP from R: > \ > QEXIT: \ ( f -- ) \ EXIT a colon def if flag is 0 > cdd #1 \ set carry only if flag is 0 > pla \ DROP the flag > ldy [cs],x+ \ discard current IP and pop the > jmp (,y+) \ previous IP from R: > \ > > :-) Mike B. How big are the opcodes? If you have 16-bit opcodes, you could write the simulator using FAST-SWITCH> and get good speed. :-) 32-bit opcodes would require SLOW-SWITCH> most likely (unless you have pages of 16-bit opcodes and could use nested FAST-SWITCH> constructs).
[toc] | [prev] | [next] | [standalone]
| From | Michael Barry <barrym95838@yahoo.com> |
|---|---|
| Date | 2017-02-12 18:49 -0800 |
| Message-ID | <332248bb-f25c-4d47-b2b4-151e88bb6bac@googlegroups.com> |
| In reply to | #54824 |
On Sunday, February 12, 2017 at 5:11:11 PM UTC-8, hughag...@gmail.com wrote: > On Sunday, February 12, 2017 at 5:25:22 PM UTC-7, Michael Barry wrote: > > .. > > 65m32 (a 32-bit wide retro-cross between the 6502 and 6809, and > > still a figment of my over-worked imagination): > > \ > > PICK: \ ( ... w0 +n -- ... w0 wn ) \ Copy nth stack item to TOS > > add #,s > > lda ,a \ @ > > jmp (,y+) \ NEXT > > \ > > ROVER: \ ( 2 1 0 -- 2 1 0 2 ) \ Copy the 3rd stack item to TOS > > pda 1,s > > jmp (,y+) \ NEXT > > \ > > EXIT: \ ( -- ) \ Terminate a colon definition. > > ldy ,x+ \ discard current IP and pop the > > jmp (,y+) \ previous IP from R: > > \ > > QEXIT: \ ( f -- ) \ EXIT a colon def if flag is 0 > > cdd #1 \ set carry only if flag is 0 > > pla \ DROP the flag > > ldy [cs],x+ \ discard current IP and pop the > > jmp (,y+) \ previous IP from R: > > \ > > > > :-) Mike B. > > How big are the opcodes? > > If you have 16-bit opcodes, you could write the simulator using > FAST-SWITCH> and get good speed. :-) > > 32-bit opcodes would require SLOW-SWITCH> most likely (unless you > have pages of 16-bit opcodes and could use nested FAST-SWITCH> > constructs). All of the above machine instructions reside in single 32-bit words. The "mnemonic" is 7 bits, the numeric portion of the operand is 16 bits, and the operand "decorations" are 9 bits. If the numeric portion of the operand is not within [-32767 .. 32767], then the "magic" value of -32768 causes the numeric portion to be discarded and replaced with the value in the following word. I don't know Forth well enough to use it for my simulator .. it's 80% done, but I'm doing it in plain vanilla C [flame suit on]. Mike B.
[toc] | [prev] | [next] | [standalone]
| From | Michael Barry <barrym95838@yahoo.com> |
|---|---|
| Date | 2017-02-12 18:59 -0800 |
| Message-ID | <02232ebf-594b-417b-9861-58c03265446b@googlegroups.com> |
| In reply to | #54827 |
On Sunday, February 12, 2017 at 6:49:04 PM UTC-8, Michael Barry wrote: > ... > All of the above machine instructions reside in single 32-bit words. > > The "mnemonic" is 7 bits, the numeric portion of the operand is 16 > bits, and the operand "decorations" are 9 bits. If the numeric > portion of the operand is not within [-32767 .. 32767], then the > "magic" value of -32768 causes the numeric portion to be discarded > and replaced with the value in the following word. > > I don't know Forth well enough to use it for my simulator .. it's > 80% done, but I'm doing it in plain vanilla C [flame suit on]. > > Mike B. ... and I'm using a 128-entry jump table in my fetch/decode/execute loop :-)
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-02-12 21:18 -0800 |
| Message-ID | <6fd9f269-a17c-42ce-ab80-8a11c12b9af2@googlegroups.com> |
| In reply to | #54828 |
On Sunday, February 12, 2017 at 7:59:15 PM UTC-7, Michael Barry wrote: > On Sunday, February 12, 2017 at 6:49:04 PM UTC-8, Michael Barry wrote: > > ... > > All of the above machine instructions reside in single 32-bit words. > > > > The "mnemonic" is 7 bits, the numeric portion of the operand is 16 > > bits, and the operand "decorations" are 9 bits. If the numeric > > portion of the operand is not within [-32767 .. 32767], then the > > "magic" value of -32768 causes the numeric portion to be discarded > > and replaced with the value in the following word. > > > > I don't know Forth well enough to use it for my simulator .. it's > > 80% done, but I'm doing it in plain vanilla C [flame suit on]. > > > > Mike B. > > ... and I'm using a 128-entry jump table in my fetch/decode/execute > loop :-) If you are more comfortable with C than with Forth, then stick with C --- the SWITCH in C has always had a jump-table --- my FAST-SWITCH> is just a Forth version of C's SWITCH, so the Forth simulator would be very similar to the C simulator, with little or no advantage obtained by using Forth rather than C. As I said before though, the best way to write a simulator is to make the assembler not only generate the program for your target processor, but also generate a Forth program that runs on the host computer and simulates the program. This takes advantage of Forth's meta-compiling, which C does not support. You aren't decoding the opcode at run-time --- you are doing this work at compile-time --- the result should be a lot faster than anything that could be done in C (use VFX of course, not SwiftForth, to get good speed). This technique that I'm describing for Forth only works when you have the source-code and all of it is assembled by your assembler. This technique doesn't work when all you have is the machine-code for the target processor. For example, this would be a bad technique for a 65c02 simulator because most or all of the 65c02 programs that you are simulating were written in the 1980s and the source-code has been lost (or, more likely, is proprietary). With your 65M32 however, you do have all of the source-code --- there are no legacy programs from the old days, because the 65M32 didn't exist in the old days --- you personally wrote all of the 65M32 code, so you have the source-code.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-02-12 14:39 +0000 |
| Message-ID | <2017Feb12.153940@mips.complang.tuwien.ac.at> |
| In reply to | #54795 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>One could argue that if NIP and TUCK were primitives, and hence didn't
>have the overhead of an extra layer, they would be more widely used. But
>the fact is, most programmers I know just don't think of them.
[~/gforth:92760] grep -i "nip" *.fs */*.fs|wc -l
313
[~/gforth:92761] grep -i "swap drop" *.fs */*.fs|wc -l
41
Of these 41 occurences of "swap drop", most are in the Hayes tests
which try to use only core words, some are in code that was written
for Forth-83, some are occurences of "2swap drop", and very few could
be cases where NIP was available, but the programmer did not think of
it.
[~/gforth:92764] grep -i "tuck" *.fs */*.fs|wc -l
174
[~/gforth:92765] grep -i "swap over" *.fs */*.fs|wc -l
15
There is less Hayes test code here, but again some cases where not
using TUCK was intentional (e.g., in the Forth implementation of
TUCK), and an occurence of 2SWAP OVER.
It's interesting that TUCK and "SWAP OVER" combined are used much less
frequently than OVER (889 occurences). In Martin Mayerhofer's work on
stack allocation, the typical pattern was to compute a value on TOS,
and stash it away for later use using some TUCK-like operation. Forth
programmers apparently tend to work differently much of the time: they
compute the value ealier, then put other stuff on top of it, then grab
the value with OVER or the like.
One reason might be that the stack allocation work was limited to
straight-line code, with the stack empty on entry to the basic block
(only locals were used between basic blocks; this work was on the
JVM). For a Forth loop, you can put some read-only data lower on the
stack before the loop and access it with OVER; for a Forth definition,
you may want to access a parameter with OVER, if you use it again
later.
>It's also worth coding words that can affect
>performance, such as screen and disk I/O (though that's fading as
>rotating media disappears).
That makes no sense. If the I/O takes on the order of milliseconds
because of rotating media, saving some ns by writing the I/O words in
native code is not going to help significantly. OTOH, if you have an
inner loop that contains NIP, making the NIP fast can produce a
significant speedup.
- 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-02-11 18:47 -0800 |
| Message-ID | <19ab6cf0-ddf3-42d9-9aaf-41d0f042836a@googlegroups.com> |
| In reply to | #54789 |
On Saturday, February 11, 2017 at 5:55:11 AM UTC-7, Rod Pemberton wrote: > On Fri, 10 Feb 2017 18:13:43 -0800 (PST) > hughaguilar96@gmail.com wrote: > > > On Friday, February 10, 2017 at 6:43:56 PM UTC-7, HAA wrote: > > > > Coding style may influence this. For SwiftForth 0= IF NOT IF > > > appear 200 times compared to ?EXIT (151) EXIT-THEN (227). > > > > > > Numbers matter but decisions are made on less. Take ANS words NIP > > > and TUCK. SwiftForth: NIP (158) TUCK (56) > > > NIP and TUCK are conveniences - additions to the language that don't > > > fundamentally change anything. > > > > ANS-Forth was designed by Forth Inc. that in 1994 was using ITC and > > knew essentially nothing about code optimization. > > > > NIP is the same as: SWAP DROP > > TUCK is the same as: SWAP OVER > NIP and TUCK are prime examples of why I said your <SWITCH wouldn't be > used. LOL
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-12 00:49 -0500 |
| Message-ID | <o7ost6$uh$1@dont-email.me> |
| In reply to | #54786 |
On 2/10/2017 9:13 PM, hughaguilar96@gmail.com wrote: > On Friday, February 10, 2017 at 6:43:56 PM UTC-7, HAA wrote: >> Coding style may influence this. For SwiftForth 0= IF NOT IF appear >> 200 times compared to ?EXIT (151) EXIT-THEN (227). >> >> Numbers matter but decisions are made on less. Take ANS words NIP >> and TUCK. SwiftForth: NIP (158) TUCK (56) >> NIP and TUCK are conveniences - additions to the language that don't >> fundamentally change anything. > > ANS-Forth was designed by Forth Inc. that in 1994 was using ITC and knew essentially nothing about code optimization. > > NIP is the same as: SWAP DROP > TUCK is the same as: SWAP OVER NIP is often a no brainer as it only require a pop while writing to the top of the stack the same value that is there, or if the top of stack is cached doing nothing to it. TUCK is a different matter. It involves pushing the stack, but writing three values. Again, if the top of stack is cached this means not writing the top of stack, but still requires two writes to the actual stack. It would only require a single write if the top two levels of the stack are cached. In software caching the top two stack values is costly in terms of code, both space and execution time. In hardware its not a "big" deal, but requires not only the extra register, but extra multiplexers as well. When designing CPUs the multiplexers will blow up your logic counts if you aren't careful. So in a stack processor it is not likely to see TUCK as a hardware primitive unless it uses multiple clock cycles (anathema in my designs). -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-02-11 23:07 -0800 |
| Message-ID | <8737fjvqec.fsf@nightsong.com> |
| In reply to | #54803 |
rickman <gnuarm@gmail.com> writes: > When designing CPUs the multiplexers will blow up your logic counts if > you aren't careful. So in a stack processor it is not likely to see > TUCK as a hardware primitive unless it uses multiple clock cycles > (anathema in my designs). In a fancy-ass processor maybe it can be done by register renaming.
[toc] | [prev] | [next] | [standalone]
| From | Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> |
|---|---|
| Date | 2017-02-12 12:36 +0000 |
| Message-ID | <20170212123649.48ebae9d@t530.lan> |
| In reply to | #54805 |
On Sat, 11 Feb 2017 23:07:07 -0800 Paul Rubin <no.email@nospam.invalid> wrote: > rickman <gnuarm@gmail.com> writes: > > When designing CPUs the multiplexers will blow up your logic > > counts if you aren't careful. So in a stack processor it is > > not likely to see TUCK as a hardware primitive unless it > > uses multiple clock cycles (anathema in my designs). > > In a fancy-ass processor maybe it can be done by register > renaming. This is how my FA processor design does it. Stack items are of variable size, so access is indirect, and 'register renaming' is needed. Using 'copy on write' this also completes in one clock cycle for cached stack items. (OTOH, When performing math on multiple cell stack items sequencing is needed to obtain the streamed result. Using multiple clock cycles for this is a design feature.) Jan Coombs --
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-02-13 11:08 +1100 |
| Message-ID | <o7qtbc$1r99$1@gioia.aioe.org> |
| In reply to | #54786 |
hughaguilar96@gmail.com wrote: > ... > The same thing is true of ?EXIT --- making this a primitive is going to be result in > much faster code than IF EXIT THEN would --- this is why those old Forth systems had > ?EXIT despite the fact that it isn't used very much. Or expected to be used more often. Brodie & Moore comment on this in Thinking Forth. The problem, they argue, with redefining common sequences as a word is that you must recall the name and what it does. Easier just to remember the sequence as performing a useful function. Brodie refers to these as a 'cliches'. Interestingly systems which have ?NEGATE BOUNDS BUFFER: BOUNDS etc. it's often possible to find instances where the system programmer himself had forgotten and reverted to the long form!
[toc] | [prev] | [next] | [standalone]
Page 9 of 14 — ← Prev page 1 … 7 8 [9] 10 11 … 14 Next page →
Back to top | Article view | comp.lang.forth
csiph-web