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 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
| From | Nathan Schulzke <nschulzke@gmail.com> |
|---|---|
| Date | 2016-12-09 09:25 -0800 |
| Subject | Ideal Stack Machine Instruction Set |
| Message-ID | <9ec202ed-8f32-4b76-b1a2-3cfaafbed507@googlegroups.com> |
Hey all, As a personal educational project, I decided to build a simple VM (
[toc] | [next] | [standalone]
| From | Nathan Schulzke <nschulzke@gmail.com> |
|---|---|
| Date | 2016-12-09 09:30 -0800 |
| Message-ID | <1a0be1fe-8615-4b13-a748-81bf6411db04@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 ( 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!
[toc] | [prev] | [next] | [standalone]
| From | trans <transfire@gmail.com> |
|---|---|
| Date | 2016-12-09 10:23 -0800 |
| Message-ID | <039e51f5-1854-414e-b863-6119f8925b62@googlegroups.com> |
| In reply to | #53229 |
On Friday, December 9, 2016 at 12:30:29 PM UTC-5, 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! What language are you planning to implement this in?
[toc] | [prev] | [next] | [standalone]
| From | Nathan Schulzke <nschulzke@gmail.com> |
|---|---|
| Date | 2016-12-09 16:37 -0800 |
| Message-ID | <ef2eed85-7cf8-4958-85f1-b43d7504265a@googlegroups.com> |
| In reply to | #53230 |
On Friday, December 9, 2016 at 11:23:42 AM UTC-7, trans wrote: > On Friday, December 9, 2016 at 12:30:29 PM UTC-5, 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! > > What language are you planning to implement this in? C++, simply because it's what I'm most familiar with. C would probably be more efficient, but that's not my primary concern at this point. > 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. Thank you! I'll take a look. > You might find this useful: > http://www.complang.tuwien.ac.at/anton/euroforth/ef08/papers/pelc.pdf That also looks very helpful. Thanks! :)
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-09 17:01 -0800 |
| Message-ID | <c10acf9b-edd6-46e2-a036-386582062db2@googlegroups.com> |
| In reply to | #53240 |
On Friday, December 9, 2016 at 5:37:44 PM UTC-7, Nathan Schulzke wrote: > On Friday, December 9, 2016 at 11:23:42 AM UTC-7, trans wrote: > > What language are you planning to implement this in? > > C++, simply because it's what I'm most familiar with. C would probably be more efficient, but that's not my primary concern at this point. > > > 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. > > Thank you! I'll take a look. Actually, my Stundurd is for an FPGA --- it would not be a good choice for threaded-code system on a desktop-computer. I do have my portable Forth assembler, but I haven't posted the document yet. This isn't a VM either though. This is an assembly-language that can assemble into machine-code for multiple different processors. It is similar to the 16-bit x86. The idea is that a Forth system can be written in this assembly-language --- then it can be ported to another processor by changing the assembler (the whole Forth system doesn't have to be modified at all). On some processors it is not taking advantage of all the processor's features (the PIC24 has 20 registers, for example), but on other processors it is stretching the processor's features (the 6812 doesn't have enough registers, so some of them will have to be pseudo-registers in memory). Why do you want to write a Forth system in C++ or C or any other language? This has already been done several times for C, and at least once for C++ (I have the book). For the most part, these Forth systems are slow compared to Forth systems written in assembly-language --- they are mostly useful as embedded languages --- Lua is a lot more popular as an embedded language in C programs though.
[toc] | [prev] | [next] | [standalone]
| From | Nathan Schulzke <nschulzke@gmail.com> |
|---|---|
| Date | 2016-12-10 09:07 -0800 |
| Message-ID | <730c706c-eccc-4066-b348-8423ec768d26@googlegroups.com> |
| In reply to | #53242 |
My purpose for this project is purely educational: to explore the concepts of ISA design and VMs, not to necessarily implement a particularly efficient Forth system. I chose to do a Forth-centric VM because I really like Forth. :) When I need to use Forth for a project and I care about efficiency, I'll use one of the main implementations, or write my own in assembly, for sure.
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-01-01 21:40 -0500 |
| Message-ID | <20170101214050.6f0fbba6@_> |
| In reply to | #53242 |
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 2) code is portable 3) code survives longer 4) compiler optimizations 5) foreign function interfaces 6) powerful tool chain 7) more programmers ... Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-01-01 21:06 -1000 |
| Message-ID | <Q_-dnWhaPMN0ZvTFnZ2dnUU7-cfNnZ2d@supernews.com> |
| In reply to | #53652 |
On 1/1/17 4:40 PM, Rod Pemberton wrote:
> 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:
>
We prefer writing Forth in Forth because:
> 1) easier than assembly
Check!
> 2) code is portable
Check!
> 3) code survives longer
Check!
> 4) compiler optimizations
Check!
> 5) foreign function interfaces
Check!
> 6) powerful tool chain
Check!
> 7) more programmers
Ok, there are certainly more C/C++ programmers than Forth programmers.
But our experience is that familiarity with the project domain is the
most important qualification, and programmers find Forth quite easy to
learn.
8) Forth-style interactive programming makes development times
significantly shorter and applications more reliable.
9) For embedded systems, Forth makes significantly better
utilization of limited hardware resources, enabling unit costs in
mass-produced products to be significantly lower.
Cheers,
Elizabeth
--
Elizabeth R. Conklin
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA 90045
USA
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-01-03 17:22 -0800 |
| Message-ID | <87mvf739he.fsf@nightsong.com> |
| In reply to | #53657 |
"Elizabeth D. Rather" <erather@forth.com> writes: > Ok, there are certainly more C/C++ programmers than Forth > programmers. But our experience is that familiarity with the project > domain is the most important qualification, and programmers find Forth > quite easy to learn. This is puzzling to me. Yes the language (except for a few technical corners) is very simple, but I've found learning to use it effectively to be quite difficult. That's one of the things that makes it interesting, imho. Productive Forth programmers know something that I don't, or they use different methods than what I've gotten used to / spoiled by, or whatever. It's like in the song: I was taught assembler in my second year of school, It's something like construction work, with a toothpick for a tool ...
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-01-04 10:09 +0100 |
| Message-ID | <867f6bjinx.fsf@molnjunk.nocrew.org> |
| In reply to | #53721 |
Paul Rubin wrote: > Elizabeth D. Rather wrote: >> and programmers find Forth quite easy to learn. > This is puzzling to me. Yes the language (except for a few technical > corners) is very simple, but I've found learning to use it effectively > to be quite difficult. That's one of the things that makes it > interesting, imho. Productive Forth programmers know something that I > don't I find it gets easier with practice. If you only work on small toy problems, you probably won't get far. I went through that phase, but it didn't make my a better Forth programmer. Once I worte my own metacompiler, assemblers, libraries, and other tools, it started to sink in. I think there's no way around putting in the hours. 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.
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2017-01-04 11:59 +0000 |
| Message-ID | <MPG.32d6f3ec6d5b05e89896e5@news.virginmedia.com> |
| In reply to | #53727 |
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." -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-04 10:56 -0800 |
| Message-ID | <80d3fd30-17b7-4fc5-a59e-2d2ff1e9cd71@googlegroups.com> |
| In reply to | #53729 |
On Wednesday, January 4, 2017 at 4:58:25 AM UTC-7, 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." This isn't a very good analogy. In golf the rules are fixed, so it is a matter of gaining skill within that static environment. This analogy works a lot better with C than with Forth. In Forth it is possible to write compile-time code (meta-compilers), so you make your own rules. Nobody is going to succeed at Forth if they write their programs in raw Forth --- all they are going to do is complain about the lack of features --- this is what typically happens when C programmers try to learn Forth. The problem with ANS-Forth is that Elizabeth Rather tried to turn Forth into a static environment similar to COBOL which she was familiar with. There are multiple failures to support meta-compilation: 1.) Control-flow data is on the data-stack, rather than on its own stack. A meta-compiler doesn't have access to the data-stack and has to hold its internal data somewhere else (either the return-stack or in locals) --- this is doable, but it is a hassle --- this is like making the golfers play the game with dumbbells chained to their wrists. 2.) FIND is broken, so you can't obtain xt values for most of the words in the standard. My disambiguifiers fix this problem (in practice they do; theoretically an ANS-Forth compiler could be written in which the disambiguifiers don't work). This is doable, but it is totally taboo --- Anton Ertl and Bernd Paysan have both invented disambiguifiers independently, but they both refuse to acknowledge the existence of the disambiguifiers --- most ANS-Forth programmers, if they aren't told about the disambiguifiers, will not figure out this solution on their own (it took me several years to realize the significance of the disambiguifiers). 3.) LITERAL is not vectored. A cross-compiler that uses the built-in outer-interpreter is founded upon meta-compilation, but even when you have finished you still can't support literal numbers so you still look like an idiot. This bug in ANS-Forth indirectly pulls the rug out from under the meta-compiler writer. 4.) When QUIT (which is called by ABORT and ABORT" internally) executes, the outer-interpreter does not go back to a known state. There are global variables that don't get reset to a known state. BASE is one of them. This complicates debugging significantly. This is like playing golf with a goof-ball that is weighted on one side so it tumbles chaotically. QUIT should restore the user to a known state. This problem mostly affects meta-compiler writers because their compile-time code may crash during compilation, and it may have temporarily set the word-list search path to something different than what is normally used in interpretation mode. QUIT should also save the state prior to the abort in some shadow variables so the user can examine it, which may help in determining what caused the abort. The disambiguifiers are really the key to succeeding at ANS-Forth! This allows a lot of meta-compilation to be done --- examples are SYNONYM ALIAS MACRO: (the early-binding version) and writing your own outer-interpreter --- none of this is possible without disambiguifiers. Imagine if Elizabeth Rather made a rule that all golfers have to play the game with their boots encased in buckets of concrete. Then somebody carefully read her rule book and realized that she said "boots" but didn't say "feet" --- her effort at sabotaging the game was typically incompetent (everything she does is incompetent) --- the golfers pulled their feet out of their boots and played barefoot, so they were still technically playing by her rules, but the quality of the game improved 100 times over! It is the same with ANS-Forth --- FIND was broken, but POSTPONE was not broken, so the disambiguifiers put a POSTPONE of the original word inside a new same-name word, and then suddenly FIND begins to work properly. The key to quality in ANS-Forth code is to work around the broken FIND --- the only way to succeed at Forth is by first defeating Elizabeth Rather who strives to prevent Forth meta-compiler code from being written --- she is the primary reason why Forth programmers fail to write quality code.
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-04 23:58 +0100 |
| Message-ID | <1mzcmwn.1d5l4e81yqlgziN%awegel@arcor.de> |
| In reply to | #53731 |
Oh, Hugh hijacked another thread. <hughaguilar96@gmail.com> wrote: > 1.) Control-flow data is on the data-stack, rather than on its own stack. > A meta-compiler doesn't have access to the data-stack and has to hold its > internal data somewhere else (either the return-stack or in locals) --- Not quite true. Eg: : 1: >r : r> ; 1: t.lit opc-lit t, t, ; > 2.) FIND is broken, so you can't obtain xt values for most of the words > in the standard. Pardon? Which words can't be found by FIND? I think you're confusing find with tick. > 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? > 4.) When QUIT (which is called by ABORT and ABORT" internally) executes, > the outer-interpreter does not go back to a known state. There are global > variables that don't get reset to a known state. BASE is one of them. > This complicates debugging significantly. This is like playing golf with > a goof-ball that is weighted on one side so it tumbles chaotically. Now you're exaggerating shamelessly (as usual). > QUIT should restore the user to a known state. This problem mostly > affects meta-compiler writers because their compile-time code may crash > during compilation, and it may have temporarily set the word-list search > path to something different than what is normally used in interpretation > mode. QUIT should also save the state prior to the abort in some shadow > variables so the user can examine it, which may help in determining what > caused the abort. You might also revise your exception handling strategy. Using abort or abort" for everything (as you do) just isn't good enough, exactly because you throw away the information about the nature of the exception. PS: Would you please at least learn how to break your lines properly?!
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-01-04 20:06 -0800 |
| Message-ID | <87inpu2lrx.fsf@nightsong.com> |
| In reply to | #53737 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-05 04:12 -0600 |
| Message-ID | <-fGdnQd9XqS3gfPFnZ2dnUU7-XfNnZ2d@supernews.com> |
| 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. No, really no. The fact that you can write a text interpeter in Forth is key to making this kind of thing easy. There is some unfortunate language in the standard definition of FIND which means that it is possible to have a conforming implementation in which a portable text interpreter cannot be written. However, to the best of my knowledge real implementations don't have such problems, and high-quality implementations certainly shouldn't. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-05 12:43 +0100 |
| Message-ID | <1mzdpjs.1tgkxjsje067iN%awegel@arcor.de> |
| In reply to | #53748 |
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > 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. > > No, really no. The fact that you can write a text interpeter in Forth > is key to making this kind of thing easy. > > There is some unfortunate language in the standard definition of FIND > which means that it is possible to have a conforming implementation in > which a portable text interpreter cannot be written. Do you refer to this: > For a given string, the values returned by FIND while compiling may > differ from those returned while not compiling. Find can still be used to find both variants in any state by explicitly turning the compiler on or off: : cfind state @ 0= dup >r if ] then find r> if postpone [ then ; : ifind state @ dup >r if postpone [ then find r> if ] then ; : special? dup cfind rot ifind d<> ;
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-05 16:38 +0000 |
| Message-ID | <2017Jan5.173808@mips.complang.tuwien.ac.at> |
| In reply to | #53753 |
awegel@arcor.de (Alexander Wegel) writes:
>Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>
>> 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.
>>
>> No, really no. The fact that you can write a text interpeter in Forth
>> is key to making this kind of thing easy.
>>
>> There is some unfortunate language in the standard definition of FIND
>> which means that it is possible to have a conforming implementation in
>> which a portable text interpreter cannot be written.
>
>Do you refer to this:
>
>> For a given string, the values returned by FIND while compiling may
>> differ from those returned while not compiling.
That is certainly a problematic piece of text, but 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;
So as soon as your user-defined text-interpreter using FIND
text-interprets the system-defined IF or ";", it is outside of the
standard. The workaround that Hugh Aguilar uses of actually
redefining these words (his disambiguifiers) works around this
issue.
In practice, I think that the traditional user-defined text
interpreter works on every system, including for words like IF and
";". Maybe the mention of FIND in 4.1.2 and the text you cited should
be replaced with a tighter specification, but nobody has proposed such
language in a common-practice (not very tight) kind of way. When we
discussed these issues, people wanted something quite different (some
even wanted to change what COMPILE, means), but could not find
consensus on it.
- 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 | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-05 19:17 +0100 |
| Message-ID | <1mze777.1pa8kqa1s6gl65N%awegel@arcor.de> |
| In reply to | #53763 |
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, and the standard suggests this too: > A.6.1.1550 FIND > ... > Hence the values returned by FIND may depend on STATE, and ' and ['] > may be unable to find words without interpretation semantics.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-05 18:26 +0000 |
| Message-ID | <2017Jan5.192609@mips.complang.tuwien.ac.at> |
| In reply to | #53765 |
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.
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).
>, and the standard suggests this too:
>
>> A.6.1.1550 FIND
>> ...
>> Hence the values returned by FIND may depend on STATE, and ' and [']
>> may be unable to find words without interpretation semantics.
First, appendix A is informative, not normative, and it does not
specify what value FIND returns, and does not say that this is not an
ambiguous condition.
- 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 | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-06 01:56 +0100 |
| Message-ID | <1mzebgp.dtxvh21g9n8r7N%awegel@arcor.de> |
| In reply to | #53766 |
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.
[toc] | [prev] | [next] | [standalone]
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web