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 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-05 12:45 +0100 |
| Message-ID | <1mzdq1i.1lyrbh01509rp4N%awegel@arcor.de> |
| In reply to | #53746 |
Paul Rubin <no.email@nospam.invalid> wrote: > awegel@arcor.de (Alexander Wegel) writes: > > Is there a reason to use the hosts outer interpreter but sheer laziness? > > I thought it was an important part of Forth's fiendish cleverness. Sure - i should have written "abuse".
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-06 08:19 -0800 |
| Message-ID | <412b61b0-c9d1-4c0a-af1e-af583edcccba@googlegroups.com> |
| In reply to | #53737 |
> > 3.) LITERAL is not vectored. A cross-compiler that uses the built-in > > outer-interpreter is founded upon meta-compilation, > > Using the hosts outer interpreter is better suited for meta-compiling > than it is for cross-compiling, because when cross-compiling the target > is different (maybe very different) from the host. > > Is there a reason to use the hosts outer interpreter but sheer laziness? With multiple vocabularies you can keep the most of host words and just recover needed. With some tricks, and, of course, vectored LITERAL it is possible to write a very small portion of code to retarget all to another system. After each literal processed my Forth executes DISPATCH-NUMBER vector, which is empty in normal case. For cross-compilation, last pushed number can be moved as an argument to target memory image. Btw, no ONLY-ALSO is required for this, since vocabulary hierarchy is static. This looks simple enough: PROC : [ FORTH ] CREATE CODE^ , DOES> @ KF632-LIT [ KF632 ] cmdCALL ENDPROC PROC ; FROMR RETB ENDPROC
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-06 17:57 +0100 |
| Message-ID | <1mzfyic.riyzeo1f9qstvN%awegel@arcor.de> |
| In reply to | #53782 |
Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: > > > 3.) LITERAL is not vectored. A cross-compiler that uses the built-in > > > outer-interpreter is founded upon meta-compilation, > > > > Using the hosts outer interpreter is better suited for meta-compiling > > than it is for cross-compiling, because when cross-compiling the target > > is different (maybe very different) from the host. > > > > Is there a reason to use the hosts outer interpreter but sheer laziness? > > With multiple vocabularies you can keep the most of host words and just > recover needed. With some tricks, and, of course, vectored LITERAL it is > possible to write a very small portion of code to retarget all to another > system. But the same is true when using your own outer interpreter (which is just another small piece of code), with the additional benefit that you don't need a system providing a vectored literal then.
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2017-01-08 01:34 -0800 |
| Message-ID | <301aeca5-4510-47f0-b1e8-6b73c1912d88@googlegroups.com> |
| In reply to | #53729 |
On Wednesday, January 4, 2017 at 12:58:25 PM UTC+1, john wrote: > In article <867f6bjinx.fsf@molnjunk.nocrew.org>, lars.spam@nocrew.org says... > > All the commonly dispenced advice for writing Forth programs is helpful, > > but I only started to understand it after I became more comfortable with > > Forth. > > > > Once upon a time Arnold Palmer hit a hole in one. > A bystander screamed in delight, "damn - that was lucky" > Palmer turned to him and smiled, "You know what, it's a funny > thing but the more I practice the luckier I get." That is a great quote. Let me pose a suggestive question. When your object is to write an Golf compiler in Forth, would you start by rewriting the innards of your Forth, or would you first try to become good at Golf?
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2017-01-08 17:08 +0000 |
| Message-ID | <MPG.32dc82623c2c77b39896e6@news.virginmedia.com> |
| In reply to | #53847 |
In article <301aeca5-4510-47f0-b1e8-6b73c1912d88@googlegroups.com>, mhx@iae.nl says... > > Let me pose a suggestive question. > When your object is to write an Golf compiler in > Forth, would you start by rewriting the innards of your > Forth, or would you first try to become good at Golf? > > > Well - if I understand your thrust correctly: first I'd identify that the compiler needs wriiting in the first place (that implies I already know more than a bit of golf) Then I'd look for the management tools I need to define the solution to whatever issues I've identified. And begin that. Then I'd look for what staff are available and what their skills are then maybe - just maybe - I'd be ready to look at what programming language or languages might be useful to complete the task to my specification. as things stand with my current project I'm trying to decide whether to let jack have his head and do some preliminary work in forth or to require the proof of concept work to be done in another environment entirely. As things stand I have arguaments for both. Sadly neither of which would inform my golf swing. -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-02 16:49 +0000 |
| Message-ID | <2017Jan2.174946@mips.complang.tuwien.ac.at> |
| In reply to | #53652 |
Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> writes:
>On Fri, 9 Dec 2016 17:01:44 -0800 (PST)
>hughaguilar96@gmail.com wrote:
>
>> Why do you want to write a Forth system in C++ or C or any other
>> language?
>
>My take on that is:
>
>1) easier than assembly
Not really.
>2) code is portable
Yes, that was the main motivation for doing the Gforth engine in C.
However, in the meantime the number of general-purpose platforms has
dwindled, and this is no longer that important (and we have always
used assembly language for Gforth EC).
>3) code survives longer
True.
>4) compiler optimizations
Given what the C compiler people consider "optimizations" these days,
this is the main reason for staying away from C and C++.
>5) foreign function interfaces
C is pretty bad at this. Note how long it took Gforth to get a
foreign function interface, how much effort it took, and what it
entails.
>6) powerful tool chain
Whatever may be powerful about the toolchain, it does not really help
much when developing a Forth system in my experience.
>7) more programmers
In our experience, not really. There may be more C/C++ programmers,
but they don't volunteer for contributing to an existing Forth system:
Gforth (with more Forth code portion) still has the same people on
board that it had 24 years ago; PFE (more C code portion) had two
differnt maintainers and lost both of them.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-09 14:52 -0800 |
| Message-ID | <65a2d0c6-b202-42eb-bd46-0b0a3fcd42f2@googlegroups.com> |
| In reply to | #53229 |
On Friday, December 9, 2016 at 10:30:29 AM UTC-7, Nathan Schulzke wrote: > On Friday, December 9, 2016 at 10:25:21 AM UTC-7, Nathan Schulzke wrote: > > Hey all, > > > > As a personal educational project, I decided to build a simple VM ( > > I... don't know what happened there. Restarting. > > I'm building a simple stack-based VM, and am currently working on the instruction set. Since I know that there've been several Forth machines that have been made, and you all have a lot of experience with Forth between you, I wanted to see what your thoughts were: > > 1) What would your ideal Forth-friendly instruction set look like? Which opcodes would be absolutely necessary, and which would be nice? > 2) What would the virtual hardware look like? My preliminary design has two stacks (parameter and return), and three registers (machine code PC and IR, and an IP for Forth). I'm building this with the idea of an indirect-threaded forth system, since that seems to be the easiest first step. > > I don't have a ton of experience with ISAs or VMs, and almost none with stack machines, so any feedback is appreciated! > > Thanks! This is my design: http://www.forth.org/Stundurd.txt This is an old document with a couple of mistakes, but it is pretty close --- I will upload a new document soon.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-12-09 14:56 -0800 |
| Message-ID | <874m2c4sp5.fsf@nightsong.com> |
| In reply to | #53229 |
Nathan Schulzke <nschulzke@gmail.com> writes: > What would the virtual hardware look like? My preliminary design has > two stacks (parameter and return), and three registers (machine code > PC and IR, and an IP for Forth). You might find this useful: http://www.complang.tuwien.ac.at/anton/euroforth/ef08/papers/pelc.pdf
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-12-23 13:13 -0800 |
| Message-ID | <afa8a07e-7e13-4a3e-b12a-aa624a5cb7a6@googlegroups.com> |
| In reply to | #53228 |
On Friday, December 9, 2016 at 10:25:21 AM UTC-7, Nathan Schulzke wrote: > Hey all, > > As a personal educational project, I decided to build a simple VM ( Phillip Koopman's stack machines book is a good place to start. Look Hans Bezemer's 4th, which is written in C: https://thebeez.home.xs4all.nl/4tH/ He spent a lot of time polishing it.
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-01-06 06:58 -0800 |
| Message-ID | <0dc5f2c0-8e05-4e5a-8c1e-cf08da4eec98@googlegroups.com> |
| In reply to | #53228 |
Am Freitag, 6. Januar 2017 01:56:20 UTC+1 schrieb Alexander Wegel:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>
> > awegel@arcor.de (Alexander Wegel) writes:
> > >Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> > >
> > >> the following rules
> > >> out a text interpreter as a standard program more clearly:
> > >>
> > >> |4.1.2 Ambiguous conditions
> > >> |
> > >> |attempting to obtain the execution token, (e.g., with 6.1.0070 ',
> > >> |6.1.1550 FIND, etc. of a definition with undefined interpretation
> > >> |semantics;
> > >
> > >I think FIND differs from ' and ['] in that it isn't limited to words
> > >with interpretation semantics
> >
> > Yes, in practice it works that way;
> > the extreme case is a cmForth-like
> > system where IF and ";" are only FINDable in compile state; there FIND
> > will return 0 in interpretation state, and the user-defined text
> > interpreter will report "IF undefined" or somesuch, but that will be
> > pretty much the same as the behaviour of the system-defined text
> > interpreter.
>
> I had such a system too (ansified pocketforth derivative).
>
> > Anyway, the normative text of Forth-94/2012 makes this ambiguous, so
> > by the text of the standard a standard program must not FIND the
> > system's IF (not even in compile state).
>
> I think the rationale behind these restrictions becomes clear in
> D.6.7 Immediacy, where there is an explanation why ' and ['] are not
> permitted with compiling words:
> They don't return immediacy information, just a bare execution token.
> (FIND which doesn't have that shortcoming isn't ruled out there.)
>
> The good thing is: I'm not attempting to "obtain an execution token",
> but to "obtain an execution-token + immediacy-flag pair", so the
> paragraph in 4.1.2 doesn't apply. It even makes sense this way ;D
>
> BTW: Find is ruled out in 4.1.2 in a rather generic list (starting with
> E.g., ending with etc.) while there are only ~4 candidate words in the
> whole standard (' ['] FIND SEARCH-WORDLIST) - it might be normative, but
> seems a bit huh-hasty or imprecise to me.
>
> Alex W.
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.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-06 09:32 -0600 |
| Message-ID | <pu6dnTavH7M4JfLFnZ2dnUU7-SvNnZ2d@supernews.com> |
| In reply to | #53779 |
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. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-01-06 09:11 -0800 |
| Message-ID | <a14a63ff-378c-4440-9fa3-b8c9862251b0@googlegroups.com> |
| In reply to | #53780 |
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. > > Andrew. How so ?? It must be some IMMEDIATE version then, and NOT state-smart!
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-06 12:41 -0600 |
| Message-ID | <l9CdnZs5fb9vefLFnZ2dnUU7-LGdnZ2d@supernews.com> |
| In reply to | #53785 |
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! 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. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-01-06 21:31 -1000 |
| Message-ID | <9LqdnTVLw9H1BO3FnZ2dnUU7-WfNnZ2d@supernews.com> |
| In reply to | #53788 |
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. > 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. > > Andrew. > -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-07 13:28 -0800 |
| Message-ID | <1a59eff3-aa36-4889-a9f2-c887c13fc8c3@googlegroups.com> |
| In reply to | #53801 |
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??? > > 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. The only way for this to work, is for TO to set a global variable at run-time and then to have the VALUE word test this global variable and, if it is set do a store and if it is not set do a fetch, and then clear the global variable. This is very bad design --- a whole slew of state-sensitive words --- the "Forth Way" is supposed to eschew context-sensitive words and quasi-syntax. Just get rid of TO and value altogether like I do in Straight Forth --- that is why it is called "Straight Forth" --- it is straight-forward, getting rid of ANS-Forth's goofy attempts at a C-like syntax. Elizabeth Rather introduced TO into ANS-Forth to appease the recalcitrant C programmers --- I remember when a "Forth Dimensions" article in the 1980s introduced TO as a way to set CONSTANT words to new values, and I thought that it was a bad idea then too --- just discard this nonsense!
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <htrofhc@gmail.com> |
|---|---|
| Date | 2017-01-07 23:00 +0100 |
| Message-ID | <bskt9dpnpgl1.1patfmnl5wgju.dlg@40tude.net> |
| In reply to | #53824 |
Op Sat, 7 Jan 2017 13:28:15 -0800 (PST) schreef hughaguilar96@gmail.com: > > She is not making any sense at all. TO can't find the parameter field of the target and store into it. What??? > My TO generates code that writes into the paramater field of the target. So your premise (as always) is false. groet Coos
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-07 14:37 -0800 |
| Message-ID | <a16c8b34-0597-4261-af94-26fe824ae420@googlegroups.com> |
| In reply to | #53826 |
On Saturday, January 7, 2017 at 3:01:07 PM UTC-7, Coos Haak wrote: > Op Sat, 7 Jan 2017 13:28:15 -0800 (PST) schreef hughaguilar96@gmail.com: > > > > > She is not making any sense at all. TO can't find the parameter field of the target and store into it. What??? > > > > My TO generates code that writes into the paramater field of the target. > So your premise (as always) is false. > > groet Coos You are such a brown-noser! This is what she said: On Saturday, 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. Notice the part where she said: "No immediacy anywhere." TO is typically immediate (or fake-immediate like in VFX where it appears to be non-immediate but is special-cased by COMPILE, so that it executes at compile-time like an immediate word). If TO and the VALUE word are both ordinary non-immediate words (what she means when she says: "compile a normal reference to TO followed by a normal reference to the target VALUE") then you have to use the method that I described in which a global variable is set by TO and then checked by the VALUE word so it knows whether to fetch or store. All of you ANS-Forth cult members are so quick to defend your "leading expert" --- you don't take two seconds to think about what you are saying --- none of you are making any sense whatsoever!
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-08 00:06 +0100 |
| Message-ID | <1mziar9.7na3lsqmv3xnN%awegel@arcor.de> |
| In reply to | #53824 |
<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.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-07 18:50 -0800 |
| Message-ID | <e9e5fa66-b585-47e0-8098-12f4f173bf4a@googlegroups.com> |
| In reply to | #53829 |
On Saturday, January 7, 2017 at 4:06:16 PM UTC-7, Alexander Wegel wrote: > <hughaguilar96@gmail.com> wrote: > > On Saturday, 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. --- Forth-83 largely outlawed these tricks, but they were still done in F83 etc. in which the user wasn't planning on porting his code to any other system and hence felt okay about using carnal knowledge --- no serious standard supports tricks that involve carnal knowledge of the implementation. It seems humorous to me the lengths that the ANS-Forth cult members will go to in supporting Elizabeth Rather's idiotic pronouncements --- she just makes that stuff up, with little or no thought, and without any understanding of how Forth works --- then the cult members contort themselves trying to prove that what she said was actually wise, or at least possible, rather than the pile of horse-shit that it appears to be. 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. Most C enthusiasts know more about Forth than Elizabeth Rather does --- if they have written even one Forth function, then they have written infinitely more Forth code that she has --- they aren't going to volunteer to learn Forth when they already know more about Forth than the "leading expert" on Forth.
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-08 14:28 +0100 |
| Message-ID | <1mzjdkc.pxeg6w5h00nyN%awegel@arcor.de> |
| In reply to | #53839 |
<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!
[toc] | [prev] | [next] | [standalone]
Page 5 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