Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #53228 > unrolled thread
| Started by | Nathan Schulzke <nschulzke@gmail.com> |
|---|---|
| First post | 2016-12-09 09:25 -0800 |
| Last post | 2017-01-07 15:37 +0000 |
| Articles | 20 on this page of 171 — 22 participants |
Back to article view | Back to comp.lang.forth
Ideal Stack Machine Instruction Set Nathan Schulzke <nschulzke@gmail.com> - 2016-12-09 09:25 -0800
Re: Ideal Stack Machine Instruction Set Nathan Schulzke <nschulzke@gmail.com> - 2016-12-09 09:30 -0800
Re: Ideal Stack Machine Instruction Set trans <transfire@gmail.com> - 2016-12-09 10:23 -0800
Re: Ideal Stack Machine Instruction Set Nathan Schulzke <nschulzke@gmail.com> - 2016-12-09 16:37 -0800
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2016-12-09 17:01 -0800
Re: Ideal Stack Machine Instruction Set Nathan Schulzke <nschulzke@gmail.com> - 2016-12-10 09:07 -0800
Re: Ideal Stack Machine Instruction Set Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-01 21:40 -0500
Re: Ideal Stack Machine Instruction Set "Elizabeth D. Rather" <erather@forth.com> - 2017-01-01 21:06 -1000
Re: Ideal Stack Machine Instruction Set Paul Rubin <no.email@nospam.invalid> - 2017-01-03 17:22 -0800
Re: Ideal Stack Machine Instruction Set Lars Brinkhoff <lars.spam@nocrew.org> - 2017-01-04 10:09 +0100
Re: Ideal Stack Machine Instruction Set john <anon@example.com> - 2017-01-04 11:59 +0000
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-04 10:56 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-04 23:58 +0100
Re: Ideal Stack Machine Instruction Set Paul Rubin <no.email@nospam.invalid> - 2017-01-04 20:06 -0800
Re: Ideal Stack Machine Instruction Set Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-05 04:12 -0600
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-05 12:43 +0100
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-05 16:38 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-05 19:17 +0100
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-05 18:26 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-06 01:56 +0100
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-07 15:53 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-07 18:20 +0100
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-08 16:33 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 20:02 +0100
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-09 17:53 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-09 20:22 +0100
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-09 08:04 -0800
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-09 17:04 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-09 20:22 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-10 01:41 +0100
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-09 22:16 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 09:44 +0000
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-10 15:19 +0100
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 15:24 +0000
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 15:35 +0000
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-10 22:12 +0100
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 22:42 +0000
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-11 00:23 +0100
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 23:35 +0000
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-10 23:38 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-11 10:32 +0000
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-11 12:52 +0100
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-11 13:23 +0000
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-11 06:08 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-11 14:39 +0000
Re: Ideal Stack Machine Instruction Set franck.bensusan@gmail.com - 2017-01-11 23:00 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-12 13:55 +0000
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-12 14:06 +0000
Re: Ideal Stack Machine Instruction Set franck.bensusan@gmail.com - 2017-01-13 06:29 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-13 14:52 +0000
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-14 12:23 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-12 15:47 +0100
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-12 15:09 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-12 20:23 +0100
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-12 21:21 +0000
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-13 03:45 +0100
Re: Ideal Stack Machine Instruction Set Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-13 02:55 -0600
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-13 14:29 +0000
Re: Ideal Stack Machine Instruction Set Bernd Linsel <bl1@gmx.com> - 2017-01-13 16:11 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-13 17:26 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-13 17:27 +0100
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-13 17:01 +0000
nt=xt? (was: Ideal Stack Machine Instruction Set) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-14 15:35 +0000
Re: nt=xt? (was: Ideal Stack Machine Instruction Set) stephen@mpeforth.com - 2017-01-14 13:58 -0800
Re: nt=xt? (was: Ideal Stack Machine Instruction Set) hughaguilar96@gmail.com - 2017-01-14 14:52 -0800
Re: nt=xt? (was: Ideal Stack Machine Instruction Set) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-15 14:00 +0000
Re: nt=xt? (was: Ideal Stack Machine Instruction Set) albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-15 16:51 +0100
Re: nt=xt? (was: Ideal Stack Machine Instruction Set) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-15 16:04 +0000
Re: nt=xt? (was: Ideal Stack Machine Instruction Set) hughaguilar96@gmail.com - 2017-01-15 13:47 -0800
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-14 12:39 +0000
Re: Ideal Stack Machine Instruction Set Matthias Trute <matthias.trute@gmail.com> - 2017-01-12 22:14 -0800
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-14 13:45 +0000
Re: Ideal Stack Machine Instruction Set franck.bensusan@gmail.com - 2017-01-14 08:51 -0800
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-14 09:23 -0800
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-14 18:02 +0000
Re: Ideal Stack Machine Instruction Set franck.bensusan@gmail.com - 2017-01-09 23:42 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 09:36 +0000
Re: Ideal Stack Machine Instruction Set franck.bensusan@gmail.com - 2017-01-10 03:55 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 13:40 +0000
Re: Ideal Stack Machine Instruction Set franck.bensusan@gmail.com - 2017-01-10 06:40 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-05 12:45 +0100
Re: Ideal Stack Machine Instruction Set Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-06 08:19 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-06 17:57 +0100
Re: Ideal Stack Machine Instruction Set mhx@iae.nl - 2017-01-08 01:34 -0800
Re: Ideal Stack Machine Instruction Set john <anon@example.com> - 2017-01-08 17:08 +0000
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-02 16:49 +0000
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2016-12-09 14:52 -0800
Re: Ideal Stack Machine Instruction Set Paul Rubin <no.email@nospam.invalid> - 2016-12-09 14:56 -0800
Re: Ideal Stack Machine Instruction Set Brad Eckert <hwfwguy@gmail.com> - 2016-12-23 13:13 -0800
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-06 06:58 -0800
Re: Ideal Stack Machine Instruction Set Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-06 09:32 -0600
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-06 09:11 -0800
Re: Ideal Stack Machine Instruction Set Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-06 12:41 -0600
Re: Ideal Stack Machine Instruction Set "Elizabeth D. Rather" <erather@forth.com> - 2017-01-06 21:31 -1000
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-07 13:28 -0800
Re: Ideal Stack Machine Instruction Set Coos Haak <htrofhc@gmail.com> - 2017-01-07 23:00 +0100
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-07 14:37 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 00:06 +0100
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-07 18:50 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 14:28 +0100
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-08 19:34 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-09 06:27 +0100
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-10 00:08 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 10:01 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-10 13:12 +0100
Re: Ideal Stack Machine Instruction Set stephen@mpeforth.com - 2017-01-08 07:23 -0800
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-08 19:41 -0800
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-09 17:41 +0000
Re: Ideal Stack Machine Instruction Set "Elizabeth D. Rather" <erather@forth.com> - 2017-01-07 18:56 -1000
TO implementation (was: Ideal Stack Machine Instruction Set) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-07 14:02 +0000
Re: TO implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-07 10:51 -0600
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-08 15:27 +0000
Re: TO implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-08 13:36 -0600
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-09 18:20 +0000
Re: TO implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-10 03:56 -0600
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-15 15:15 +0000
Re: TO implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-15 13:34 -0600
Re: TO implementation hughaguilar96@gmail.com - 2017-01-15 14:04 -0800
Re: TO implementation stephen@mpeforth.com - 2017-01-15 14:24 -0800
Re: TO implementation hughaguilar96@gmail.com - 2017-01-15 15:42 -0800
Re: TO implementation hughaguilar96@gmail.com - 2017-01-15 15:56 -0800
Re: TO implementation awegel@arcor.de (Alexander Wegel) - 2017-01-16 14:25 +0100
Re: TO implementation hughaguilar96@gmail.com - 2017-01-16 11:30 -0800
Re: TO implementation awegel@arcor.de (Alexander Wegel) - 2017-01-17 02:00 +0100
Re: TO implementation albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-17 12:59 +0100
Re: TO implementation awegel@arcor.de (Alexander Wegel) - 2017-01-17 14:38 +0100
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-17 15:47 +0000
Re: TO implementation hughaguilar96@gmail.com - 2017-01-17 10:24 -0800
Re: TO implementation hughaguilar96@gmail.com - 2017-01-16 17:02 -0800
Re: TO implementation awegel@arcor.de (Alexander Wegel) - 2017-01-17 06:00 +0100
Re: TO implementation Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-15 22:19 -0500
Re: TO implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-16 08:57 -0600
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-19 11:26 +0000
Re: TO implementation Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-19 20:49 -0500
Re: TO implementation minforth@arcor.de - 2017-01-20 00:27 -0800
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-20 12:20 +0000
Re: TO implementation Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-26 22:42 -0500
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-27 08:33 +0000
Re: TO implementation minforth@arcor.de - 2017-01-27 03:59 -0800
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-19 11:40 +0000
Re: TO implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-19 05:55 -0600
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-19 14:46 +0000
Re: TO implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-19 11:03 -0600
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-06 20:22 +0100
Re: Ideal Stack Machine Instruction Set Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-07 03:54 -0600
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-07 13:51 +0000
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-07 18:50 +0100
Re: Ideal Stack Machine Instruction Set mhx@iae.nl - 2017-01-08 02:05 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-06 17:41 +0100
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-06 09:15 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-06 18:40 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-06 20:25 +0100
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-07 14:55 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-07 18:55 +0100
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-07 19:10 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-08 01:25 +0100
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 02:17 +0100
Re: Ideal Stack Machine Instruction Set mhx@iae.nl - 2017-01-08 01:53 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 17:03 +0100
Re: Ideal Stack Machine Instruction Set Coos Haak <htrofhc@gmail.com> - 2017-01-08 17:51 +0100
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 18:30 +0100
Re: Ideal Stack Machine Instruction Set Paul Rubin <no.email@nospam.invalid> - 2017-01-08 10:51 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 20:06 +0100
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-07 15:31 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-07 18:20 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-07 18:56 +0100
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-07 19:10 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-08 01:26 +0100
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 02:06 +0100
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-06 17:23 -0800
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-07 15:37 +0000
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-08 19:34 -0800 |
| Message-ID | <2a2b3921-8d32-4982-86ae-5f80b465f944@googlegroups.com> |
| In reply to | #53852 |
On Sunday, January 8, 2017 at 6:28:36 AM UTC-7, Alexander Wegel wrote: > <hughaguilar96@gmail.com> wrote: > > > On Saturday, January 7, 2017 at 4:06:16 PM UTC-7, Alexander Wegel wrote: > > > <hughaguilar96@gmail.com> wrote: > > > > On Sat., January 7, 2017 at 12:31:57 AM UTC-7, Elizabeth D. Rather wrote: > > > > > You can, for instance, compile a normal reference to TO followed by a > > > > > normal reference to the target VALUE. In executing, TO would know how to > > > > > find the parameter field of the target and store into it, then advance > > > > > the address interpreter (or its equivalent) over the target. No > > > > > immediacy anywhere. > > > > > > > > She is not making any sense at all. TO can't find the parameter field of > > > > the target and store into it. What??? > > > > > > Non-portable, but possible when integral part of a system: > > > > > > : valiu create , does> @ ; > > > : tu r> dup cell+ >r @ >body ! ; > > > > > > This surely doesn't work when interpreting, but at least the compiled > > > version does make some sense. > > > > Those kinds of tricks, that assumed a threaded system and directly accessed > > the compiled code, were common in the 1980s with figForth etc. > > So, which Hugh should we believe: The Hugh who wrote that she's not > making any sense at all, or the Hugh that knew this has been done? > > Pfff! I know that this has been done --- I also say that it doesn't make any sense --- just because something is possible, doesn't mean that it makes sense.
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-09 06:27 +0100 |
| Message-ID | <1mzkjj1.4y8vgu1rs1nifN%awegel@arcor.de> |
| In reply to | #53881 |
<hughaguilar96@gmail.com> wrote: > On Sunday, January 8, 2017 at 6:28:36 AM UTC-7, Alexander Wegel wrote: >> <hughaguilar96@gmail.com> wrote: >> >>> On Sat., January 7, 2017 at 4:06:16 PM UTC-7, Alexander Wegel wrote: >>>> <hughaguilar96@gmail.com> wrote: >>>>> On Sat., January 7, 2017 at 12:31:57 AM UTC-7, Elizabeth D. Rather wrote: >>>>>> You can, for instance, compile a normal reference to TO followed by a >>>>>> normal reference to the target VALUE. In executing, TO would know how to >>>>>> find the parameter field of the target and store into it, then advance >>>>>> the address interpreter (or its equivalent) over the target. No >>>>>> immediacy anywhere. >>>>> >>>>> She is not making any sense at all. TO can't find the parameter field of >>>>> the target and store into it. What??? >>>> >>>> Non-portable, but possible when integral part of a system: >>>> >>>> : valiu create , does> @ ; >>>> : tu r> dup cell+ >r @ >body ! ; >>>> >>>> This surely doesn't work when interpreting, but at least the compiled >>>> version does make some sense. >>> >>> Those kinds of tricks, that assumed a threaded system and directly accessed >>> the compiled code, were common in the 1980s with figForth etc. >> >> So, which Hugh should we believe: The Hugh who wrote that she's not >> making any sense at all, or the Hugh that knew this has been done? >> >> Pfff! > > I know that this has been done --- I also say that it doesn't make any sense - > just because something is possible, doesn't mean that it makes sense. You wrote "TO can't find the parameter field of the target and store into it", now you conveniently leave it out to hide your failed attack behind some ambiguity. Pffff!
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-10 00:08 -0800 |
| Message-ID | <df8c3697-92d5-405c-bacb-1dccaa1873c3@googlegroups.com> |
| In reply to | #53886 |
On Sunday, January 8, 2017 at 10:27:35 PM UTC-7, Alexander Wegel wrote: > <hughaguilar96@gmail.com> wrote: > > > On Sunday, January 8, 2017 at 6:28:36 AM UTC-7, Alexander Wegel wrote: > >> <hughaguilar96@gmail.com> wrote: > >> > >>> On Sat., January 7, 2017 at 4:06:16 PM UTC-7, Alexander Wegel wrote: > >>>> <hughaguilar96@gmail.com> wrote: > >>>>> On Sat., January 7, 2017 at 12:31:57 AM UTC-7, Elizabeth D. Rather > wrote: > >>>>>> You can, for instance, compile a normal reference to TO followed > by a > >>>>>> normal reference to the target VALUE. In executing, TO would know > how to > >>>>>> find the parameter field of the target and store into it, then > advance > >>>>>> the address interpreter (or its equivalent) over the target. No > >>>>>> immediacy anywhere. > >>>>> > >>>>> She is not making any sense at all. TO can't find the parameter > field of > >>>>> the target and store into it. What??? > >>>> > >>>> Non-portable, but possible when integral part of a system: > >>>> > >>>> : valiu create , does> @ ; > >>>> : tu r> dup cell+ >r @ >body ! ; > >>>> > >>>> This surely doesn't work when interpreting, but at least the > compiled > >>>> version does make some sense. > >>> > >>> Those kinds of tricks, that assumed a threaded system and directly > accessed > >>> the compiled code, were common in the 1980s with figForth etc. > >> > >> So, which Hugh should we believe: The Hugh who wrote that she's not > >> making any sense at all, or the Hugh that knew this has been done? > >> > >> Pfff! > > > > I know that this has been done --- I also say that it doesn't make any sense - > > just because something is possible, doesn't mean that it makes sense. > > You wrote "TO can't find the parameter field of the target and store > into it", now you conveniently leave it out to hide your failed attack > behind some ambiguity. > > Pffff! Your method requires carnal knowledge of how the code gets compiled. Also, you have to modify the outer-interpreter so that it checks that the word after the TO is a VALUE or local variable, unless you are planning on checking this at run-time. I said before that I found it humorous how the ANS-Forth cult members would contort themselves to find some hokey way to support Elizabeth Rather's goofy pronouncements about how Forth works. I still think that she most likely doesn't know the difference between immediate and non-immediate, which is why she made this implementation defined for all of the words in the standard. Why are you pestering me with this nonsense? Are you hoping that Elizabeth Rather to appoint you to the Forth-200x committee after Stephen Pelc and his employee Peter Knaggs resign? It is my prediction for 2017 that they will resign because of the one or both of the following reasons: 1.) It is a gross violation of the rule that no company has more than one vote. 2.) Stephen Pelc is obviously trying to cripple the standard to prevent common Forth programmers from writing standard code to do things like my SYNONYM ALIAS and MACRO: words (so he can make these words VFX-specific and trap the users in vendor lock-in). Either of these reasons should be adequate to cause the Forth-200x mailing-list members abandon ship, assuming that they have as much brains as rats. I think that you and Julien Fondren are the most likely candidates for Elizabeth Rather to appoint to the Forth-200x committee. :-)
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-10 10:01 +0000 |
| Message-ID | <o52bb3$jtn$1@dont-email.me> |
| In reply to | #53919 |
On 1/10/2017 08:08, hughaguilar96@gmail.com wrote: > 1.) It is a gross violation of the rule that no company has more than > one vote. No it's not a violation (gross or otherwise). Stop hyperventilating, you'll burst a blood vessel. http://forth-standard.org/standard/members-2x. === The committee meetings are open to the public, anybody is allowed to join the committee in its deliberations. Membership of the committee is open to anybody who can attend. On attending a meeting of any kind a non-member becomes an observing member (observer). If they attend the next voting meeting, they will become a voting member of the committee, otherwise they revert to non-member status. An observer will not normally be allowed to vote, but may be allowed at the discretion of the committee. A member will be deemed to have resigned from the committee if they fail to attend two consecutive voting meetings. === -- Alex
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-10 13:12 +0100 |
| Message-ID | <1mzn0ag.glc6lkycbnraN%awegel@arcor.de> |
| In reply to | #53919 |
<hughaguilar96@gmail.com> wrote: > I still think that she most likely doesn't know > the difference between immediate and non-immediate, which is why she > made this implementation defined for all of the words in the standard. But everybody knows by now that when you write "most likely", it really means "i know it's a lie, but i hope that nobody cares enough to stop me", and when you write "i think" it doesn't mean a thing. So (a) learn how to think (b) (important!) practice reading (c) get a mofo therapy
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com |
|---|---|
| Date | 2017-01-08 07:23 -0800 |
| Message-ID | <843b174c-1faf-4f98-b9c3-a48a60dce438@googlegroups.com> |
| In reply to | #53839 |
> Most likely, Elizabeth Rather doesn't know the difference between immediate and non-immediate words --- > this is why ANS-Forth doesn't specify the standard words as being immediate or non-immediate, but leaves > this as "implementation defined" which is another word for "ambiguous" --- the result is bizarre > implementations such as VFX in which words such as IF are non-immediate but are special-cased by > COMPILE, to execute at compile-time like immediate words. Do try to keep up. I've discussed this many times before. ANS and Forth-2012 permit words to have separate interpretation and compilation actions. VFX actually allows you to set these. ANS and Forth-2012 have no word or easy way to determine whether a word is IMMEDIATE, so it really doesn't matter whether IF is IMMEDIATE or not unless you write code that assumes that IF is IMMEDIATE. IMMEDIATE is for the moment a word to say that the compilation action of a word is the same as the interpretation action. IMHO the description of compilation and interpretation in the Forth-2012 standard is broken. Stephen
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-08 19:41 -0800 |
| Message-ID | <3f46ae56-ad84-4f2e-8907-916d2e20fdd6@googlegroups.com> |
| In reply to | #53854 |
On Sunday, January 8, 2017 at 8:24:00 AM UTC-7, ste...@mpeforth.com wrote: > > Most likely, Elizabeth Rather doesn't know the difference between immediate and non-immediate words --- > > this is why ANS-Forth doesn't specify the standard words as being immediate or non-immediate, but leaves > > this as "implementation defined" which is another word for "ambiguous" --- the result is bizarre > > implementations such as VFX in which words such as IF are non-immediate but are special-cased by > > COMPILE, to execute at compile-time like immediate words. > > Do try to keep up. I've discussed this many times before. ANS and Forth-2012 permit words to have > separate interpretation and compilation actions. VFX actually allows you to set these. ANS and Forth-2012 > have no word or easy way to determine whether a word is IMMEDIATE, so it really doesn't matter whether > IF is IMMEDIATE or not unless you write code that assumes that IF is IMMEDIATE. IMMEDIATE is > for the moment a word to say that the compilation action of a word is the same as the interpretation > action. > > IMHO the description of compilation and interpretation in the Forth-2012 standard is broken. > > Stephen You said: "Do try to keep up." LOL That is very condescending! I agree that ANS-Forth and Forth-200x are broken. Standard words should be defined as being immediate or non-immediate so there is no ambiguity with differences from one system to the next. Also, words that execute at compile-time such as IF etc. should be immediate. Are you keeping up? My disambiguifiers fix all of these problems --- include them in your next VFX release! --- you will likely get kicked off the Forth-200x committee for shining a spotlight on ANS-Forth's ambiguous issue, but don't worry about it. If you include the disambiguifiers, then you can also include SYNONYM FAST-SYNONYM ALIAS and MACRO: as well, as these require the disambiguifiers --- these are all written in ANS-Forth so they are portable to any ANS-Forth system --- or would you prefer to make them VFX-specific so you trap your customers in vendor lock-in?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-09 17:41 +0000 |
| Message-ID | <2017Jan9.184149@mips.complang.tuwien.ac.at> |
| In reply to | #53854 |
stephen@mpeforth.com writes:
>ANS and Forth-2012 permit words to have
>separate interpretation and compilation actions. VFX actually allows you to set these.
Forth-94 and -2012 describe interpretation and compilation semantics,
and words with non-traditonal combinations of these. Last I looked,
VFX did not have a way to set these, but approximated it by allowing
to change what COMPILE, does for a word. The problem with that is
that a standard COMPILE, must append the semantics represented by xt
to the current definition (the same semantics that are performed by
EXECUTE); performing the compilation semantics of the word instead is
not a correct implementation of COMPILE, in general. Fortunately for
VFX, the difference between these behaviours only plays a role for few
words, and people rarely tick and COMPILE, these words.
> ANS and Forth-2012
>have no word or easy way to determine whether a word is IMMEDIATE
FIND returns 1 if the found word is immediate, and -1 if it isn't.
Please limit the line length to about 70 chars.
- 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-01-07 18:56 -1000 |
| Message-ID | <qKadnat8vesMW-zFnZ2dnUU7-Y-dnZ2d@supernews.com> |
| In reply to | #53829 |
On 1/7/17 1:06 PM, Alexander Wegel wrote: > <hughaguilar96@gmail.com> wrote: > >> On Saturday, January 7, 2017 at 12:31:57 AM UTC-7, Elizabeth D. Rather wrote: >>> On 1/6/17 8:41 AM, Andrew Haley wrote: >>>> minforth@arcor.de wrote: >>>>> Am Freitag, 6. Januar 2017 16:32:59 UTC+1 schrieb Andrew Haley: >>>>>> minforth@arcor.de wrote: >>>>>>> >>>>>>> It's the same old story ad nauseam, to repair Forth's traditional >>>>>>> compiler directives. And it is getting worse with each invention of >>>>>>> new overloadings of TO. Already TO is overloaded 4 times: singles, >>>>>>> doubles, floats and locals. Overloading cries for boxed values and >>>>>>> OO, but.... >>>>>>> >>>>>>> What should FIND TO return then? Forbidding it is a very poor excuse >>>>>>> IMO. >>>>>> >>>>>> TO could be implemented with no special compilation semantics at all. >>>>>> >>>>>> The original implementation set a flag which was read and cleared by >>>>>> the next child of VALUE. Today's optimizing compilers are quite >>>>>> capable of turning that into a simple stored, so there's no reason for >>>>>> TO to be overloaded at all: it's just a word. >>>>> >>>>> How so ?? >>>>> It must be some IMMEDIATE version then, and NOT state-smart! >>> >>> You can, for instance, compile a normal reference to TO followed by a >>> normal reference to the target VALUE. In executing, TO would know how to >>> find the parameter field of the target and store into it, then advance >>> the address interpreter (or its equivalent) over the target. No >>> immediacy anywhere. >> >> She is not making any sense at all. TO can't find the parameter field of the >> target and store into it. What??? > > Non-portable, but possible when integral part of a system: > > : valiu create , does> @ ; > : tu r> dup cell+ >r @ >body ! ; > > This surely doesn't work when interpreting, but at least the compiled > version does make some sense. Since TO is a standard word, it is presumed to be supplied by a Standard System, and therefore does not have to be itself written in Standard Forth or have a portable implementation. The intent is for applications that *use* TO to be portable. Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-07 14:02 +0000 |
| Subject | TO implementation (was: Ideal Stack Machine Instruction Set) |
| Message-ID | <2017Jan7.150224@mips.complang.tuwien.ac.at> |
| In reply to | #53788 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>minforth@arcor.de wrote:
>> Am Freitag, 6. Januar 2017 16:32:59 UTC+1 schrieb Andrew Haley:
>>> TO could be implemented with no special compilation semantics at all.
>>>
>>> The original implementation set a flag which was read and cleared by
>>> the next child of VALUE. Today's optimizing compilers are quite
>>> capable of turning that into a simple stored, so there's no reason for
>>> TO to be overloaded at all: it's just a word.
>>
>> How so ??
>> It must be some IMMEDIATE version then, and NOT state-smart!
>
>An optimizing compiler can know exactly what TO does, and do the right
>thing accordingly. TO does not need to be IMMEDIATE or have any
>special compilation semantics.
You can also use TO interpretively. So my guess is that you are
thinking of having the flag-setting variant of TO and the
flag-reading-and-resetting variants of VALUEs, FVALUEs, and 2VALUEs
for interpretive use, and when the compiler sees these next to each
other, it generates faster code. Likewise, if it sees a VALUE,
FVALUE, 2VALUE or local without a preceding TO, it will generate just
a fetch from the location instead of doing the flag-checking.
That's possible, but the implementation appears quite complex to me;
it needs an optimization mechanism in the compiler that can handle
these words (whereas, e.g., the peephole optimizer in Gforth only
works on primitives), and rules for these combinations. Not a
simplification compared to a parsing TO.
Let's look at how different systems perform:
Gforth 0.7 has a parsing interpret/compile: TO with an IF cascade for
dealing with different target types.
The current development Gforth also has an interpret/compile: TO, but
with a more object-oriented mechanism for dealing with different
target types (each word knows how it should react to being TOd).
SwiftForth also has a parsing TO. It tries various word handlers
until one succeeds, and falls back to setting a flag (apparently for
something in SWOOP) if none succeeds; it deals with compilation
vs. interpretation with STATE-smartness (at least for values).
VFX: from what I can SEE, it does not look simple.
Let's see how they behave (I also tested the development version of
Gforth, but apart from differences in the output format, it behaves
the same way as Gforth 0.7.2, so I don't show it here):
1 value x
2 to dup x .s
Gforth 0.7 SwiftForth VFX
:2: Invalid name argument 2 2 1 <-Top ok DATA STACK
2 to >>>dup<<< x .s top
2 0000:0002
x .
Gforth 0.7 SwiftForth VFX
1 1 2
So VFX behaves like a flag-setting variant, while in SwiftForth
something between the TO and the value makes the TO behave like a noop
(actually, it seems to set a flag for some SWOOP stuff, but the value
makes no use of that).
: foo to dup x ; 3 foo .s cr x .
Gforth 0.7 SwiftForth VFX
:4: Invalid name argument 2 2 1 3 3 1 <-Top DATA STACK
: foo to >>>dup<<< [...] 1 ok top
3 0000:0003
2 0000:0002
3
This is consistent with the interpretive behaviour.
: flip to dup ; : flop x ; 4 flip flop .s cr x .
Gforth 0.7 SwiftForth
:5: Invalid name argument 2 2 1 3 3 1 4 4 1 <-Top
: flip to >>>dup<<< [...] 1 ok
VFX
Err# -402 ERR: Unconsumed operator at end of definition
-> : flip to dup ; : flop x ; 4 flip flop .s cr x .
^
So apparently in VFX TO sets a flag during compilation (probably with
a special COMPILE, behaviour (VFX's approximation of special
compilation semantics)). A value (or something else) may consume the
flag and is then COMPILE,d or EXECUTEd differently, and ";" checks
whether the flag is consumed. The flag is apparently the same as that
set during interpretation:
: bar [ to ] ;
Err# -402 ERR: Unconsumed operator at end of definition
-> : bar [ to ] ;
^
: boing [ to ] x ; ok
5 boing .s
DATA STACK
empty stack
ok
x . 5 ok
to : bla ;
Err# -402 ERR: Unconsumed operator at end of definition
-> to : bla ;
^
to : buh x ; ok
6 buh x . 6 ok
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-07 10:51 -0600 |
| Subject | Re: TO implementation |
| Message-ID | <HNCdnRmCtI0VgezFnZ2dnUU7-RHNnZ2d@supernews.com> |
| In reply to | #53809 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> >>An optimizing compiler can know exactly what TO does, and do the right >>thing accordingly. TO does not need to be IMMEDIATE or have any >>special compilation semantics. > > You can also use TO interpretively. So my guess is that you are > thinking of having the flag-setting variant of TO and the > flag-reading-and-resetting variants of VALUEs, FVALUEs, and 2VALUEs > for interpretive use, and when the compiler sees these next to each > other, it generates faster code. Likewise, if it sees a VALUE, > FVALUE, 2VALUE or local without a preceding TO, it will generate just > a fetch from the location instead of doing the flag-checking. Exactly. > That's possible, but the implementation appears quite complex to me; > it needs an optimization mechanism in the compiler that can handle > these words (whereas, e.g., the peephole optimizer in Gforth only > works on primitives), and rules for these combinations. Not a > simplification compared to a parsing TO. It doesn't *need* such an optimization: that's for systems that already have optimizing compilers. Systems that don't optimize can use the flag-setting TO. Such a scheme satisfies the needs of very small and simple systems and those of complex systems needing to generate optimal code. Either way, all the nastiness with parsing words is gone: there are no special compilation semantics. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-08 15:27 +0000 |
| Subject | Re: TO implementation |
| Message-ID | <2017Jan8.162730@mips.complang.tuwien.ac.at> |
| In reply to | #53813 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>
>>>An optimizing compiler can know exactly what TO does, and do the right
>>>thing accordingly. TO does not need to be IMMEDIATE or have any
>>>special compilation semantics.
>>
>> You can also use TO interpretively. So my guess is that you are
>> thinking of having the flag-setting variant of TO and the
>> flag-reading-and-resetting variants of VALUEs, FVALUEs, and 2VALUEs
>> for interpretive use, and when the compiler sees these next to each
>> other, it generates faster code. Likewise, if it sees a VALUE,
>> FVALUE, 2VALUE or local without a preceding TO, it will generate just
>> a fetch from the location instead of doing the flag-checking.
>
>Exactly.
>
>> That's possible, but the implementation appears quite complex to me;
>> it needs an optimization mechanism in the compiler that can handle
>> these words (whereas, e.g., the peephole optimizer in Gforth only
>> works on primitives), and rules for these combinations. Not a
>> simplification compared to a parsing TO.
>
>It doesn't *need* such an optimization: that's for systems that
>already have optimizing compilers.
My point was: Can you name an optimizing compiler that has an
optimization mechanism that supports the scheme you propose? And
would the result be simpler than the existing implementation of TO?
>Either way, all the nastiness with parsing
>words is gone: there are no special compilation semantics.
Would work for TO, IS and ACTION-OF, but you still need the nastiness
of special compilation semantics (or its even nastier approximations
STATE-smartness or "smart" COMPILE,) as long as we keep S" and S\".
So, it's no surprise that the three systems I looked at use special
compilation semantics or their approximations (STATE-smartness for
SwiftForth, "smart" COMPILE, for VFX) for implementing TO.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-08 13:36 -0600 |
| Subject | Re: TO implementation |
| Message-ID | <QeednfnuxZxQCe_FnZ2dnUU7-I3NnZ2d@supernews.com> |
| In reply to | #53856 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> >>It doesn't *need* such an optimization: that's for systems that >>already have optimizing compilers. > > My point was: Can you name an optimizing compiler that has an > optimization mechanism that supports the scheme you propose? And > would the result be simpler than the existing implementation of TO? No. Possibly, but I do not know for sure. I might experiment. >>Either way, all the nastiness with parsing >>words is gone: there are no special compilation semantics. > > Would work for TO, IS and ACTION-OF, but you still need the nastiness > of special compilation semantics (or its even nastier approximations > STATE-smartness or "smart" COMPILE,) as long as we keep S" and S\". That is true. > So, it's no surprise that the three systems I looked at use special > compilation semantics or their approximations (STATE-smartness for > SwiftForth, "smart" COMPILE, for VFX) for implementing TO. OK, but so what? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-09 18:20 +0000 |
| Subject | Re: TO implementation |
| Message-ID | <2017Jan9.192014@mips.complang.tuwien.ac.at> |
| In reply to | #53867 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Either way, all the nastiness with parsing
>>>words is gone: there are no special compilation semantics.
>>
>> Would work for TO, IS and ACTION-OF, but you still need the nastiness
>> of special compilation semantics (or its even nastier approximations
>> STATE-smartness or "smart" COMPILE,) as long as we keep S" and S\".
>
>That is true.
Well, of course we now have an alternative to S" and S\": the string
recognizer.
>> So, it's no surprise that the three systems I looked at use special
>> compilation semantics or their approximations (STATE-smartness for
>> SwiftForth, "smart" COMPILE, for VFX) for implementing TO.
>
>OK, but so what?
The scheme you outlined likely does not have an implementation
advantage over existing implementation approaches.
Does it have an advantage in behaviour? I don't think so: Gforth
reports an error if you use TO with an inappropriate followup word. I
think that's the most useful behaviour.
But let's see what cool things could be done if we treat TO and values
as normal words and lift the restrictions that they come with. E.g.:
5 value v
: foo ( ... xt -- ... ) execute v ;
7 ' drop foo . \ prints 5
7 ' to foo v . \ prints 7
Unfortunately, you now have to decide whether you want to support that
usage or "optimize" V to assume that there is no TO in front of it
(deviating from the un"optimized" behaviour).
In any case, I fail to see an advantage in your scheme. Not having
special compilation semantics for TO is nice, but your scheme seems
to have funny corner cases, too.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-10 03:56 -0600 |
| Subject | Re: TO implementation |
| Message-ID | <Vq6dnaCsC64jMunFnZ2dnUU7-U3NnZ2d@supernews.com> |
| In reply to | #53904 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Either way, all the nastiness with parsing >>>>words is gone: there are no special compilation semantics. >>> > > Well, of course we now have an alternative to S" and S\": the string > recognizer. > >>> So, it's no surprise that the three systems I looked at use special >>> compilation semantics or their approximations (STATE-smartness for >>> SwiftForth, "smart" COMPILE, for VFX) for implementing TO. >> >>OK, but so what? > > The scheme you outlined likely does not have an implementation > advantage over existing implementation approaches. That's hard to measure. But even if it doesn't that doesn't really affect the point in question, which is that special compilation semantics are unnecessary. And if we allow S" to be state-smart, the need for mechanisms other than IMMEDIATE to implement Standard Forth goes away altogether. > Does it have an advantage in behaviour? I don't think so: Gforth > reports an error if you use TO with an inappropriate followup word. > I think that's the most useful behaviour. OK. I think that's a waste of time, but each to their own. > But let's see what cool things could be done if we treat TO and values > as normal words and lift the restrictions that they come with. E.g.: No, let's not. Why would any of this be supported? The standard says it isn't. I assume there is a point to all this, but I don't know what it might be. > In any case, I fail to see an advantage in your scheme. It's not *my* scheme: it's the TO solution, genuine and original. > Not having special compilation semantics for TO is nice, but your > scheme seems to have funny corner cases, too. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-15 15:15 +0000 |
| Subject | Re: TO implementation |
| Message-ID | <2017Jan15.161523@mips.complang.tuwien.ac.at> |
| In reply to | #53924 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> The scheme you outlined likely does not have an implementation
>> advantage over existing implementation approaches.
>
>That's hard to measure.
Not really. You could just replace the existing implementation of TO
in a system for which you have the source code (e.g., Gforth) with the
proposed implementation, and do a before-after evaluation according to
various metrics, e.g., source code size, object code size, execution
time, compilation time.
>But even if it doesn't that doesn't really
>affect the point in question, which is that special compilation
>semantics are unnecessary. And if we allow S" to be state-smart, the
>need for mechanisms other than IMMEDIATE to implement Standard Forth
>goes away altogether.
Who are you and what have you done to Andrew Haley who pronounced his
dislike of STATE here many times?
While I think that Forth would be better off without special
compilation semantics and especially without its fragile
approximations such as STATE-smart words, there are a significant
number of Forth programmers and system implementors who embrace such
words and who will implement even the worst approximations such as
broken COMPILE, or STATE-smart words. So we should better do it
right.
That being said, I think we had consensus in the committee to put the
same restrictions wrt ticking and POSTPONEing on S" S\" as on TO IS
ACTION-OF, but forgot to actually pull it through. Since you are so
keen on allowing STATE-smart S", how about you making that proposal?
>> But let's see what cool things could be done if we treat TO and values
>> as normal words and lift the restrictions that they come with. E.g.:
>
>No, let's not. Why would any of this be supported? The standard says
>it isn't.
So what's the point of your implementation approach? It's probably
more complex, it does not check for errors, and all the restrictions
that allow a parsing implementation with special compilation semantics
or its STATE-smart approximation are still there (only not checked,
but still assumed to hold in "optimization"). Admittedly I don't find
lifting these restrictions useful myself.
>> In any case, I fail to see an advantage in your scheme.
>
>It's not *my* scheme: it's the TO solution, genuine and original.
Flag-setting is the original implementation, but the scheme with the
"optimizer" is yours; in particular if it does not support the features
that the original implementation supported.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-15 13:34 -0600 |
| Subject | Re: TO implementation |
| Message-ID | <nMCdneVL4t5KU-bFnZ2dnUU7-evNnZ2d@supernews.com> |
| In reply to | #54028 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>But even if it doesn't that doesn't really affect the point in >>question, which is that special compilation semantics are >>unnecessary. And if we allow S" to be state-smart, the need for >>mechanisms other than IMMEDIATE to implement Standard Forth goes >>away altogether. > > Who are you and what have you done to Andrew Haley who pronounced his > dislike of STATE here many times? STATE sucks. So do all mechanisms which cause words to behave differently depending on whether they are called by the interpeter or the compiler. I think I have been fairly consistent about this. > While I think that Forth would be better off without special > compilation semantics and especially without its fragile > approximations such as STATE-smart words, there are a significant > number of Forth programmers and system implementors who embrace such > words and who will implement even the worst approximations such as > broken COMPILE, or STATE-smart words. So we should better do it > right. Hmm. > That being said, I think we had consensus in the committee to put > the same restrictions wrt ticking and POSTPONEing on S" S\" as on TO > IS ACTION-OF, but forgot to actually pull it through. Since you are > so keen on allowing STATE-smart S", how about you making that > proposal? That an interesting possibility. >>> But let's see what cool things could be done if we treat TO and values >>> as normal words and lift the restrictions that they come with. E.g.: >> >>No, let's not. Why would any of this be supported? The standard says >>it isn't. > > So what's the point of your implementation approach? The assertion was that TO requires parsing. My counter-assertion is that it doesn't. That is all. It doesn't require parsing for basic functionality, and it doesn't require parsing for performance. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-15 14:04 -0800 |
| Subject | Re: TO implementation |
| Message-ID | <67481c83-9ddc-439f-a5f9-e49e2842e2b0@googlegroups.com> |
| In reply to | #54030 |
On Sunday, January 15, 2017 at 12:34:53 PM UTC-7, Andrew Haley wrote: > The assertion was that TO requires parsing. My counter-assertion is > that it doesn't. That is all. It doesn't require parsing for basic > functionality, and it doesn't require parsing for performance. You don't know what you are talking about! Earlier Elizabeth Rather said that TO doesn't have to be immediate and Alex Wegal came up with some contorted code to support this idiotic assertion, but his code was highly non-standard because it involved accessing the generated code at run-time. Also, it didn't work because it assumed that the word following TO was a VALUE which isn't necessarily true. TO does require parsing at compile-time (it has to be immediate to do this) so it can determine if the word following is actually a VALUE or a local variable --- this needs to be checked at compile-time --- that is the problem with having syntax, that it requires a lot of checking at compile-time to determine if the syntax is legal. VFX makes all the words in the standard that had traditionally been immediate, such as IF etc., non-immediate. This is just bizarre! I call these "fake-immediate" words --- they appear to be non-immediate, but COMPILE, special-cases them internally so they execute at compile-time like immediate words. So, you are still doing parsing at compile-time. The ANS-Forth documentation for TO (6.2.2295) says: "An ambiguous condition exists if name was not defined by VALUE." Also, (13.6.1.2295) says: "An ambiguous condition exists if name was not defined by either VALUE or (LOCAL)." So, that is the ANS-Forth solution: just define user mistakes as being an "ambiguous condition" rather than catch them at compile-time and abort with a helpful error message. That is so stupid!!! This is Elizabeth Rather's stupidity!!! BTW: The words in the standard that were traditionally immediate but are now ambiguous as to being immediate or non-immediate need to be disambiguified. The only such word that can't be disambiguified is TO because this was explicitly outlawed in the ANS-Forth document. Consequently, I have this code in my disambiguifiers: VFX? [if] : to postpone to ; immediate [then] \ The ANS-Forth document (6.2.2295) states: "An ambiguous condition exists if either POSTPONE or [COMPILE] is applied to TO." \ Disambiguifying TO does work under VFX though, so it is provided above. It may work under other ANS-Forth compilers too, although it is not ANS-Forth compliant.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com |
|---|---|
| Date | 2017-01-15 14:24 -0800 |
| Subject | Re: TO implementation |
| Message-ID | <7bfafb42-a9d1-4623-96c1-8cda489c8807@googlegroups.com> |
| In reply to | #54038 |
> TO does require parsing at compile-time (it has to be immediate to do this) > so it can determine if the word following is actually a VALUE or a local variable > --- this needs to be checked at compile-time --- that is the problem with > having syntax, that it requires a lot of checking at compile-time to determine > if the syntax is legal. > > VFX makes all the words in the standard that had traditionally been immediate, > such as IF etc., non-immediate. This is just bizarre! I call these "fake-immediate" > words --- they appear to be non-immediate, but COMPILE, special-cases them > internally so they execute at compile-time like immediate words. So, you are still > doing parsing at compile-time. The VFX version of TO neither parses nor is IMMEDIATE. There is no special-casing in COMPILE, Stephen > > The ANS-Forth documentation for TO (6.2.2295) says: > "An ambiguous condition exists if name was not defined by VALUE." > Also, (13.6.1.2295) says: > "An ambiguous condition exists if name was not defined by either VALUE or (LOCAL)." > So, that is the ANS-Forth solution: just define user mistakes as being an "ambiguous condition" rather than catch them at compile-time and abort with a helpful error message. That is so stupid!!! This is Elizabeth Rather's stupidity!!! > > BTW: The words in the standard that were traditionally immediate but are now ambiguous as to being immediate or non-immediate need to be disambiguified. The only such word that can't be disambiguified is TO because this was explicitly outlawed in the ANS-Forth document. Consequently, I have this code in my disambiguifiers: > > VFX? [if] > : to postpone to ; immediate > [then] > > \ The ANS-Forth document (6.2.2295) states: "An ambiguous condition exists if either POSTPONE or [COMPILE] is applied to TO." > \ Disambiguifying TO does work under VFX though, so it is provided above. It may work under other ANS-Forth compilers too, although it is not ANS-Forth compliant.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-15 15:42 -0800 |
| Subject | Re: TO implementation |
| Message-ID | <44887440-0938-4523-be08-01e80729cddf@googlegroups.com> |
| In reply to | #54040 |
On Sunday, January 15, 2017 at 3:24:03 PM UTC-7, ste...@mpeforth.com wrote:
> > TO does require parsing at compile-time (it has to be immediate to do this)
> > so it can determine if the word following is actually a VALUE or a local variable
> > --- this needs to be checked at compile-time --- that is the problem with
> > having syntax, that it requires a lot of checking at compile-time to determine
> > if the syntax is legal.
> >
> > VFX makes all the words in the standard that had traditionally been immediate,
> > such as IF etc., non-immediate. This is just bizarre! I call these "fake-immediate"
> > words --- they appear to be non-immediate, but COMPILE, special-cases them
> > internally so they execute at compile-time like immediate words. So, you are still
> > doing parsing at compile-time.
>
> The VFX version of TO neither parses nor is IMMEDIATE. There is no special-casing
> in COMPILE,
All of those words that were traditionally immediate (such as IF etc.), but are now ambiguous in ANS-Forth as to whether they are immediate or not, and are non-immediate in VFX have to be special-cased so they can execute at compile-time.
TO is one of them --- it is non-immediate in VFX --- but it actually executes at compile-time.
Look at this:
12345 constant ccc ok
: test 67890 to ccc ;
Err# -402 ERR: Unconsumed operator at end of definition
-> : test 67890 to ccc ;
^
ok
TO knew at compile-time that CCC was not a VALUE --- obviously, it is being special-cased at compile-time --- that is how it figures this stuff out at compile-time.
These are what I call "fake immediate" --- they appear to be non-immediate (because FIND returns -1 for them, and their xt if given to EXECUTE inside of colon word aborts rather than execute) --- but yet they are special-cased to actually execute at compile-time when they are encountered in the source-code so they can do what they do.
ANS-Forth is total crap!!! It is badly infected with ambiguity!!! All of the ANS-Forth compilers are incompatible with each other in regard to how basic aspects of Forth such as FIND work. What you are doing in VFX is totally incompatible with gForth and SwiftForth. What kind of standard is this, in which none of the standard compilers are compatible with each other? WTF???
Why are you supporting ANS-Forth when it is obviously crap? Code written to work under VFX will not work under any other ANS-Forth compiler. The programmer gets trapped in vendor lock-in to VFX --- I think vendor lock-in is the whole point of VFX doing everything in an incompatible manner --- you make a big marketing speech about how VFX is ANS-Forth compatible, but you purposely write VFX in such a manner that code that runs under VFX won't run under any other ANS-Forth compiler.
You are the worst possible person to be on the Forth-200x committee because you are financially motivated to sabotage the standard so that programs won't be compatible between standard compilers.
You are trying to intimidate me by saying things like: "Do try to keep up." This condescending talk intimidates all of the little brown-nosers who kneel in front of you on the Forth-200x mailing list --- they don't want to look like novices who can't understand, so they nod their heads up and down as if they do understand, even though it is all bullshit. Intimidation doesn't work on me though --- I know how to program in Forth (it doesn't take a big expert to know that IF etc. are supposed to be immediate) --- you can't convince me that I don't know Forth.
In regard to SYNONYM you told me to RTFM, meaning the VFX manual which describes a SYNONYM that is not written in ANS-Forth --- you were trying to trap me in vendor lock-in by convincing me that SYNONYM can't be written in ANS-Forth --- I made you look stupid by writing SYNONYM and ALIAS in ANS-Forth though! The disambiguifiers made this possible.
My prediction for 2017 is that you and your employee Peter Knaggs will resign from the Forth-200x committee. It is very obvious that you are trying to sabotage the standard to prevent theoretically standard code from being ported between theoretically standard compilers --- you are doing this to trap people in vendor lock-in to VFX --- you are profoundly corrupt and the worst possible person to be on the Forth-200x committee.
You can't intimidate me with your bullshit! I am going to continue to shine a spotlight on the ambiguity in ANS-Forth, and also on your effort to similarly sabotage Forth-200x.
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web