Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #58987 > unrolled thread
| Started by | lehs <skydda.barnen@gmail.com> |
|---|---|
| First post | 2017-05-10 08:21 -0700 |
| Last post | 2017-05-15 11:23 +0000 |
| Articles | 20 on this page of 215 — 25 participants |
Back to article view | Back to comp.lang.forth
Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-10 08:21 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-10 16:39 +0100
Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-10 08:46 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 16:04 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 04:22 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-11 10:35 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 05:08 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-11 03:51 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 07:02 -0500
Re: Would ?EXIT work in all ANS-Forth systems? rickman <gnuarm@gmail.com> - 2017-05-13 11:55 -0400
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 09:32 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 11:56 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 12:20 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-15 12:31 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 15:50 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 16:49 +0000
Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-10 12:04 -0700
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-11 01:08 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-11 09:13 +0100
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-11 01:48 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-11 09:59 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-12 14:20 +0000
Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-12 17:01 -0700
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-12 22:18 -0700
Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-13 03:09 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-13 21:07 +1000
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:20 +0000
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-14 11:59 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-14 09:21 -0500
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-14 10:43 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-14 18:35 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-15 07:11 +0200
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 04:35 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-15 03:54 -0700
Re: Would ?EXIT work in all ANS-Forth systems? mhx@iae.nl - 2017-05-15 04:07 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 06:23 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-15 06:53 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 09:18 -0500
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-14 22:44 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 04:16 -0500
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-16 02:00 -0700
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-16 02:43 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 05:08 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 12:11 +0000
Re: Would ?EXIT work in all ANS-Forth systems? NN <november.nihal@gmail.com> - 2017-05-17 05:24 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-17 07:35 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-17 14:59 +0100
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-17 13:30 +0000
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-15 11:09 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-14 21:17 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-15 07:13 +0200
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-16 10:24 +1000
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-16 01:13 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 12:26 +0000
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-17 01:58 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-17 16:45 +0000
Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-25 12:04 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-26 10:02 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-26 07:46 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-26 13:53 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-26 10:14 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 10:16 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 08:59 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 11:27 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 10:19 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-26 20:20 +0200
Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 21:38 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 14:06 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 22:00 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-26 17:06 +0000
Re: Would ?EXIT work in all ANS-Forth systems? hum9 <obi65537@gmail.com> - 2017-05-27 01:15 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-28 14:17 +0000
Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-29 20:30 -0700
Re: Would ?EXIT work in all ANS-Forth systems? hum9 <obi65537@gmail.com> - 2017-05-29 21:08 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-30 04:12 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-30 12:44 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-30 08:09 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-30 14:35 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-30 16:27 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-31 12:16 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 05:34 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-01 02:14 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 08:40 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-01 06:14 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-01 13:16 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-01 07:43 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-01 14:15 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-02 11:49 +0100
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 16:42 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-02 03:19 -0500
Re: Would ?EXIT work in all ANS-Forth systems? hughaguilar96@gmail.com - 2017-06-01 14:07 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Matthias Trute <matthias.trute@gmail.com> - 2017-06-02 12:26 -0700
Re: Would ?EXIT work in all ANS-Forth systems? minforth@arcor.de - 2017-06-02 13:16 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Matthias Trute <matthias.trute@gmail.com> - 2017-06-03 01:34 -0700
Re: Would ?EXIT work in all ANS-Forth systems? minforth@arcor.de - 2017-06-03 02:54 -0700
Re: Would ?EXIT work in all ANS-Forth systems? hughaguilar96@gmail.com - 2017-06-01 13:53 -0700
Re: Would ?EXIT work in all ANS-Forth systems? hughaguilar96@gmail.com - 2017-06-01 13:48 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-01 22:31 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-02 08:03 -0500
Re: Would ?EXIT work in all ANS-Forth systems? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-02 15:16 +0200
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-02 14:30 +0100
Re: Would ?EXIT work in all ANS-Forth systems? hughaguilar96@gmail.com - 2017-06-02 07:32 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-02 18:23 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-06-01 14:49 -0700
Re: Would ?EXIT work in all ANS-Forth systems? minforth@arcor.de - 2017-06-01 16:05 -0700
Re: Would ?EXIT work in all ANS-Forth systems? hughaguilar96@gmail.com - 2017-06-01 17:48 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-06-01 18:44 -0700
Re: Would ?EXIT work in all ANS-Forth systems? hughaguilar96@gmail.com - 2017-06-01 19:14 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-06-01 19:54 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-27 17:40 +0000
WRAP...END-WRAP (was: Would ?EXIT work ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-30 15:28 +0000
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-24 15:46 +1000
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <obi65537@gmail.com> - 2017-05-25 11:51 -0700
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <obi65537@gmail.com> - 2017-05-25 20:38 -0700
Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-25 22:03 -0700
Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-25 22:09 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-26 21:56 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-26 13:30 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-27 15:04 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-27 17:33 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-29 12:17 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-29 08:42 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-30 11:14 +1000
Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-05-29 20:32 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-30 14:40 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-30 12:55 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-31 12:17 +1000
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-01 12:01 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-01 02:17 -0500
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-01 22:09 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-01 07:51 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-01 14:20 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-02 13:09 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-02 08:44 +0100
Re: Would ?EXIT work in all ANS-Forth systems? obi65537@gmail.com - 2017-06-02 11:05 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-02 19:34 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-03 14:29 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-06-02 21:54 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-04 22:52 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-06-02 22:24 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-06-03 07:34 +0100
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-03 08:39 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-06-03 13:47 +0100
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-03 14:36 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-06-04 17:29 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-04 10:28 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-05 15:09 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-05 09:36 +0100
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-05 09:35 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-05 10:57 +0100
Re: Would ?EXIT work in all ANS-Forth systems? JennyB <jennybrien@googlemail.com> - 2017-06-05 13:07 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-07 12:42 +1000
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-05 20:07 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-06-04 10:45 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-05 19:21 +1000
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-06-03 14:19 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-02 03:32 -0500
Re: Would ?EXIT work in all ANS-Forth systems? hughaguilar96@gmail.com - 2017-06-02 06:50 -0700
Re: Would ?EXIT work in all ANS-Forth systems? hum9 <obi65537@gmail.com> - 2017-05-27 00:33 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-27 14:53 +1000
READ-FILE over-specified? "HAA" <someone@microsoft.com> - 2017-05-27 21:28 +1000
Re: READ-FILE over-specified? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-27 13:11 +0000
Re: READ-FILE over-specified? "HAA" <someone@microsoft.com> - 2017-05-29 13:47 +1000
Re: READ-FILE over-specified? hughaguilar96@gmail.com - 2017-05-28 21:58 -0700
Re: READ-FILE over-specified? "HAA" <someone@microsoft.com> - 2017-05-30 11:06 +1000
Re: READ-FILE over-specified? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-28 09:44 +0200
Re: READ-FILE over-specified? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-28 13:41 +0000
Re: READ-FILE over-specified? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-28 19:59 +0200
Re: READ-FILE over-specified? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-29 05:20 +0000
Re: READ-FILE over-specified? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-29 10:29 +0200
Re: READ-FILE over-specified? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-29 09:34 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-16 09:42 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 09:53 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 04:53 -0500
Re: Would ?EXIT work in all ANS-Forth systems? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-16 12:32 +0200
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 12:35 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 10:48 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 18:23 +0100
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-17 04:33 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-17 12:29 +0100
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 10:28 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 10:43 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 16:34 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-16 12:41 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-17 16:14 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 03:05 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-18 16:33 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 12:43 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 04:01 -0500
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-18 15:41 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-18 11:58 -0500
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-18 22:57 +0100
Re: Would ?EXIT work in all ANS-Forth systems? "HAA" <someone@microsoft.com> - 2017-05-17 00:32 +1000
Re: Would ?EXIT work in all ANS-Forth systems? Alex <alex@rivadpm.com> - 2017-05-16 15:53 +0100
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-15 05:29 +0000
Re: Would ?EXIT work in all ANS-Forth systems? humptydumpty <ouatubi@gmail.com> - 2017-05-14 23:00 -0700
Re: Would ?EXIT work in all ANS-Forth systems? rickman <gnuarm@gmail.com> - 2017-05-17 12:27 -0400
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 09:16 +0000
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 09:55 +0000
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:25 +0000
Re: Would ?EXIT work in all ANS-Forth systems? Julian Fondren <julian.fondren@gmail.com> - 2017-05-13 07:49 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 09:59 +0000
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 12:22 +0000
Re: Would ?EXIT work in all ANS-Forth systems? "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:19 +0000
Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-14 23:23 -0700
Re: Would ?EXIT work in all ANS-Forth systems? Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-15 00:10 -0700
Re: Would ?EXIT work in all ANS-Forth systems? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-15 09:35 +0000
Re: Would ?EXIT work in all ANS-Forth systems? lehs <skydda.barnen@gmail.com> - 2017-05-15 00:54 -0700
Return-address manipulation (was: Would ?EXIT ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-15 08:47 +0000
Re: Return-address manipulation (was: Would ?EXIT ...) stephen@mpeforth.com (Stephen Pelc) - 2017-05-15 11:53 +0000
Re: Return-address manipulation (was: Would ?EXIT ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-16 13:03 +0000
Re: Return-address manipulation (was: Would ?EXIT ...) Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-16 07:06 -0700
Re: Return-address manipulation (was: Would ?EXIT ...) Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-16 07:14 -0700
Re: Would ?EXIT work in all ANS-Forth systems? "Elizabeth D. Rather" <erather@forth.com> - 2017-05-14 21:58 -1000
Re: Would ?EXIT work in all ANS-Forth systems? stephen@mpeforth.com (Stephen Pelc) - 2017-05-15 11:23 +0000
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-26 10:14 -0500 |
| Message-ID | <54ednVbw4IWn27XEnZ2dnUU7-budnZ2d@supernews.com> |
| In reply to | #59868 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> obi65537@gmail.com writes: >>> >>> But even if that was not the case, should we add features to the >>> language that make fast implementations slower (and not just when >>> using this feature) and/or more complicated in order to allow a usage >>> that saves some time on a slow system? If the users were interested >>> in speed, they would switch to a fast system. >> >>That's not entirely sound reasoning. Fast is good, small is good, >>simple is good. Every Forth system chooses some mix of these. It's >>wrong to say that someone who wants a simple system and is prepared >>somewhat to compromise speed to get simplicity is not interested in >>speed. > > Sure, in that case you choose some balance between speed and > simplicity. Does that give you the right to demand that other systems > become slower and/or more complicated so that you can use a technique > that may save time on your system? Absolutely not, no. I'm entirely in agreement with you on that matter. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-26 10:16 -0500 |
| Message-ID | <og9glj$ah5$1@dont-email.me> |
| In reply to | #59859 |
On 5/26/2017 7:46 AM, Andrew Haley wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> obi65537@gmail.com writes: >> >> But even if that was not the case, should we add features to the >> language that make fast implementations slower (and not just when >> using this feature) and/or more complicated in order to allow a usage >> that saves some time on a slow system? If the users were interested >> in speed, they would switch to a fast system. > > That's not entirely sound reasoning. Fast is good, small is good, > simple is good. Every Forth system chooses some mix of these. It's > wrong to say that someone who wants a simple system and is prepared > somewhat to compromise speed to get simplicity is not interested in > speed. > > Andrew. > I'm in that boat right now, making plans to migrate a Forth to create a Forth system that is small and simple to migrate to another CPU but I want it reasonably fast too and these three qualities are in conflict. I end up changing my mind as to what I want since its not easy to have all three qualities and be easy to port. Small and simple is easy but it's not fast, my original plans are for a Direct Threaded Token based on using C or Go suits those two qualities well but it's not fast. Making it fast is not simple or easy to migrate, just use assembler for the primitives or make it subroutine threaded. So making a decisions that makes all three happy while easy to migrate is not a simple task. Right now I think the only reasonable way to do it is with my original plan, Direct Threaded Token Forth and just get it working, it will be easy to port to another CPU, and if I use a particular CPU enough then convert that version to use Assembler for the primitives to speed it up, can't get away from assembler if one wants speed and small size. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-05-26 08:59 -0700 |
| Message-ID | <aeaa8c51-126c-4b2b-a105-e54c6e84ad31@googlegroups.com> |
| In reply to | #59871 |
vineri, 26 mai 2017, 18:16:19 UTC+3, Cecil - k5nwa a scris: > On 5/26/2017 7:46 AM, Andrew Haley wrote: > > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > >> obi65537@gmail.com writes: > >> > >> But even if that was not the case, should we add features to the > >> language that make fast implementations slower (and not just when > >> using this feature) and/or more complicated in order to allow a usage > >> that saves some time on a slow system? If the users were interested > >> in speed, they would switch to a fast system. > > > > That's not entirely sound reasoning. Fast is good, small is good, > > simple is good. Every Forth system chooses some mix of these. It's > > wrong to say that someone who wants a simple system and is prepared > > somewhat to compromise speed to get simplicity is not interested in > > speed. > > > > Andrew. > > > I'm in that boat right now, making plans to migrate a Forth to create a > Forth system that is small and simple to migrate to another CPU but I > want it reasonably fast too and these three qualities are in conflict. I > end up changing my mind as to what I want since its not easy to have all > three qualities and be easy to port. > > Small and simple is easy but it's not fast, my original plans are for a > Direct Threaded Token based on using C or Go suits those two qualities > well but it's not fast. Making it fast is not simple or easy to migrate, > just use assembler for the primitives or make it subroutine threaded. So > making a decisions that makes all three happy while easy to migrate is > not a simple task. > > Right now I think the only reasonable way to do it is with my original > plan, Direct Threaded Token Forth and just get it working, it will be > easy to port to another CPU, and if I use a particular CPU enough then > convert that version to use Assembler for the primitives to speed it up, > can't get away from assembler if one wants speed and small size. > > -- > Cecil - k5nwa I don't know what you mean by DTC token forth. I experimented some time ago a kind of threading technique for ARM Cortex-M CPUs. 32bit addresses as in DTC, but the VM "inner" interpreter looks for bit0 of the address. If this bit is "1", it treats it like a native code (primitive) and calls it directly. Incidentally, every primitive has this bit set (the thumb bit) so it fits naturally. The addresses that have bit0 "0" are treated like high level colon code, and the interpreter pushes the IP on the return stack by itself and does the nesting. This way, the system is only a bit slower than DTC when calling primitives but it's faster when calling high level words. Also, the high level words don't have the overhead of the DOCOL (ENTER, or whatever name you use). The only thing about this technique is that it's ... bigger. For a 32bit CPU every address is 32bit, jumps are 64bit, literals are 64bit, etc. Native code generation even when not inlining anything is a bit more compact. For such a CPU like a Cortex-M (say 48MHz or higher) this technique is more than enough in speed. Even for (non very critical) interrupts!
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-26 11:27 -0500 |
| Message-ID | <og9krr$qh9$1@dont-email.me> |
| In reply to | #59874 |
On 5/26/2017 10:59 AM, Raimond Dragomir wrote: > vineri, 26 mai 2017, 18:16:19 UTC+3, Cecil - k5nwa a scris: >> On 5/26/2017 7:46 AM, Andrew Haley wrote: >>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>> obi65537@gmail.com writes: >>>> >>>> But even if that was not the case, should we add features to the >>>> language that make fast implementations slower (and not just when >>>> using this feature) and/or more complicated in order to allow a usage >>>> that saves some time on a slow system? If the users were interested >>>> in speed, they would switch to a fast system. >>> >>> That's not entirely sound reasoning. Fast is good, small is good, >>> simple is good. Every Forth system chooses some mix of these. It's >>> wrong to say that someone who wants a simple system and is prepared >>> somewhat to compromise speed to get simplicity is not interested in >>> speed. >>> >>> Andrew. >>> >> I'm in that boat right now, making plans to migrate a Forth to create a >> Forth system that is small and simple to migrate to another CPU but I >> want it reasonably fast too and these three qualities are in conflict. I >> end up changing my mind as to what I want since its not easy to have all >> three qualities and be easy to port. >> >> Small and simple is easy but it's not fast, my original plans are for a >> Direct Threaded Token based on using C or Go suits those two qualities >> well but it's not fast. Making it fast is not simple or easy to migrate, >> just use assembler for the primitives or make it subroutine threaded. So >> making a decisions that makes all three happy while easy to migrate is >> not a simple task. >> >> Right now I think the only reasonable way to do it is with my original >> plan, Direct Threaded Token Forth and just get it working, it will be >> easy to port to another CPU, and if I use a particular CPU enough then >> convert that version to use Assembler for the primitives to speed it up, >> can't get away from assembler if one wants speed and small size. >> >> -- >> Cecil - k5nwa > > I don't know what you mean by DTC token forth. I experimented some time > ago a kind of threading technique for ARM Cortex-M CPUs. 32bit addresses > as in DTC, but the VM "inner" interpreter looks for bit0 of the address. > If this bit is "1", it treats it like a native code (primitive) and calls > it directly. Incidentally, every primitive has this bit set (the thumb bit) > so it fits naturally. The addresses that have bit0 "0" are treated like > high level colon code, and the interpreter pushes the IP on the return > stack by itself and does the nesting. This way, the system is only a bit > slower than DTC when calling primitives but it's faster when calling > high level words. Also, the high level words don't have the overhead > of the DOCOL (ENTER, or whatever name you use). > The only thing about this technique is that it's ... bigger. For a 32bit > CPU every address is 32bit, jumps are 64bit, literals are 64bit, etc. > Native code generation even when not inlining anything is a bit more > compact. > For such a CPU like a Cortex-M (say 48MHz or higher) this technique is more > than enough in speed. Even for (non very critical) interrupts! > > Its basically Direct threaded but instead of machine code in the code field it has one byte tokens, there is a jump table that the token uses to branch to the appropriate code written in C or Go. The code field has instructions (tokens) for a Forth VM instead of machine code, the whole thing does not have assembly code so it's easy to move to another CPU but its slower than having native code. If one uses a version enough then one can plan to replace the tokens with actual machine code for a speed improvement but only on CPUs that one uses a lot. I'll look at what you did and see if it can simplify the code. The whole purpose is to be able to easily modify the system for use with custom FPGA CPUs for which no software exist. Right now I use eForth Software with a Meta-Compiler to generate code for the custom CPU, this software is from C. H. Ting and it works well enough but the natives are restless and I want to try my own. This is getting so messy and complicated that I'm thinking to let things be the way they are and continue using eForth. So maybe before I build my own I might want to try adapting the current eForth system to a new CPU such as a dsPIC and see how it goes. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-05-26 10:19 -0700 |
| Message-ID | <6b9932de-bad6-4e80-97bb-b9210cd3794e@googlegroups.com> |
| In reply to | #59875 |
vineri, 26 mai 2017, 19:27:55 UTC+3, Cecil - k5nwa a scris: > On 5/26/2017 10:59 AM, Raimond Dragomir wrote: > > vineri, 26 mai 2017, 18:16:19 UTC+3, Cecil - k5nwa a scris: > >> On 5/26/2017 7:46 AM, Andrew Haley wrote: > >>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > >>>> obi65537@gmail.com writes: > >>>> > >>>> But even if that was not the case, should we add features to the > >>>> language that make fast implementations slower (and not just when > >>>> using this feature) and/or more complicated in order to allow a usage > >>>> that saves some time on a slow system? If the users were interested > >>>> in speed, they would switch to a fast system. > >>> > >>> That's not entirely sound reasoning. Fast is good, small is good, > >>> simple is good. Every Forth system chooses some mix of these. It's > >>> wrong to say that someone who wants a simple system and is prepared > >>> somewhat to compromise speed to get simplicity is not interested in > >>> speed. > >>> > >>> Andrew. > >>> > >> I'm in that boat right now, making plans to migrate a Forth to create a > >> Forth system that is small and simple to migrate to another CPU but I > >> want it reasonably fast too and these three qualities are in conflict. I > >> end up changing my mind as to what I want since its not easy to have all > >> three qualities and be easy to port. > >> > >> Small and simple is easy but it's not fast, my original plans are for a > >> Direct Threaded Token based on using C or Go suits those two qualities > >> well but it's not fast. Making it fast is not simple or easy to migrate, > >> just use assembler for the primitives or make it subroutine threaded. So > >> making a decisions that makes all three happy while easy to migrate is > >> not a simple task. > >> > >> Right now I think the only reasonable way to do it is with my original > >> plan, Direct Threaded Token Forth and just get it working, it will be > >> easy to port to another CPU, and if I use a particular CPU enough then > >> convert that version to use Assembler for the primitives to speed it up, > >> can't get away from assembler if one wants speed and small size. > >> > >> -- > >> Cecil - k5nwa > > > > I don't know what you mean by DTC token forth. I experimented some time > > ago a kind of threading technique for ARM Cortex-M CPUs. 32bit addresses > > as in DTC, but the VM "inner" interpreter looks for bit0 of the address. > > If this bit is "1", it treats it like a native code (primitive) and calls > > it directly. Incidentally, every primitive has this bit set (the thumb bit) > > so it fits naturally. The addresses that have bit0 "0" are treated like > > high level colon code, and the interpreter pushes the IP on the return > > stack by itself and does the nesting. This way, the system is only a bit > > slower than DTC when calling primitives but it's faster when calling > > high level words. Also, the high level words don't have the overhead > > of the DOCOL (ENTER, or whatever name you use). > > The only thing about this technique is that it's ... bigger. For a 32bit > > CPU every address is 32bit, jumps are 64bit, literals are 64bit, etc. > > Native code generation even when not inlining anything is a bit more > > compact. > > For such a CPU like a Cortex-M (say 48MHz or higher) this technique is more > > than enough in speed. Even for (non very critical) interrupts! > > > > > Its basically Direct threaded but instead of machine code in the code > field it has one byte tokens, there is a jump table that the token uses > to branch to the appropriate code written in C or Go. > > The code field has instructions (tokens) for a Forth VM instead of > machine code, the whole thing does not have assembly code so it's easy > to move to another CPU but its slower than having native code. If one > uses a version enough then one can plan to replace the tokens with > actual machine code for a speed improvement but only on CPUs that one > uses a lot. > > I'll look at what you did and see if it can simplify the code. > > The whole purpose is to be able to easily modify the system for use with > custom FPGA CPUs for which no software exist. Right now I use eForth > Software with a Meta-Compiler to generate code for the custom CPU, this > software is from C. H. Ting and it works well enough but the natives are > restless and I want to try my own. > > This is getting so messy and complicated that I'm thinking to let things > be the way they are and continue using eForth. So maybe before I build > my own I might want to try adapting the current eForth system to a new > CPU such as a dsPIC and see how it goes. > -- > Cecil - k5nwa I know eForth pretty well but it is a bit under my "standard". My forths are also quite simple, something in the eForth philosophy, but I improved some things, added other things etc. For example, I also have the FOR NEXT loops (and no DO LOOPs) like in eForth, by my FOR loops are just what they should have been in the first place. Looping N times (not N+1) and 0 times also (when N is 0, skip the loop entirely). Indexes (R@) from N-1 to 0. This can be done as simple as in eForth if you have the "working" primitive in FOR, not in NEXT. So my FOR compiles a doFOR with a forward branch over the loop and the NEXT simply jumps back unconditionally to FOR. My current working system is kind of token threaded. The primitives are tokenized (one byte per primitive but with some extension opcodes if you have more than 256 primitives), and the high level words are not tokenized, they just got called with "call" opcodes. It's like there is a VM with a finite set of opcodes, everyone being in fact a forth primitive. This is VERY compact.
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-05-26 20:20 +0200 |
| Message-ID | <86a85zo4yu.fsf@molnjunk.nocrew.org> |
| In reply to | #59879 |
Raimond Dragomir wrote: > My current working system is kind of token threaded. The primitives > are tokenized (one byte per primitive but with some extension opcodes > if you have more than 256 primitives), and the high level words are > not tokenized, they just got called with "call" opcodes. It's like > there is a VM with a finite set of opcodes, everyone being in fact > a forth primitive. > This is VERY compact. I working on a toy stack processor with 4-bit instructions. The generated code is very very compact if you stay with the primitives. But in practice most instructions are calls. Still, it's an interesting exercise. There's a simulator written in Forth, and a hardware design in Verilog.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-05-26 21:38 -0700 |
| Message-ID | <88f9052c-1c52-43f2-9dab-b39d01595f64@googlegroups.com> |
| In reply to | #59881 |
vineri, 26 mai 2017, 21:20:12 UTC+3, Lars Brinkhoff a scris: > Raimond Dragomir wrote: > > My current working system is kind of token threaded. The primitives > > are tokenized (one byte per primitive but with some extension opcodes > > if you have more than 256 primitives), and the high level words are > > not tokenized, they just got called with "call" opcodes. It's like > > there is a VM with a finite set of opcodes, everyone being in fact > > a forth primitive. > > This is VERY compact. > > I working on a toy stack processor with 4-bit instructions. The > generated code is very very compact if you stay with the primitives. > But in practice most instructions are calls. > > Still, it's an interesting exercise. There's a simulator written in > Forth, and a hardware design in Verilog. I know what you mean, still, the compactness come from various sources: 8bit literals (two bytes), 16bit literals (3 bytes), 16bit relative calls (3 bytes), 8bit and 16bit various jumps (2-3 bytes), etc. I didn't say that in a tokenized forth everything is 8bit tokens. I even implemented a paged addressing opcodes for literals, meaning that for addresses (in my forth systems addresses and constants are always compiled as literals) can be only 16bit. Otherwise you have 32bit literals for every address. For example, in a "classical" Cortex-M CPU with code at 0 and data at 0x20000000, I only need a "paged" literal for the 0x2000xxxx space, so that every data is compiled as 16bit (the offset to 0x2000xxxx).
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-05-26 14:06 -0500 |
| Message-ID | <og9u5o$rvc$1@dont-email.me> |
| In reply to | #59879 |
On 5/26/2017 12:19 PM, Raimond Dragomir wrote: > vineri, 26 mai 2017, 19:27:55 UTC+3, Cecil - k5nwa a scris: >> On 5/26/2017 10:59 AM, Raimond Dragomir wrote: >>> vineri, 26 mai 2017, 18:16:19 UTC+3, Cecil - k5nwa a scris: >>>> On 5/26/2017 7:46 AM, Andrew Haley wrote: >>>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>>> obi65537@gmail.com writes: >>>>>> >>>>>> But even if that was not the case, should we add features to the >>>>>> language that make fast implementations slower (and not just when >>>>>> using this feature) and/or more complicated in order to allow a usage >>>>>> that saves some time on a slow system? If the users were interested >>>>>> in speed, they would switch to a fast system. >>>>> >>>>> That's not entirely sound reasoning. Fast is good, small is good, >>>>> simple is good. Every Forth system chooses some mix of these. It's >>>>> wrong to say that someone who wants a simple system and is prepared >>>>> somewhat to compromise speed to get simplicity is not interested in >>>>> speed. >>>>> >>>>> Andrew. >>>>> >>>> I'm in that boat right now, making plans to migrate a Forth to create a >>>> Forth system that is small and simple to migrate to another CPU but I >>>> want it reasonably fast too and these three qualities are in conflict. I >>>> end up changing my mind as to what I want since its not easy to have all >>>> three qualities and be easy to port. >>>> >>>> Small and simple is easy but it's not fast, my original plans are for a >>>> Direct Threaded Token based on using C or Go suits those two qualities >>>> well but it's not fast. Making it fast is not simple or easy to migrate, >>>> just use assembler for the primitives or make it subroutine threaded. So >>>> making a decisions that makes all three happy while easy to migrate is >>>> not a simple task. >>>> >>>> Right now I think the only reasonable way to do it is with my original >>>> plan, Direct Threaded Token Forth and just get it working, it will be >>>> easy to port to another CPU, and if I use a particular CPU enough then >>>> convert that version to use Assembler for the primitives to speed it up, >>>> can't get away from assembler if one wants speed and small size. >>>> >>>> -- >>>> Cecil - k5nwa >>> >>> I don't know what you mean by DTC token forth. I experimented some time >>> ago a kind of threading technique for ARM Cortex-M CPUs. 32bit addresses >>> as in DTC, but the VM "inner" interpreter looks for bit0 of the address. >>> If this bit is "1", it treats it like a native code (primitive) and calls >>> it directly. Incidentally, every primitive has this bit set (the thumb bit) >>> so it fits naturally. The addresses that have bit0 "0" are treated like >>> high level colon code, and the interpreter pushes the IP on the return >>> stack by itself and does the nesting. This way, the system is only a bit >>> slower than DTC when calling primitives but it's faster when calling >>> high level words. Also, the high level words don't have the overhead >>> of the DOCOL (ENTER, or whatever name you use). >>> The only thing about this technique is that it's ... bigger. For a 32bit >>> CPU every address is 32bit, jumps are 64bit, literals are 64bit, etc. >>> Native code generation even when not inlining anything is a bit more >>> compact. >>> For such a CPU like a Cortex-M (say 48MHz or higher) this technique is more >>> than enough in speed. Even for (non very critical) interrupts! >>> >>> >> Its basically Direct threaded but instead of machine code in the code >> field it has one byte tokens, there is a jump table that the token uses >> to branch to the appropriate code written in C or Go. >> >> The code field has instructions (tokens) for a Forth VM instead of >> machine code, the whole thing does not have assembly code so it's easy >> to move to another CPU but its slower than having native code. If one >> uses a version enough then one can plan to replace the tokens with >> actual machine code for a speed improvement but only on CPUs that one >> uses a lot. >> >> I'll look at what you did and see if it can simplify the code. >> >> The whole purpose is to be able to easily modify the system for use with >> custom FPGA CPUs for which no software exist. Right now I use eForth >> Software with a Meta-Compiler to generate code for the custom CPU, this >> software is from C. H. Ting and it works well enough but the natives are >> restless and I want to try my own. >> >> This is getting so messy and complicated that I'm thinking to let things >> be the way they are and continue using eForth. So maybe before I build >> my own I might want to try adapting the current eForth system to a new >> CPU such as a dsPIC and see how it goes. >> -- >> Cecil - k5nwa > > I know eForth pretty well but it is a bit under my "standard". > My forths are also quite simple, something in the eForth philosophy, > but I improved some things, added other things etc. For example, > I also have the FOR NEXT loops (and no DO LOOPs) like in eForth, > by my FOR loops are just what they should have been in the first > place. Looping N times (not N+1) and 0 times also (when N is 0, skip > the loop entirely). Indexes (R@) from N-1 to 0. This can be done > as simple as in eForth if you have the "working" primitive in FOR, > not in NEXT. So my FOR compiles a doFOR with a forward branch > over the loop and the NEXT simply jumps back unconditionally to FOR. > > My current working system is kind of token threaded. The primitives > are tokenized (one byte per primitive but with some extension opcodes > if you have more than 256 primitives), and the high level words are > not tokenized, they just got called with "call" opcodes. It's like > there is a VM with a finite set of opcodes, everyone being in fact > a forth primitive. > This is VERY compact. > I use eForth mostly for FPGA CPUs to generate a target Forth, and some embedded CPUs where having too many tools can be detrimental as the resources are limited. for PCs I have VFX, MPE and various free Forth that seem decent. Contrary to many I like the DO and LOOP words but I also have a set of favorite extra words to enhance plain eForth. Interesting in that your eForth uses one byte tokens, that is what I was planning on having so a question or two. What CPUs is your tokenized eForth for? Is it fast enough to get the job done? I'm a speed freak and I'm afraid that too many times it turns out that a not so fast Forth is more than good enough but I still worry about it not being efficient and as fast as it could be for nothing I might add. I figured a tokenized Forth is easy to move to a new CPU but it also has a path to become more efficient without a major re-write if required. Before anyone starts getting cranky maybe this discussion belong on it's own thread. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-05-26 22:00 -0700 |
| Message-ID | <b49e9fa3-6611-4a99-b9fc-7015300bcbab@googlegroups.com> |
| In reply to | #59882 |
> Contrary to many I like the DO and LOOP words but I also have a set of > favorite extra words to enhance plain eForth. I don't have a strong opinion against do loops. Only that so many times you really don't need them, I mean you need just a simpler counted loop, like FOR. In my "biggest" forth implementation (one that's only for the PC side, I didn't port it yet to an embedded microcontroller) I have a variant of DO LOOPs in which: DO is like the standard ?DO LOOP is standard and I have -LOOP which is the decrementing variant of the incrementing LOOP. I also have IX JX KX and LX indexes which work in a "normal" way, meaning that the IX is always for the first (outer) loop, JX for the next one, and so on, LX is for the most inner loop (last) if you really need four nested loops :) I don't have +LOOP. In my experience, when I need a stepped index, I also need the normal one, so I need to derive some of it from the other. So I sticked with the simplest form of +1 and -1 steps. > What CPUs is your tokenized eForth for? > Is it fast enough to get the job done? Cortex-M CPUs. Yes fast enough, although I didn't experimented an interrupt routine in a tokenized form. But I suspect that short timer handlers at milliseconds rates or relatively slow uart handlers are doable. My tokenized architecture is not even very optimized. Any primitive can be natively called, so you can mix native code with tokenized code easily. You can imagine a compiler which can compile some words natively (or STC) and other words as tokenized code. This way you can have the right mix of compactness and speed. > > I'm a speed freak and I'm afraid that too many times it turns out that a > not so fast Forth is more than good enough but I still worry about it > not being efficient and as fast as it could be for nothing I might add. > I can't help you about that, and probably nobody can. You need to do things, and experiment yourself. I'm convinced a mixed native/tokenized compiler is the right way to go. In a hope that very few things will need native code compilingand the most of the application will be tokenized. > I figured a tokenized Forth is easy to move to a new CPU but it also has > a path to become more efficient without a major re-write if required. > > Before anyone starts getting cranky maybe this discussion belong on it's > own thread. > > -- > Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-26 17:06 +0000 |
| Message-ID | <2017May26.190627@mips.complang.tuwien.ac.at> |
| In reply to | #59368 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>humptydumpty <ouatubi@gmail.com> writes:
>>One of quick & dirty multilevel drop that I thought is pair:
>>
>>: ESC ( rp -- ) RP! ;
>>: ESCAPES> ( xt[rp--] -- ) RP@ swap EXECUTE ;
>>
>>And used something like:
>>
>>: escaping-word ( .. rp -- ... ) .. IF ESC THEN ... ;
>>: working-word ( .. rp -- ... ) .. escaping-word ... ;
>>: current-word ( .. -- ... ) ['] working-word ESCAPES> ... ;
>
>What's wrong with
>
>: escaping-word ( .. -- ... ) .. THROW ... ;
>: working-word ( .. -- ... ) .. escaping-word ... ;
>: current-word ( .. -- ... ) ['] working-word CATCH ... ;
>
>Advantages: no np to pass around, no IF, and it's standard. In
>practice you will probably want to throw and catch a specific ball,
>but that's still easier than passing np through various words.
I made a small microbenchmark based on that:
: bench-catch
100000000 0 ?do ['] noop catch throw loop ;
: ESC ( rp -- ) RP! ;
: ESCAPES> ( xt[rp--] -- ) RP@ swap EXECUTE ;
: escaping-word1 ( .. rp -- ... ) true IF drop fdrop ESC THEN ;
: working-word1 ( .. rp -- ... ) 1 1e escaping-word1 drop fdrop ;
: current-word1 ( .. -- ... ) ['] working-word1 ESCAPES> ;
: escaping-word2 ( .. -- ... ) true if 1 fast-throw then ;
: working-word2 ( .. -- ... ) 1 1e escaping-word2 drop fdrop ;
: current-word2 ( .. -- ... ) ['] working-word2 CATCH drop ;
: bench-esc
100000000 0 ?do current-word1 loop ;
: bench-fthrow
100000000 0 ?do current-word2 loop ;
FAST-THROW is a THROW that does not produce a backtrace and always
throws (that's why it is wrapped in IF..THEN here).
Results in cycles per iteration on Gforth-fast (development version):
31 bench-esc
95 bench-fthrow
73 bench-catch
So we could improve the performance of BENCH-FTHROW by improving the
performance of CATCH (which is possible). But even so, 95 cycles is
not that expensive.
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | hum9 <obi65537@gmail.com> |
|---|---|
| Date | 2017-05-27 01:15 -0700 |
| Message-ID | <3947d8a6-eb34-44ee-87db-c9ed046bf654@googlegroups.com> |
| In reply to | #59880 |
On Friday, May 26, 2017 at 8:23:40 PM UTC+3, Anton Ertl wrote: > anton (Anton Ertl) writes: > >humptydumpty writes: > >>One of quick & dirty multilevel drop that I thought is pair: > >> > >>: ESC ( rp -- ) RP! ; > >>: ESCAPES> ( xt[rp--] -- ) RP@ swap EXECUTE ; > >> > >>And used something like: > >> > >>: escaping-word ( .. rp -- ... ) .. IF ESC THEN ... ; > >>: working-word ( .. rp -- ... ) .. escaping-word ... ; > >>: current-word ( .. -- ... ) ['] working-word ESCAPES> ... ; > > > >What's wrong with > > > >: escaping-word ( .. -- ... ) .. THROW ... ; > >: working-word ( .. -- ... ) .. escaping-word ... ; > >: current-word ( .. -- ... ) ['] working-word CATCH ... ; > > > >Advantages: no np to pass around, no IF, and it's standard. In > >practice you will probably want to throw and catch a specific ball, > >but that's still easier than passing np through various words. > > I made a small microbenchmark based on that: > > : bench-catch > 100000000 0 ?do ['] noop catch throw loop ; > > : ESC ( rp -- ) RP! ; > : ESCAPES> ( xt[rp--] -- ) RP@ swap EXECUTE ; > > : escaping-word1 ( .. rp -- ... ) true IF drop fdrop ESC THEN ; > : working-word1 ( .. rp -- ... ) 1 1e escaping-word1 drop fdrop ; > : current-word1 ( .. -- ... ) ['] working-word1 ESCAPES> ; > > : escaping-word2 ( .. -- ... ) true if 1 fast-throw then ; > : working-word2 ( .. -- ... ) 1 1e escaping-word2 drop fdrop ; > : current-word2 ( .. -- ... ) ['] working-word2 CATCH drop ; > > : bench-esc > 100000000 0 ?do current-word1 loop ; > > : bench-fthrow > 100000000 0 ?do current-word2 loop ; > > FAST-THROW is a THROW that does not produce a backtrace and always > throws (that's why it is wrapped in IF..THEN here). > > Results in cycles per iteration on Gforth-fast (development version): > 31 bench-esc > 95 bench-fthrow > 73 bench-catch > > So we could improve the performance of BENCH-FTHROW by improving the > performance of CATCH (which is possible). But even so, 95 cycles is > not that expensive. > > - 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 2017: http://www.euroforth.org/ef17/ One would use what is more suited in the working context. :) For me, more than ESC/ESCAPES> (which was used as proof of concept) I prefer 'callec'. I did not intent to use 'callec' as substitute for 'CALL/THROW' on treating exceptions. Each technique for its job. Have a nice day, hum9
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-28 14:17 +0000 |
| Message-ID | <2017May28.161741@mips.complang.tuwien.ac.at> |
| In reply to | #59911 |
hum9 <obi65537@gmail.com> writes:
>One would use what is more suited in the working context. :)
>
>For me, more than ESC/ESCAPES> (which was used as proof of concept)
>I prefer 'callec'. I did not intent to use 'callec' as substitute
>for 'CALL/THROW' on treating exceptions.
My point is that CATCH/THROW is better for multi-level exit than
explicit return-address manipulation: It cleans up the stacks, and
works also with locals and on systems with tail-call elimination and
inlining.
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | obi65537@gmail.com |
|---|---|
| Date | 2017-05-29 20:30 -0700 |
| Message-ID | <9cc27b0b-2086-46f8-bc39-0cfa1fde6ad7@googlegroups.com> |
| In reply to | #59971 |
On Sunday, May 28, 2017 at 5:22:20 PM UTC+3, Anton Ertl wrote: > hum9 writes: > >One would use what is more suited in the working context. :) > > > >For me, more than ESC/ESCAPES> (which was used as proof of concept) > >I prefer 'callec'. I did not intent to use 'callec' as substitute > >for 'CALL/THROW' on treating exceptions. > > My point is that CATCH/THROW is better for multi-level exit than > explicit return-address manipulation: It cleans up the stacks, and > works also with locals and on systems with tail-call elimination and > inlining. > > - 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 2017: http://www.euroforth.org/ef17/ My point is using 'CATCH/THROW' for multilevel-exit is an abuse. It does more than is needed, had speed penalty for that and does not have 'CALLEC' flexibility. Direct return-stack manipulations, 'ESC/ESCAPES>', 'CALLEC' does preserve data stack items. When 'THROW'-ing useful data stack items are shoved-up: ANS-Forth excerpt: "data stack depth is the same as it was just before CATCH began execution. The values of the i * x stack arguments could have been modified arbitrarily during the execution of xt. In general, nothing useful may be done with those stack items, but since their number is known (because the stack depth is deterministic), the application may DROP them to return to a predictable stack state." If using 'CATCH/THROW', data stack items that have to be passed to continuation of 'CATCH' should be saved somewhere before 'THROW' and restored after 'CATCH'. Have a nice day, hum9
[toc] | [prev] | [next] | [standalone]
| From | hum9 <obi65537@gmail.com> |
|---|---|
| Date | 2017-05-29 21:08 -0700 |
| Message-ID | <fe9f0f37-0958-4282-ab6e-3c7155cf4796@googlegroups.com> |
| In reply to | #60038 |
On Tuesday, May 30, 2017 at 6:30:25 AM UTC+3, obi6...@gmail.com wrote: > On Sunday, May 28, 2017 at 5:22:20 PM UTC+3, Anton Ertl wrote: > > hum9 writes: > > >One would use what is more suited in the working context. :) > > > > > >For me, more than ESC/ESCAPES> (which was used as proof of concept) > > >I prefer 'callec'. I did not intent to use 'callec' as substitute > > >for 'CALL/THROW' on treating exceptions. > > > > My point is that CATCH/THROW is better for multi-level exit than > > explicit return-address manipulation: It cleans up the stacks, and > > works also with locals and on systems with tail-call elimination and > > inlining. > > > > - 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 2017: http://www.euroforth.org/ef17/ > > > My point is using 'CATCH/THROW' for multilevel-exit is an abuse. > It does more than is needed, had speed penalty for that and does not > have 'CALLEC' flexibility. > > Direct return-stack manipulations, 'ESC/ESCAPES>', 'CALLEC' does preserve data stack items. > > When 'THROW'-ing useful data stack items are shoved-up: ANS-Forth excerpt: > "data stack depth is the same as it was just before CATCH began execution. > The values of the i * x stack arguments could have been modified arbitrarily during the execution of xt. In general, nothing useful may be done with those stack items, but since their number is known (because the stack depth is deterministic), the application may DROP them to return to a predictable stack state." > > If using 'CATCH/THROW', data stack items that have to be passed to > continuation of 'CATCH' should be saved somewhere before 'THROW' and > restored after 'CATCH'. > > Have a nice day, > hum9 Also when using 'CATCH/THROW' for multilevel-exit one should define and maintain unique constants for 'THROW'. hum9
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-30 04:12 -0500 |
| Message-ID | <YradnRSRhdMJqrDEnZ2dnUU7-IWdnZ2d@supernews.com> |
| In reply to | #60038 |
obi65537@gmail.com wrote: > > My point is using 'CATCH/THROW' for multilevel-exit is an abuse. > It does more than is needed, had speed penalty for that and does not > have 'CALLEC' flexibility. It's certainly bad style, but so is fooling about with the return stack. In either case it's not going to help anyone understand the code. My question at review time for something like this would be "What are you really trying to do, and why does it get into such a mess?" Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-30 12:44 +0100 |
| Message-ID | <ogjlp1$ujl$1@dont-email.me> |
| In reply to | #60052 |
On 5/30/2017 10:12, Andrew Haley wrote: > obi65537@gmail.com wrote: >> >> My point is using 'CATCH/THROW' for multilevel-exit is an abuse. >> It does more than is needed, had speed penalty for that and does not >> have 'CALLEC' flexibility. > > It's certainly bad style, but so is fooling about with the return > stack. Which is worse; bad style or fooling with the return stack? In the first instance, we can mark it down on the subjective grounds that it is ugly. In the second we can mark it as not just bad style, but objectively bad code. There is nothing in any of the Forth standards (afaik) that demands return addresses are available on the return stack. > In either case it's not going to help anyone understand the > code. My question at review time for something like this would be > "What are you really trying to do, and why does it get into such a > mess?" Sometimes it's not possible to avoid, even with factoring; returning to the caller (even a single level return) may have multiple DROPs and R> DROPs just to get the stack back to anything sensible. The recognizer proposal is one example where recognizers, especially when nested, may require levels of effort to unwind stacks that make the code exceedingly complex to follow and would undoubtedly score zero style points in review. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-30 08:09 -0500 |
| Message-ID | <LoydnefUF49g87DEnZ2dnUU7-QvNnZ2d@supernews.com> |
| In reply to | #60057 |
Alex <alex@rivadpm.com> wrote: > On 5/30/2017 10:12, Andrew Haley wrote: >> obi65537@gmail.com wrote: >>> >>> My point is using 'CATCH/THROW' for multilevel-exit is an abuse. >>> It does more than is needed, had speed penalty for that and does not >>> have 'CALLEC' flexibility. >> >> It's certainly bad style, but so is fooling about with the return >> stack. > > Which is worse; bad style or fooling with the return stack? Which would you rather have, leprosy or anthrax? :-) > In the first instance, we can mark it down on the subjective grounds > that it is ugly. In the second we can mark it as not just bad > style, but objectively bad code. There is nothing in any of the > Forth standards (afaik) that demands return addresses are available > on the return stack. I agree. >> In either case it's not going to help anyone understand the >> code. My question at review time for something like this would be >> "What are you really trying to do, and why does it get into such a >> mess?" > > Sometimes it's not possible to avoid, even with factoring; returning > to the caller (even a single level return) may have multiple DROPs > and R> DROPs just to get the stack back to anything sensible. The > recognizer proposal is one example where recognizers, especially > when nested, may require levels of effort to unwind stacks that make > the code exceedingly complex to follow and would undoubtedly score > zero style points in review. Hmm, and that is at least a clue that something might be wrong: at the minimum it's bad code smell because nested (recursive, even?) recognizers have got to be rather complex. Maybe it would be a clue to the programmer to back out, consider the language being recognized, and think about whether it could be redesigned. Having said that, if you really do have a complex string to parse, throwing from a recognizer when parsing has failed seems to me to be an excellent use of CATCH and THROW . I have to admit a bias: the languages I prefer are LL(1) or perhaps LL(k), with k very small. They don't need a parser to scan forward until something doesn't match, then throw away the context, backtrack, and try something else. These languages are (IMVHO) easier for people to read as well, because people don't have to scan ahead to figure out what a token means. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-30 14:35 +0000 |
| Message-ID | <2017May30.163536@mips.complang.tuwien.ac.at> |
| In reply to | #60059 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Alex <alex@rivadpm.com> wrote:
>> Sometimes it's not possible to avoid, even with factoring; returning
>> to the caller (even a single level return) may have multiple DROPs
>> and R> DROPs just to get the stack back to anything sensible. The
>> recognizer proposal is one example where recognizers, especially
>> when nested, may require levels of effort to unwind stacks that make
>> the code exceedingly complex to follow and would undoubtedly score
>> zero style points in review.
>
>Hmm, and that is at least a clue that something might be wrong: at the
>minimum it's bad code smell because nested (recursive, even?)
>recognizers have got to be rather complex. Maybe it would be a clue
>to the programmer to back out, consider the language being recognized,
>and think about whether it could be redesigned.
The first example of a nesting recognizer that comes to my mind is the
meta-recognizer. It was devised in reaction to a complaint (from you)
about recognizers being able to shadow each other (i.e., a standard
Forth feature that has occasionally caused problems and that Forth
programmers have learned to deal with, but that you imagine having
catastrophic consequences in connection with recognizers). The meta
recognizer lets you write
float?1. f. \ prints 1.
num?1. d. \ prints 1 (after giving a warning about this being a double)
Let's see if it works recursively:
meta?meta?float?1. f. \ prints 1.
Yup, works. But it's just a curiosity.
I.e., a case where we have shadowing now and lots of complaints about
the way standard Forth resolves it.
Let's see the code for this recognizer:
: rec:meta ( addr u -- xt r:to | r:fail )
\G words prefixed with @var{recognizer}@code{?} are processed by
\G @code{rec:}@var{recognizer} to disambiguate recognizers.
'?' $split dup 0= IF 2drop
ELSE
2swap [: ." rec:" type ;] $tmp find-name ?dup-IF
name?int execute EXIT
THEN
THEN
2drop r:fail ;
get-recognizers ' rec:meta swap 1+ set-recognizers
Does not seem too bad.
>I have to admit a bias: the languages I prefer are LL(1) or perhaps
>LL(k), with k very small. They don't need a parser to scan forward
>until something doesn't match, then throw away the context, backtrack,
>and try something else. These languages are (IMVHO) easier for people
>to read as well, because people don't have to scan ahead to figure out
>what a token means.
Recognizers are more like scanners than parsers in Algol-family
languages, and LL(1) does not work satisfactorily for scanners.
Still, it's a good idea to put identifying stuff at the front (e.g.,
Forth-2012 $10), instead of at the end (e.g., Forth-94/2012 "1." or
Intel assembler 10H).
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-30 16:27 +0100 |
| Message-ID | <ogk2q8$goh$1@dont-email.me> |
| In reply to | #60066 |
On 5/30/2017 15:35, Anton Ertl wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>
> : rec:meta ( addr u -- xt r:to | r:fail )
> \G words prefixed with @var{recognizer}@code{?} are processed by
> \G @code{rec:}@var{recognizer} to disambiguate recognizers.
> '?' $split dup 0= IF 2drop
> ELSE
> 2swap [: ." rec:" type ;] $tmp find-name ?dup-IF
> name?int execute EXIT
> THEN
> THEN
> 2drop r:fail ;
>
> get-recognizers ' rec:meta swap 1+ set-recognizers
>
> Does not seem too bad.
>
>> I have to admit a bias: the languages I prefer are LL(1) or perhaps
>> LL(k), with k very small. They don't need a parser to scan forward
>> until something doesn't match, then throw away the context, backtrack,
>> and try something else. These languages are (IMVHO) easier for people
>> to read as well, because people don't have to scan ahead to figure out
>> what a token means.
>
> Recognizers are more like scanners than parsers in Algol-family
> languages, and LL(1) does not work satisfactorily for scanners.
> Still, it's a good idea to put identifying stuff at the front (e.g.,
> Forth-2012 $10), instead of at the end (e.g., Forth-94/2012 "1." or
> Intel assembler 10H).
>
It's a lot more work to detect (for example) the . in a scope.prefix or
the : in a class:method, yet we seem to be OK with that as your example
shows. I don't see trailing signifiers as an issue.
(Although I do dislike xxxxH immensely. Cheap low pin count dot matrix
printers often made H and 4 indistinguishable.)
--
Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-31 12:16 -0500 |
| Message-ID | <MeednenTHvX3Z7PEnZ2dnUU7-VnNnZ2d@supernews.com> |
| In reply to | #60066 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >>I have to admit a bias: the languages I prefer are LL(1) or perhaps >>LL(k), with k very small. They don't need a parser to scan forward >>until something doesn't match, then throw away the context, backtrack, >>and try something else. These languages are (IMVHO) easier for people >>to read as well, because people don't have to scan ahead to figure out >>what a token means. > > Recognizers are more like scanners than parsers in Algol-family > languages, Really? Surely if you've got a recursive bunch of recognizers you've got a recursive-decent parser. And if they're throwing exceptions, catching, and retrying, you've got a recursive descent parser with backtracking. > and LL(1) does not work satisfactorily for scanners. Still, it's a > good idea to put identifying stuff at the front (e.g., Forth-2012 > $10), instead of at the end (e.g., Forth-94/2012 "1." or Intel > assembler 10H). Indeed so: we should write for the reader. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
Back to top | Article view | comp.lang.forth
csiph-web