Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #37787 > unrolled thread
| Started by | hughaguilar96@gmail.com |
|---|---|
| First post | 2015-03-31 15:13 -0700 |
| Last post | 2015-07-06 12:47 -0400 |
| Articles | 20 on this page of 509 — 42 participants |
Back to article view | Back to comp.lang.forth
bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-03-31 15:13 -0700
Re: bug in VFX --- IF does't work jfong@ms4.hinet.net - 2015-03-31 20:55 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-01 11:26 +0000
Re: bug in VFX --- IF does't work Jason Damisch <jasondamisch@yahoo.com> - 2015-04-01 08:39 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-01 17:35 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-12 15:18 -0700
Re: bug in VFX --- IF does't work Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-02 10:35 +0100
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-02 10:08 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-01 12:33 -0700
Re: bug in VFX --- IF does't work "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-01 22:16 -0400
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-01 13:40 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-02 17:07 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-02 19:18 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-03 06:43 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-03 10:49 -0700
Re: bug in VFX --- IF does't work beeflo <beeflobill@gmail.com> - 2015-04-03 11:17 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-04-03 14:35 -0400
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-03 19:42 +0100
Re: bug in VFX --- IF does't work jkn_gg@nicorp.f9.co.uk - 2015-04-03 14:34 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-04-03 20:52 -0400
Re: bug in VFX --- IF does't work jkn_gg@nicorp.f9.co.uk - 2015-04-04 03:47 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-04 14:07 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-04-05 00:11 -0400
Re: bug in VFX --- IF does't work jkn_gg@nicorp.f9.co.uk - 2015-04-05 08:11 -0700
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-03 23:50 +0000
Re: bug in VFX --- IF does't work Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-04 05:44 +0200
Re: bug in VFX --- IF does't work Paul Rubin <no.email@nospam.invalid> - 2015-04-03 21:32 -0700
Re: bug in VFX --- IF does't work Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-04 17:03 +0200
Re: bug in VFX --- IF does't work Paul Rubin <no.email@nospam.invalid> - 2015-04-04 21:56 -0700
Re: bug in VFX --- IF does't work Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-05 18:11 +0200
Re: bug in VFX --- IF does't work Paul Rubin <no.email@nospam.invalid> - 2015-04-05 10:13 -0700
Re: bug in VFX --- IF does't work Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-06 14:03 +0200
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-06 14:44 +0000
Re: bug in VFX --- IF does't work Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-07 11:02 +0200
Re: bug in VFX --- IF does't work Paul Rubin <no.email@nospam.invalid> - 2015-04-07 17:21 -0700
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-04-07 16:02 +0000
Re: bug in VFX --- IF does't work Paul Rubin <no.email@nospam.invalid> - 2015-04-07 11:06 -0700
Re: bug in VFX --- IF does't work Elizabeth D Rather <erather@forth.com> - 2015-04-03 18:52 -1000
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-04-05 03:54 +0000
Re: bug in VFX --- IF does't work Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-05 18:21 +0200
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-05 21:47 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-12 14:41 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-12 23:20 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-12 18:40 -0700
Re: bug in VFX --- IF does't work "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-13 04:36 -0400
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-13 23:12 -0700
Re: bug in VFX --- IF does't work "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-14 09:53 -0400
Re: bug in VFX --- IF does't work Michael Barry <barrym95838@yahoo.com> - 2015-06-14 18:38 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-15 21:03 +0100
Re: bug in VFX --- IF does't work Michael Barry <barrym95838@yahoo.com> - 2015-06-15 19:38 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-06-15 22:54 -0400
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-16 10:01 +0100
Re: bug in VFX --- IF does't work Michael Barry <barrym95838@yahoo.com> - 2015-06-16 18:25 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-17 10:11 +0100
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-06-15 22:49 -0400
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-15 21:56 -0700
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-16 00:11 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-16 07:21 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-16 19:45 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-17 10:34 +0000
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-17 08:49 -0700
Re: bug in VFX --- IF does't work mhx@iae.nl - 2015-06-17 13:50 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-17 18:36 -0700
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-17 23:44 -0700
Re: bug in VFX --- IF does't work "Elizabeth D. Rather" <erather@forth.com> - 2015-06-17 21:14 -1000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-18 00:15 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-18 09:27 +0100
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-18 02:04 -0700
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-18 03:32 -0700
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-18 04:19 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-18 12:31 +0000
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-18 05:57 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-18 12:21 +0000
Re: bug in VFX --- IF does't work "Elizabeth D. Rather" <erather@forth.com> - 2015-06-18 08:01 -1000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-18 12:11 -0700
Re: bug in VFX --- IF does't work Walter Banks <walter@bytecraft.com> - 2015-06-18 17:25 -0400
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-18 22:56 +0200
Re: bug in VFX --- IF does't work coos <chforth@hccnet.nl> - 2015-06-18 18:54 +0200
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-18 10:53 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-18 21:31 +0100
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-18 23:58 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-19 08:23 +0100
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-19 01:01 -0700
Re: bug in VFX --- IF does't work Thomas Östreicher <thomas.oestreicher@gmail.com> - 2015-06-19 01:07 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-19 09:38 +0000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-19 02:51 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-20 16:35 +0000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-20 21:28 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-20 21:33 -0700
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-20 21:49 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-21 14:01 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-21 14:19 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 13:16 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-22 16:53 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-23 15:39 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-23 18:11 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-23 22:16 +0200
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-23 23:26 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-24 03:23 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-24 08:04 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-24 14:46 +0200
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-24 13:03 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-24 15:05 +0100
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-24 14:32 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-24 14:20 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-24 20:04 +0200
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-24 16:08 +0200
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-26 08:07 +0100
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-26 08:55 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-27 00:56 +0200
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-26 18:06 +0100
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-27 01:00 +0200
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-27 11:07 +0100
Re: bug in VFX --- IF does't work Matthias Trute <matthias.trute@gmail.com> - 2015-06-27 12:04 -0700
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-27 21:14 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-20 16:26 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-20 21:55 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-21 14:26 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-22 00:29 +0100
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-22 03:24 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 07:49 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-21 21:16 -0700
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-22 02:09 -0700
Re: bug in VFX --- IF does't work "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-22 05:57 -0400
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-21 14:27 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 11:58 +0000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-19 01:04 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-20 16:17 +0000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-19 00:55 -0700
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-19 02:42 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-06-19 03:56 -0400
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-19 02:47 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-19 11:37 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-19 19:56 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-21 21:23 +0100
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 08:39 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-22 11:27 +0100
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-06-22 16:07 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-21 14:56 +0000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-19 00:40 -0700
Re: bug in VFX --- IF does't work Ron Aaron <rambamist@gmail.com> - 2015-06-19 10:55 +0300
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-21 14:43 +0000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-22 02:05 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 16:41 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-19 12:55 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-18 10:00 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-18 20:56 +0100
Re: bug in VFX --- IF does't work Hannu Vuolasaho <vuokkosetae@gmail.com> - 2015-06-19 03:13 +0300
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-19 08:37 +0100
WAS: bug in VFX... IS: More rants from Rantman of Rantland rickman <gnuarm@gmail.com> - 2015-06-18 16:33 -0400
Re: WAS: bug in VFX... IS: More rants from Rantman of Rantland "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-19 05:19 -0400
Re: WAS: bug in VFX... IS: More rants from Rantman of Rantland Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-06-19 13:38 +0100
Re: WAS: bug in VFX... IS: More rants from Rantman of Rantland rickman <gnuarm@gmail.com> - 2015-06-19 12:29 -0400
Re: WAS: bug in VFX... IS: More rants from Rantman of Rantland "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-19 17:53 -0400
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-19 12:07 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-19 12:55 +0000
The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-20 15:36 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-20 14:01 -0400
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-06-20 08:33 -1000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-06-20 21:18 -0700
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-21 13:09 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) stephen@mpeforth.com (Stephen Pelc) - 2015-06-21 14:50 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-21 23:58 +0200
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) stephen@mpeforth.com (Stephen Pelc) - 2015-06-22 10:54 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 15:52 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) stephen@mpeforth.com (Stephen Pelc) - 2015-06-22 17:08 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-23 16:43 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-22 20:19 +0200
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 08:47 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) stephen@mpeforth.com (Stephen Pelc) - 2015-06-22 13:58 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 15:37 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) stephen@mpeforth.com (Stephen Pelc) - 2015-06-22 17:02 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-23 16:29 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) stephen@mpeforth.com (Stephen Pelc) - 2015-06-23 18:18 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) Mark Wills <markwills1970@gmail.com> - 2015-06-23 00:42 -0700
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-06-22 21:47 -1000
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-23 02:42 -0700
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-23 03:38 -0700
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-06-23 12:55 +0000
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-23 06:55 -0700
Re: The meaning of xt in Forth-94 peter.m.falth@gmail.com - 2015-06-23 08:29 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-23 16:47 +0000
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-06-23 22:48 +0000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-06-24 18:13 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-06-25 13:40 +0100
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-25 06:29 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-25 08:13 -0700
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-06-25 16:33 +0000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-06-25 13:45 -0700
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-06-26 05:54 +0000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-06-27 21:08 -0700
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-26 03:44 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-26 03:52 -0700
Re: The meaning of xt in Forth-94 franck.bensusan@gmail.com - 2015-06-26 08:54 -0700
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-27 01:09 +0200
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-06-27 11:00 +0100
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-27 15:23 +0200
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-27 16:31 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-27 21:11 +0200
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-28 13:41 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-29 03:09 +0200
Re: The meaning of xt in Forth-94 mhx@iae.nl - 2015-06-27 06:42 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-06-28 13:21 +0100
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-06-26 12:20 +0100
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-12 19:43 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-28 14:09 +0000
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-28 10:21 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-28 14:26 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-29 03:21 +0200
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-30 07:14 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-01 00:33 +0200
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-04 13:58 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-05 00:18 +0200
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 07:33 +0100
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 08:28 +0100
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-07-05 12:22 +0000
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-06 16:03 +0000
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-06 18:40 +0100
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-07-06 20:36 +0000
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-07 07:18 +0100
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-07 07:17 +0000
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-06-28 19:32 -0700
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-06-28 19:32 -1000
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-06-29 15:06 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-30 07:48 +0000
Re: The meaning of xt in Forth-94 franck.bensusan@gmail.com - 2015-06-30 03:38 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-30 04:44 -0700
Re: The meaning of xt in Forth-94 franck.bensusan@gmail.com - 2015-07-01 02:49 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-01 04:43 -0700
Re: The meaning of xt in Forth-94 rickman <gnuarm@gmail.com> - 2015-07-02 02:16 -0400
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-01 23:24 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-02 00:10 -0700
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-02 01:51 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-02 12:49 +0000
Re: The meaning of xt in Forth-94 "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-02 18:02 -0400
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-04 14:31 +0000
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-30 01:55 -0700
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-01 20:32 -0700
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-07-02 02:40 -0700
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-02 22:40 -0700
Re: The meaning of xt in Forth-94 "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-03 04:32 -0400
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-03 03:03 -0700
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-07-03 03:16 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-03 22:06 +0100
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-03 22:39 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-04 14:45 +0000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-04 11:39 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-04 19:55 +0100
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-04 20:54 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 07:18 +0100
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-07-04 21:47 -1000
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 01:49 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 10:30 +0100
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 03:09 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 16:29 +0100
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 09:49 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 22:10 +0100
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-05 14:54 -0700
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-07-05 12:41 -1000
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-05 15:47 -0700
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-06 00:57 +0200
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-05 16:08 -0700
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-06 01:36 +0200
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-05 17:25 -0700
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-07-05 13:15 -1000
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-07-06 02:05 -0700
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-05 19:46 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-06 07:57 +0000
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-06 18:53 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-07 07:37 +0000
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-08 05:18 +0000
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-08 07:59 +0100
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-08 12:06 -0700
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-08 20:08 -0700
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-09 08:31 +0100
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-09 14:06 +0100
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-09 14:09 +0100
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-09 13:34 -0700
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-10 20:27 +0100
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-10 12:46 -0700
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-10 21:48 +0100
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-08 17:02 +0200
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-08 17:48 +0100
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-08 20:58 +0200
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-08 20:19 +0100
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-08 21:48 +0200
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-09 00:47 +0100
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-09 04:56 +0000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-11 14:34 -0700
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-07 08:09 +0100
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-07 16:32 +0200
Re: The meaning of xt in Forth-94 coos <chforth@hccnet.nl> - 2015-07-07 16:43 +0200
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-07 15:16 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-07 22:14 +0200
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-08 02:06 +0000
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-07 14:57 +0000
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-07 22:51 +0100
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-07-07 13:11 -1000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-07 19:34 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-06 20:47 -0700
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-06 21:55 -0700
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-07-05 08:53 -1000
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-07-06 01:56 -0700
Re: The meaning of xt in Forth-94 "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-23 18:13 -0400
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-24 01:44 -0700
Re: The meaning of xt in Forth-94 "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-24 20:07 -0400
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-25 17:05 +0000
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-24 02:08 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-24 04:53 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-24 04:57 -0700
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-24 05:46 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-24 07:05 -0700
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-06-24 14:40 +0000
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-24 10:12 -0700
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-06-24 20:35 +0000
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-24 15:01 +0000
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-24 08:58 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-24 09:54 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-28 16:40 +0000
Re: The meaning of xt in Forth-94 "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-28 15:10 -0400
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-28 23:32 -0700
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-06-28 21:37 -1000
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-29 01:38 -0700
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-24 08:53 -0700
Re: The meaning of xt in Forth-94 "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-24 20:08 -0400
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-23 10:30 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-23 22:58 +0200
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-23 23:49 +0200
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-19 15:07 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-20 16:09 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-22 16:24 -0700
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-06-15 17:41 +0000
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-06-15 16:54 +0000
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-06-15 22:57 -0400
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-13 10:51 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-13 12:57 +0100
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-13 21:53 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-13 22:41 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-14 11:42 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-14 09:26 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-14 23:15 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-14 16:39 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-14 15:21 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-14 23:20 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-14 16:48 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-14 17:52 -0700
Re: bug in VFX --- IF does't work Doug Hoffman <glidedog@gmail.com> - 2015-06-14 21:13 -0400
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-14 20:09 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-03 10:25 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-04-03 14:43 -0400
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-03 20:14 +0100
Re: bug in VFX --- IF does't work jfong@ms4.hinet.net - 2015-04-03 23:16 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-03 20:02 +0100
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-03 20:46 +0000
Re: bug in VFX --- IF does't work krishna.myneni@ccreweb.org - 2015-04-04 06:43 -0700
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-04 17:31 +0000
Re: bug in VFX --- IF does't work krishna.myneni@ccreweb.org - 2015-04-04 15:54 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-04 21:01 -0700
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-04-06 04:48 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-04 13:57 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-04-05 00:16 -0400
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-05 10:11 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-05 14:37 -0700
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-04-06 04:52 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-05 21:58 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-06 13:56 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-06 22:22 +0200
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-06 18:09 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-07 14:30 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-07 15:43 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-10 19:55 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-11 15:51 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-11 16:25 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-12 10:22 +0000
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-12 10:48 +0000
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-12 10:53 +0000
Re: bug in VFX --- IF does't work Coos Haak <chforth@hccnet.nl> - 2015-04-12 14:18 +0200
Re: bug in VFX --- IF does't work Coos Haak <chforth@hccnet.nl> - 2015-04-12 14:35 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-13 12:36 +0000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-04-13 06:00 -0700
Re: bug in VFX --- IF does't work Coos Haak <chforth@hccnet.nl> - 2015-04-13 21:02 +0200
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-04-13 13:32 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-12 09:40 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-04-12 13:38 -0400
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-12 18:55 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-13 00:07 -0700
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-13 08:07 +0000
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-05-12 23:09 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-12 20:35 -0700
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-13 10:10 +0000
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-05-13 15:58 -0400
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-13 13:13 -0700
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-14 11:40 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-14 18:48 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-06-12 21:51 -0400
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-13 00:13 +0100
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-12 20:43 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-13 09:53 +0100
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-14 09:46 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-14 10:01 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-14 18:24 +0100
Re: bug in VFX --- IF does't work "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-14 17:17 -0400
Re: bug in VFX --- IF does't work Ron Aaron <rambamist@gmail.com> - 2015-04-13 18:08 +0300
Re: bug in VFX --- IF does't work "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-06 22:07 -0400
Re: bug in VFX --- IF does't work "Elizabeth D. Rather" <erather@forth.com> - 2015-04-06 16:44 -1000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-07 11:09 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-07 14:49 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-08 01:58 +0100
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-20 23:21 -0700
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-04-21 02:10 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-21 10:41 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-21 13:31 +0100
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-04-21 06:00 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-21 14:09 +0100
Re: bug in VFX --- IF does't work Lars Brinkhoff <lars.spam@nocrew.org> - 2015-04-22 10:59 +0200
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-22 11:41 +0000
Re: bug in VFX --- IF does't work Lars Brinkhoff <lars.spam@nocrew.org> - 2015-04-22 14:13 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 14:06 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-22 15:42 +0000
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-22 15:57 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 16:43 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-24 05:35 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-24 11:22 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-24 11:18 -0700
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-25 01:21 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-25 16:49 +0000
Re: bug in VFX --- IF does't work Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-05-03 21:07 +0100
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-05-03 23:25 +0100
Re: bug in VFX --- IF does't work gwj.nexus@gmail.com - 2015-05-05 10:53 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-05-05 19:10 +0100
Re: bug in VFX --- IF does't work Gerry <gerry@jackson9000.fsnet.co.uk> - 2015-05-06 21:41 +0100
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-05-07 11:05 +0100
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-08 11:35 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-06 14:09 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-04 03:08 +0200
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-05-04 09:23 +0100
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-04 20:32 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-06 13:26 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-06 20:00 +0200
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-06 13:24 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-08 12:07 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-05-08 18:26 +0100
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-09 01:10 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-12 16:13 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-13 00:11 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-04 16:58 +0000
Re: bug in VFX --- IF does't work gwj.nexus@gmail.com - 2015-05-05 11:24 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-06 13:13 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-24 13:11 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-25 21:05 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-21 14:06 +0100
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-22 20:05 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-23 05:57 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-23 10:50 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-24 11:59 -0700
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-05-12 23:18 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-12 20:24 -0700
Re: bug in VFX --- IF does't work "Elizabeth D. Rather" <erather@forth.com> - 2015-04-24 08:56 -1000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-24 12:09 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-24 22:29 +0100
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-06-15 17:54 +0000
Re: bug in VFX --- IF does't work Jason Damisch <jasondamisch@yahoo.com> - 2015-04-02 09:04 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-02 21:04 -0700
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-03 10:48 +0000
Re: bug in VFX --- IF does't work Hans Bezemer <the.beez.speaks@gmail.com> - 2015-04-10 17:52 +0200
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-10 16:13 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-11 16:56 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-12 09:28 -0700
Re: bug in VFX --- IF does't work Jason Damisch <jasondamisch@yahoo.com> - 2015-04-03 10:26 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-05 21:54 -0700
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-26 01:20 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-26 15:09 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-27 03:13 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-01 14:59 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-05-01 19:38 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-01 16:59 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 15:56 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-01 22:45 +0200
Re: bug in VFX --- IF does't work JennyB <jennybrien@googlemail.com> - 2015-05-02 02:58 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-05-02 11:51 +0000
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-02 12:25 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 16:45 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-05-02 19:12 +0100
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-03 16:23 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-03 15:47 -0700
Re: bug in VFX --- IF does't work Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-05-04 10:11 +0100
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-04 09:16 -0700
Re: bug in VFX --- IF does't work roman.pavlyuk.0@gmail.com - 2015-05-04 10:15 -0700
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-06-15 23:35 +0000
Re: bug in VFX --- IF does't work Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-07-02 02:31 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-07-02 17:20 +0000
Re: bug in VFX --- IF does't work Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-07-02 15:40 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-07-02 19:55 -0400
Re: bug in VFX --- IF does't work Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-07-02 19:43 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-07-02 23:08 -0400
Re: bug in VFX --- IF does't work Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-07-02 21:56 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-07-03 01:25 -0400
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-07-02 23:00 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-07-03 22:25 +0100
Re: bug in VFX --- IF does't work Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-07-03 00:50 -0700
Re: bug in VFX --- IF does't work Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-07-03 18:21 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-07-04 13:09 +0100
Re: bug in VFX --- IF does't work Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-07-04 15:01 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 08:49 +0100
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-05 15:23 +0200
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 15:56 +0100
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-07-05 12:21 -0400
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-07-06 01:45 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-07-06 12:47 -0400
Page 10 of 26 — ← Prev page 1 … 8 9 [10] 11 12 … 26 Next page →
| From | peter.m.falth@gmail.com |
|---|---|
| Date | 2015-06-23 08:29 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <89645a64-663d-40c6-aa1e-ad2ade8c9e28@googlegroups.com> |
| In reply to | #39987 |
On Tuesday, 23 June 2015 14:55:25 UTC+2, Stephen Pelc wrote: > On Tue, 23 Jun 2015 03:38:27 -0700 (PDT), Mark Wills > <markwills1970@gmail.com> wrote: > > >set-comp ( xt1 xt2 -- ) > >The compilation semantics of the word identified by xt2 shall be > >set to xt1. During compilation, FIND , tick, COMPILE, et al shall > >return xt1. > > I was "sort of" with you up to here. The idea of making FIND and ' > state-smart is going to lead to many mistakes. It is also horrible > in application usage. Several times, we have had to write simulators > for tokenised systems that can both interpret and compile command > streams. These all end up with one or more tables for token > dispatch: > > create dispatch-table > ' dotoken0 , > ' dotoken1 , > ... > > Having to have separate xts doubles the size of the table and forces > people to go through contortions to get the compilation xt, for > example > > : token, > >in @ ' , >in ! > state on ' , state off > ; > > create ugly-dispatch-table > token-pair, dotoken0 > token-pair, dotoken1 > ... > > and then there are the words with no interpretation semantics or > no compilation semantics and the systems that refuse to tick a word. > It is just so much simpler to use a system that provides a single xt > for all words. > > Here's the definition of S" in VFX Forth: > > : S" \ Comp: "ccc<quote>" -- ; Run: -- c-addr u > \ *G Describe a string. Text is taken up to the next double-quote > \ ** character. The address and length of the string are returned. > [char] " parse >syspad > ; > comp: ( xt -- ) drop postpone (s") ", discard-sinline ; > > The colong definition is the interpretation behaviour of S". > > COMP: generates a nameless word that is the compiler for the previous > (latest) word. We also have SET-COMPILER ( xt -- ) which sets xt as > the compiler of the latest word; SET-COMPILER is mostly used in > defining words. > > You really don't need much more for optimised native code systems. > What I want to emphasise is that a single xt is all that is needed, > and at times that single xt is very useful in applications as well > as in the system. > > Stephen > But what I see here is very similar to how my system is working and I have one with dual XTs! To me the comp: definitions looks like my XTC (the compilation xt) I have a different way to get there. Here it is :p s" [char] " parse postpone sliteral ;ps This is the compilation action of the word it is always created first Here is the interpretative part :r s" (s") ;r they need not be created at the same time. I have over 400 standard words defined in this way. This allows to generate native code. tick and find will always return the interpretation behavior. The only way to get the compilation xt is to postpone the word see s" A44E18 C8DD84 5 C89907 26 comp S" C8DD84 E9F223FFFF jmp (S") ok seec will show the compilation code seec s" A44E18 C8DD84 5 C89907 26 comp S" C89907 E85DDEFFFF call SETCOND C8990C 895DFC mov [ebp-4h] , ebx C8990F BB22000000 mov ebx , # 22h C89914 8D6DFC lea ebp , [ebp-4h] C89917 E8D2A477FF call PARSE C8991C E9ECFEFFFF jmp "00C8980D" ok ' s" h. C8DD84 ok : t1 postpone s" ; ok see t1 A49A9C 4086B2 5 C80000 5 normal T1 4086B2 E950128800 jmp "00C89907" ok The A49A9C is the address of the name. They are kept in a different memory region. The only way to get from an xt to the name (and the information there) is by traversing all the words in the system The fact that there are 2 XTs in the header is totally hidden from the normal use of the system colon :noname etc all works as they should. My new system I am working on (64 bit) will most probably have 3 XTs in the header. There will also be one for the tokenized code. In fact the system is today running only on the token threaded code. Regards Peter Fälth
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-23 16:47 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <2015Jun23.184750@mips.complang.tuwien.ac.at> |
| In reply to | #39987 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Tue, 23 Jun 2015 03:38:27 -0700 (PDT), Mark Wills
><markwills1970@gmail.com> wrote:
>
>>set-comp ( xt1 xt2 -- )
>>The compilation semantics of the word identified by xt2 shall be
>>set to xt1. During compilation, FIND , tick, COMPILE, et al shall
>>return xt1.
>
>I was "sort of" with you up to here. The idea of making FIND and '
>state-smart is going to lead to many mistakes.
For ', I agree.
For FIND, Gforth's FIND has produced different xts depending on STATE
for 19 years, and there have been no mistakes reported. That's
because the usual use of FIND is in user-defined text interpreters,
and for that use you actually want the xt representing the
interpretation semantics in interpret state and the xt representing
the compilation semantics in compile state. Concerning other uses of
FIND, they are rare and usually don't involve S" and friends.
>It is just so much simpler to use a system that provides a single xt
>for all words.
It's also much simpler to add than to divide, but addition won't do
when division is required.
>Here's the definition of S" in VFX Forth:
>
>: S" \ Comp: "ccc<quote>" -- ; Run: -- c-addr u
>\ *G Describe a string. Text is taken up to the next double-quote
>\ ** character. The address and length of the string are returned.
> [char] " parse >syspad
>;
>comp: ( xt -- ) drop postpone (s") ", discard-sinline ;
>
>The colong definition is the interpretation behaviour of S".
>
>COMP: generates a nameless word that is the compiler for the previous
>(latest) word. We also have SET-COMPILER ( xt -- ) which sets xt as
>the compiler of the latest word; SET-COMPILER is mostly used in
>defining words.
>
>You really don't need much more for optimised native code systems.
>What I want to emphasise is that a single xt is all that is needed,
>and at times that single xt is very useful in applications as well
>as in the system.
And here's how the single xt of S" fails in VFX; test code:
: t1 ['] s" execute ;
t1 xxx" type
: t2 ['] s" compile, ; immediate
: t3 t2 ;
t3 yyy" type
On VFX COMPILE, does not work properly for that xt:
: t1 ['] s" execute ; ok
t1 xxx" type xxx ok
: t2 ['] s" compile, ; immediate ok
: t3 t2 ;
t3 yyy" type
Err# -13 ERR: Undefined word.
-> t3 yyy" type
For comparison, this code works correctly on both Gforth and
SwiftForth:
Gforth 0.7.9_20150510, Copyright (C) 1995-2015 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
: t1 ['] s" execute ; ok
t1 xxx" type xxx ok
: t2 ['] s" compile, ; immediate ok
: t3 t2 ; ok
t3 yyy" type yyy ok
[b8:~/gforth:7697] sf
SwiftForth i386-Linux 3.4.8a 21-Jul-2013
: t1 ['] s" execute ; ok
t1 xxx" type xxx ok
: t2 ['] s" compile, ; immediate ok
: t3 t2 ; ok
t3 yyy" type yyy ok
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-23 22:48 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <5589a588.444843090@news.eternal-september.org> |
| In reply to | #39997 |
On Tue, 23 Jun 2015 16:47:50 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >>You really don't need much more for optimised native code systems. >>What I want to emphasise is that a single xt is all that is needed, >>and at times that single xt is very useful in applications as well >>as in the system. > >And here's how the single xt of S" fails in VFX; test code: That there's a bug in VFX does not negate the point I was making. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-06-24 18:13 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <51153cf4-0911-4bc1-826e-34676cdb68e2@googlegroups.com> |
| In reply to | #39997 |
On Tuesday, June 23, 2015 at 10:04:46 AM UTC-7, Anton Ertl wrote: > stephen@mpeforth.com (Stephen Pelc) writes: > >On Tue, 23 Jun 2015 03:38:27 -0700 (PDT), Mark Wills > ><markwills1970@gmail.com> wrote: > > > >>set-comp ( xt1 xt2 -- ) > >>The compilation semantics of the word identified by xt2 shall be > >>set to xt1. During compilation, FIND , tick, COMPILE, et al shall > >>return xt1. > > > >I was "sort of" with you up to here. The idea of making FIND and ' > >state-smart is going to lead to many mistakes. > > For ', I agree. > > For FIND, Gforth's FIND has produced different xts depending on STATE > for 19 years, and there have been no mistakes reported. That's > because the usual use of FIND is in user-defined text interpreters, > and for that use you actually want the xt representing the > interpretation semantics in interpret state and the xt representing > the compilation semantics in compile state. Concerning other uses of > FIND, they are rare and usually don't involve S" and friends. So, you insulted me by saying that I "better read" your paper on the evils of state-smart words --- but now you tell us that FIND in gForth is state-smart and it returns a different xt for the same look-up string depending upon what STATE is at the time that FIND is executed. WTF??? Also, FIND is non-immediate in gForth, so the only way to execute it in compilation mode is to put it inside of an immediate word. I tried this with with c" DUP" and FIND returned the same xt value whether it was executed in compilation mode or interpretation mode. I tried this again with c" IF" and FIND returned different xt values. So, apparently this weirdness only occurs with the special-case words. These are the words that say "interpretation semantics for this word is undefined" --- tick aborts on these in gForth --- my disambiguifiers are written for all of these. Anyway, none of this is ANS-Forth compliant. There is nothing in the ANS-Forth document that would hint at FIND being state-smart and returning different xt values depending upon the value of STATE at the time that FIND executes. As the teenagers would say: "That some crazy shit!" Why is gForth considered to be an ANS-Forth compiler? gForth isn't ANS-Forth compliant at all --- it is just a screwball Forth system --- you aren't even making a half-hearted attempt at ANS-Forth compliance. You are way out there on your own thinking up bizarre features that nobody would expect or would understand. gForth is not only considered to be ANS-Forth compliant, but is widely considered to be the canonical ANS-Forth system. Consider this thread: https://groups.google.com/forum/#!searchin/comp.lang.forth/lc53/comp.lang.forth/wP5nw1ClzsM/E-TV9v2y9RoJ Here my program ticked semicolon and failed under gForth (I had only tested under SwiftForth). So, Ron Aaron gave me a snarky comment to the effect that my code wasn't ANS-Forth if it didn't work under gForth. Most likely, Ron Aaron has never read the ANS-Forth document, but he just assumes that gForth is the canonical ANS-Forth implementation and that testing under gForth is all that is necessary to prove ANS-Forth compliance (false negatives are not possible, so when my program didn't work under gForth that proved that it was not ANS-Forth). But gForth isn't ANS-Forth at all! Your state-smart FIND is not even close to being ANS-Forth --- nobody would ever predict such a thing from reading the ANS-Forth document, or having experience in Forth, or just having common-sense --- this is your own goofy idea that is totally non-standard. If gForth isn't ANS-Forth compliant, then why are you considered to be an expert on ANS-Forth? Other than the fact that Leon Wagner appointed you to be the chair-person of the Forth-200x committee, what qualifications do you have in regard to ANS-Forth? You seem to be unfamiliar with ANS-Forth. Your repeated assertion that it is legal to execute IF inside of square brackets is completely untrue --- this is not ANS-Forth (the document says that interpretation semantics for IF are undefined, meaning that IF can't legally execute when STATE is zero) --- you are just making up weird features that are totally unsupported by the ANS-Forth document. Does anybody here understand that the purpose of a language standard is so programs can be portable?
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-06-25 13:40 +0100 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mmgspu$rth$1@dont-email.me> |
| In reply to | #40044 |
on 25/06/2015 02:13:55, jihj wrote: > So, you insulted me by saying that I "better read" your paper This is the Hugh publicly rejoices when Elizabeth Rather is attacked and damn well near killed, spends years of effort and millions of words attacking her and Anton Ertl and Leon Wagner and John Passiniti and any other number of people on a regular basis, and appears here to colpain of an insult when he's asked to -- gasp! -- READ A FUCKING PAPER? Speechless.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-06-25 06:29 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <6afff213-8dd4-4a02-b9a7-c5b1116bdcd3@googlegroups.com> |
| In reply to | #40047 |
On Thursday, 25 June 2015 13:40:50 UTC+1, Alex McDonald wrote: > an insult when he's asked to -- gasp! -- READ A FUCKING PAPER? Is that a paper about fucking? Where can I read this paper? Is there no end to Anton's talents? :-)
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-06-25 08:13 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <c30adaf4-0faf-4360-95f0-31fc738bf797@googlegroups.com> |
| In reply to | #40051 |
joi, 25 iunie 2015, 16:29:10 UTC+3, Mark Wills a scris: > On Thursday, 25 June 2015 13:40:50 UTC+1, Alex McDonald wrote: > > an insult when he's asked to -- gasp! -- READ A FUCKING PAPER? > > Is that a paper about fucking? Where can I read this paper? > Is there no end to Anton's talents? :-) LOL There's too much pasion in these discussions. On the other hand, I've read the paper yesterday. It strikes me the fact that my system works where Anton claims it shouldn't work. IMO the paper is too loaded with "this will not work", "that is wrong", etc. A simple system like mine seems to work perfectly. Maybe systems like gforth or VFX will not work. But systems like these are not simple. They cannot be simple when the IF is not immediate ! How can a system have an non-immediate IF? It's clear that IF and others are special cased by the outer interpreter. So, a new level of complexity is added, we have non-immediate words, immediate words and (at least) one third category of words. For such a system Anton's paper may be true. I wonder, do we need this complexity? I suppose VFX need it in order to achieve good code optimization. I don't know if gforth needs it for the same reason. Probably a code generation comparable to C compilers need this complexity.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-25 16:33 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <558c2c89.610475904@news.eternal-september.org> |
| In reply to | #40053 |
On Thu, 25 Jun 2015 08:13:18 -0700 (PDT), Raimond Dragomir <raimond.dragomir@gmail.com> wrote: >I wonder, do we need this complexity? I suppose VFX need it in order >to achieve good code optimization. I don't know if gforth needs it for >the same reason. Probably a code generation comparable to C compilers >need this complexity. The VFX code generator is certainly complex. It's all hidden inside COMPILE, which is used inside a classical Fig-Forth style interpreter loop. Each word "knows" how to compile itself. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-06-25 13:45 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <8f3d5d15-8f74-49c4-8d9d-719a721cb98f@googlegroups.com> |
| In reply to | #40054 |
On Thursday, June 25, 2015 at 9:33:51 AM UTC-7, Stephen Pelc wrote: > On Thu, 25 Jun 2015 08:13:18 -0700 (PDT), Raimond Dragomir > <raimond.dragomir@gmail.com> wrote: > > >I wonder, do we need this complexity? I suppose VFX need it in order > >to achieve good code optimization. I don't know if gforth needs it for > >the same reason. Probably a code generation comparable to C compilers > >need this complexity. > > The VFX code generator is certainly complex. It's all hidden inside > COMPILE, which is used inside a classical Fig-Forth style interpreter > loop. Each word "knows" how to compile itself. > > Stephen The complexity is not very well hidden in VFX. You have xt values that can't be executed --- they are non-executable execution tokens (?!) --- this was the bug in IF that I described at the beginning of the thread. The VFX code generator continues to work after my disambiguifiers have been put in place --- but the bug in IF that I described at the beginning of this lengthy thread gets fixed. Charles Moore came up with the idea that there would not be a monolithic compiler (such as in Pascal) that knows how to compile the language, but that each immediate word would know how to compile itself. You have betrayed this idea by making COMPILE, the monolithic compiler that special-cases dozens of words in the language. Words like IF don't know how to compile themselves, because they aren't immediate --- they are special-cased by COMPILE, that compiles them in a special-case way different from how it compiles other non-immediate words --- you are failing to remember that in Forth the only attribute a word can have is immediate or non-immediate, and you have forced your users to know a-priori that dozens of words are special-case. The whole idea of IF etc. being non-immediate is a very screwball implementation --- my disambiguifiers hide the screwiness however by making IF etc. immediate and giving these words an xt value that can be executed --- we no longer have non-executable execution tokens.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-26 05:54 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <558ce717.658233754@news.eternal-september.org> |
| In reply to | #40057 |
On Thu, 25 Jun 2015 13:45:06 -0700 (PDT), hughaguilar96@gmail.com wrote: >The complexity is not very well hidden in VFX. You have xt values that can'= >t be executed --- they are non-executable execution tokens (?!) --- this wa= >s the bug in IF that I described at the beginning of the thread. Wrong! The action of IF calls NOINTERP which performs -14 THROW. Please leasrn to use the disassembler. dis if IF ( 00409F4C E86FF5FFFF ) CALL 004094C0 NOINTERP ( 00409F51 C3 ) NEXT, ( 6 bytes, 2 instructions ) ok dis nointerp NOINTERP ( 004094C0 8D6DFC ) LEA EBP, [EBP+-04] ( 004094C3 895D00 ) MOV [EBP], EBX ( 004094C6 BBF2FFFFFF ) MOV EBX, FFFFFFF2 ( 004094CB E8989C0000 ) CALL 00413168 THROW ( 004094D0 C3 ) NEXT, ( 17 bytes, 5 instructions ) ok >Charles Moore came up with the idea that there would not be a monolithic co= >mpiler (such as in Pascal) that knows how to compile the language, but that= > each immediate word would know how to compile itself. You have betrayed th= >is idea by making COMPILE, the monolithic compiler that special-cases dozen= >s of words in the language. No. Each word's dictionary header contains a pointer to its code generator if it has one. The dictionary header is documented. All COMPILE, has to do is to check for a token stream for the word or to check for a code generator. As I have done before, I shall ignore your posts that contain abuse. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-06-27 21:08 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <e2450df3-e6ef-4cfe-b483-1e2e10db1a4d@googlegroups.com> |
| In reply to | #40058 |
On Thursday, June 25, 2015 at 10:54:36 PM UTC-7, Stephen Pelc wrote: > On Thu, 25 Jun 2015 13:45:06 -0700 (PDT), hughaguilar96@gmail.com > wrote: > > >The complexity is not very well hidden in VFX. You have xt values that can'= > >t be executed --- they are non-executable execution tokens (?!) --- this wa= > >s the bug in IF that I described at the beginning of the thread. > > Wrong! The action of IF calls NOINTERP which performs -14 THROW. > Please leasrn to use the disassembler. I said that the execution-tokens can't be executed, and you said: "Wrong!" Then you preceded to explain that when the execution-tokens are executed they abort. That is exactly what I just said! > >Charles Moore came up with the idea that there would not be a monolithic co= > >mpiler (such as in Pascal) that knows how to compile the language, but that= > > each immediate word would know how to compile itself. You have betrayed th= > >is idea by making COMPILE, the monolithic compiler that special-cases dozen= > >s of words in the language. > > No. Each word's dictionary header contains a pointer to its code > generator if it has one. The dictionary header is documented. > All COMPILE, has to do is to check for a token stream for the > word or to check for a code generator. Words like IF etc. that would normally be immediate (know how to compile themselves) are now non-immediate --- but COMPILE, in VFX treats them differently from other non-immediate words --- they are special-cased. The ANS-Forth standard is broken in that it allows such an abomination as a non-immediate IF --- whether each word in the standard is immediate or non-immediate should have been standardized, and words like IF should obviously be immediate the way that they have always been. Anyway, my disambiguifiers fix all this --- IF is now immediate and its xt can be executed at compile-time the way that any immediate word's xt can be executed at compile-time. > As I have done before, I shall ignore your posts that contain abuse. I noticed that you recently made a big public show of explicitly inviting Alex McDonald and his "partner" to EuroForth --- does this imply that you endorse him now, the way that Elizabeth Rather endorsed John Passaniti? That guy is extremely abusive, but you don't ignore him, and instead you endorse him --- apparently you are okay with abusive behavior so long as it is directed at me and not thee. lol What a hypocrite you are!
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-06-26 03:44 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <da44a962-fcd1-4269-a17e-361732bf8c5d@googlegroups.com> |
| In reply to | #40057 |
On Thursday, 25 June 2015 21:45:08 UTC+1, hughag...@gmail.com wrote: > Charles Moore came up with the idea that there would not be a monolithic compiler (such as in Pascal) that knows how to compile the language, but that each immediate word would know how to compile itself. You have betrayed this idea by making COMPILE, the monolithic compiler that special-cases dozens of words in the language. Words like IF don't know how to compile themselves, because they aren't immediate --- they are special-cased by COMPILE, that compiles them in a special-case way different from how it compiles other non-immediate words --- you are failing to remember that in Forth the only attribute a word can have is immediate or non-immediate, and you have forced your users to know a-priori that dozens of words are special-case. Things have moved on a long way since Chuck was involved. Chuck's model is excellent for a ITC compiler/system. Perfect. AFAIK chuck never got involved in an optimising compiler. When code needs to be generated, and optimised (meaning changed) on the fly, the obvious way to do it is to make each word know how to compile itself.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-06-26 03:52 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <6a9688c1-26a2-400e-8237-721403e885f3@googlegroups.com> |
| In reply to | #40064 |
vineri, 26 iunie 2015, 13:44:25 UTC+3, Mark Wills a scris: > On Thursday, 25 June 2015 21:45:08 UTC+1, hughag...@gmail.com wrote: > > Charles Moore came up with the idea that there would not be a monolithic compiler (such as in Pascal) that knows how to compile the language, but that each immediate word would know how to compile itself. You have betrayed this idea by making COMPILE, the monolithic compiler that special-cases dozens of words in the language. Words like IF don't know how to compile themselves, because they aren't immediate --- they are special-cased by COMPILE, that compiles them in a special-case way different from how it compiles other non-immediate words --- you are failing to remember that in Forth the only attribute a word can have is immediate or non-immediate, and you have forced your users to know a-priori that dozens of words are special-case. > > Things have moved on a long way since Chuck was involved. Chuck's > model is excellent for a ITC compiler/system. Perfect. AFAIK > chuck never got involved in an optimising compiler. When code needs > to be generated, and optimised (meaning changed) on the fly, the > obvious way to do it is to make each word know how to compile itself. How to compile itself and at least knowing a lot of it's "neighbors". For example, how do you compile "DUP 0= IF" as a (possibly) single machine instruction? Or an optimized "DUP <lit> < IF" where <lit> is a literal? B-) And this is just a simple peephole optimization...
[toc] | [prev] | [next] | [standalone]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2015-06-26 08:54 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <2e7f44a5-052f-4e2d-8276-07cde970e5f6@googlegroups.com> |
| In reply to | #40065 |
Le vendredi 26 juin 2015 12:52:14 UTC+2, Raimond Dragomir a écrit :
> How to compile itself and at least knowing a lot of it's "neighbors".
> For example, how do you compile "DUP 0= IF" as a (possibly) single
> machine instruction? Or an optimized "DUP <lit> < IF" where <lit> is
> a literal? B-)
> And this is just a simple peephole optimization...
I don't know for others generators, but, in Oforth, code optimization is
handled by variables that a word checks when it compiles itself.
For instance, when you compile a number, it uses 3 global variables :
- cp : code pointer.
- cpBeforePush
- cpAfterPush
Example :
: test1 { 1 }
code generated to push 1 on the stack (x86 32 ) has three parts :
0) Check if cp = cpAfterPush
Detects if the instruction before was also a push on the stack.
here no.
1) movl $1, -4(%edi)
then cpBeforePush is set to cp
2) subl $4, %edi
then cpAfterPush is set to cp.
Result is :
movl $1, -4(%edi)
subl $4, %edi
But if you compile :
: test2 { 1 2 }
1 is compiled as above.
When 2 is compiled, cp = cpAfterPush
In that case cp is set back to cpBeforePush, removing %edi (ds pointer) update
from the code.
And resulting generated code will be :
movl $1, -4(%edi)
movl $2, -8(%edi)
subl $8, %edi
instead of :
movl $1, -4(%edi)
subl $4, %edi
movl $2, -4(%edi)
subl $4, %edi
Well, that is the idea to optimize according to "neighbors".
All Oforth code optimisations work like this.
Franck
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-06-27 01:09 +0200 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mmkm0t$9me$1@dont-email.me> |
| In reply to | #40064 |
Mark Wills wrote:
> Things have moved on a long way since Chuck was involved. Chuck's
> model is excellent for a ITC compiler/system. Perfect. AFAIK
> chuck never got involved in an optimising compiler. When code needs
> to be generated, and optimised (meaning changed) on the fly, the
> obvious way to do it is to make each word know how to compile itself.
Chuck was involved, cmForth is sort-of "optimizing", since the Novix chip
could execute several simple words in parallel (e.g. a return was just one
bit set in the Novix instruction). cmForth does that by having another
vocabulary for all those compile-me versions, and in compilation, that
vocabulary is searched first.
The fallout of cmForth is spread over Forth-94, with the possibility of
dual-xt mentioned ("FIND may not return the same xt in compilation as in
interpretation state"). Also the rational of COMPILE, describes that it may
not be possible to obtain the "compilation token", which is precicely what
happens in VFX: If I do a ' EXIT in VFX, and COMPILE, it, it will not be
optimized to the one bit set in the instruction. It might not even work at
all, because EXIT might be completely unknown in the normal wordlist (it's
compile-only after all). That's the thing we discuss that some words may
not be obtained by FIND (in interpretation state) or by '.
That stuff was Chucks idea. cmForth is a pretty small and clever system,
but I think, that particular idea wasn't that bright.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-06-27 11:00 +0100 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mmls4n$e33$1@dont-email.me> |
| In reply to | #40081 |
on 27/06/2015 00:09:38, Bernd Paysan wrote:
> Mark Wills wrote:
>> Things have moved on a long way since Chuck was involved. Chuck's
>> model is excellent for a ITC compiler/system. Perfect. AFAIK
>> chuck never got involved in an optimising compiler. When code needs
>> to be generated, and optimised (meaning changed) on the fly, the
>> obvious way to do it is to make each word know how to compile itself.
>
> Chuck was involved, cmForth is sort-of "optimizing", since the Novix
> chip could execute several simple words in parallel (e.g. a return was
> just one bit set in the Novix instruction). cmForth does that by
> having another vocabulary for all those compile-me versions, and in
> compilation, that vocabulary is searched first.
>
> The fallout of cmForth is spread over Forth-94, with the possibility
> of dual-xt mentioned ("FIND may not return the same xt in compilation
> as in interpretation state"). Also the rational of COMPILE, describes
> that it may not be possible to obtain the "compilation token", which
> is precicely what happens in VFX: If I do a ' EXIT in VFX, and
> COMPILE, it, it will not be optimized to the one bit set in the
> instruction. It might not even work at all, because EXIT might be
> completely unknown in the normal wordlist (it's compile-only after
> all). That's the thing we discuss that some words may not be obtained
> by FIND (in interpretation state) or by '.
>
> That stuff was Chucks idea. cmForth is a pretty small and clever
> system, but I think, that particular idea wasn't that bright.
>
Thanks for the history. The TAOCP is a fine, seminal and important work,
but Knuth's MIX wasn't his finest hour. Sainthood especially needs tested
in the fire of facts.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-06-27 15:23 +0200 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mmm812$meq$1@dont-email.me> |
| In reply to | #40084 |
Alex McDonald wrote:
> on 27/06/2015 00:09:38, Bernd Paysan wrote:
>> The fallout of cmForth is spread over Forth-94, with the possibility
>> of dual-xt mentioned ("FIND may not return the same xt in compilation
>> as in interpretation state"). Also the rational of COMPILE, describes
>> that it may not be possible to obtain the "compilation token", which
>> is precicely what happens in VFX: If I do a ' EXIT in VFX, and
>> COMPILE, it, it will not be optimized to the one bit set in the
>> instruction.
Oops, I meant cmForth, not VFX. VFX's smart COMPILE, is the opposite and
allows to obtain the "compilation token" from the xt.
>> That stuff was Chucks idea. cmForth is a pretty small and clever
>> system, but I think, that particular idea wasn't that bright.
>
> Thanks for the history. The TAOCP is a fine, seminal and important work,
> but Knuth's MIX wasn't his finest hour. Sainthood especially needs tested
> in the fire of facts.
MIX is based on architectures in the 1960s. That's why Knuth has chosen to
rewrite TAOCP with MMIX as architecture.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-27 16:31 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <2015Jun27.183131@mips.complang.tuwien.ac.at> |
| In reply to | #40086 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Alex McDonald wrote:
>
>> on 27/06/2015 00:09:38, Bernd Paysan wrote:
>>> The fallout of cmForth is spread over Forth-94, with the possibility
>>> of dual-xt mentioned ("FIND may not return the same xt in compilation
>>> as in interpretation state"). Also the rational of COMPILE, describes
>>> that it may not be possible to obtain the "compilation token", which
>>> is precicely what happens in VFX: If I do a ' EXIT in VFX, and
>>> COMPILE, it, it will not be optimized to the one bit set in the
>>> instruction.
>
>Oops, I meant cmForth, not VFX. VFX's smart COMPILE, is the opposite and
>allows to obtain the "compilation token" from the xt.
Yes, the way to go for optimization is to put it in COMPILE,
("intelligent COMPILE,"). But the way to go for non-default
non-immediate compilation semantics (S", TO, etc.) is to put it in the
text interpreter.
There is a temptation to use the same mechanism for both purposes in
the name of simplicity, and both cmForth and VFX fell for that
(resulting in a "smart COMPILE," rather than an "intelligent COMPILE,"
for VFX), and the result is that it does not quite work as one would
like in fringe cases.
If we want simplicity, we should go for real simplicity, and get rid
of S" and friends. Or, alternatively, if you want S" and friends, be
a man and accept the complexity of having both mechanisms.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-06-27 21:11 +0200 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mmmse7$4hc$1@dont-email.me> |
| In reply to | #40090 |
Anton Ertl wrote:
> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>Alex McDonald wrote:
>>
>>> on 27/06/2015 00:09:38, Bernd Paysan wrote:
>>>> The fallout of cmForth is spread over Forth-94, with the possibility
>>>> of dual-xt mentioned ("FIND may not return the same xt in compilation
>>>> as in interpretation state"). Also the rational of COMPILE, describes
>>>> that it may not be possible to obtain the "compilation token", which
>>>> is precicely what happens in VFX: If I do a ' EXIT in VFX, and
>>>> COMPILE, it, it will not be optimized to the one bit set in the
>>>> instruction.
>>
>>Oops, I meant cmForth, not VFX. VFX's smart COMPILE, is the opposite and
>>allows to obtain the "compilation token" from the xt.
>
> Yes, the way to go for optimization is to put it in COMPILE,
> ("intelligent COMPILE,"). But the way to go for non-default
> non-immediate compilation semantics (S", TO, etc.) is to put it in the
> text interpreter.
Doing two related things differently just to make it more complex is wrong,
Forth-wrong. And when you have the ability to use SET-COMPILER, you can't
enforce any rules.
That's Forth: you can't enforce rules, but you strive for simplicity.
Simplicity might break a program here or there if the programmer wasn't
careful. Usually, the programmer went for simplicity instead for
portability, so he's expecting that.
> There is a temptation to use the same mechanism for both purposes in
> the name of simplicity,
Yes, and that's the spirit of Forth: Simplifly. There's nothing wrong with
giving in to that temptation. A simpler system is Forth-better than a more
complex system, and a slight change in the spec to achive considerably more
simplicity is a very Forthy thing to do.
> and both cmForth and VFX fell for that
> (resulting in a "smart COMPILE," rather than an "intelligent COMPILE,"
> for VFX), and the result is that it does not quite work as one would
> like in fringe cases.
"as Anton would like in fringe cases". I'm not sure that we should really
strive for making parsing words reusable in all possible circumstances.
> If we want simplicity, we should go for real simplicity, and get rid
> of S" and friends. Or, alternatively, if you want S" and friends, be
> a man and accept the complexity of having both mechanisms.
We want simplicity, that's why we are doing Forth. We do accept that
simplicity makes some things behave "not perfect". One thing many Forth
programmers know is that the spec is not always right, and very often in the
way for a good solution. As Paul Bennet reported, it's the biggest error
source in total, with 44% (while just 15% were implementation bugs).
Words like S" are originally meant for the text interpreter only - and they
work well there, regardless if you implement them STATE-smart, dual-xt or
smart COMPILE,. They are not meant to be used as factors. Moving that into
a recognizer makes this more explicit: You can't reuse a recognizer as
factor, but you at least can easily postpone these things. So object.method
in a dot parser is postponeable, while object method with a parsing object
isn't.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-28 13:41 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <2015Jun28.154104@mips.complang.tuwien.ac.at> |
| In reply to | #40094 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>Alex McDonald wrote:
>> Yes, the way to go for optimization is to put it in COMPILE,
>> ("intelligent COMPILE,"). But the way to go for non-default
>> non-immediate compilation semantics (S", TO, etc.) is to put it in the
>> text interpreter.
>
>Doing two related things differently just to make it more complex is wrong,
>Forth-wrong.
Doing two different things the same way just because it happens to
work in many cases is wrong.
>And when you have the ability to use SET-COMPILER, you can't
>enforce any rules.
We cannot and do not enforce many rules anyway. We still specify
them, and that's the basis of the guarantees we give. E.g., for
SET-COMPILER (which should better be called SET-OPTIMIZE to reduce the
probability of inadvertent misuse), if the user does not use it
correctly, COMPILE, will not work correctly (as can be seen in VFX).
>That's Forth: you can't enforce rules, but you strive for simplicity.
Yes. And having two classes of xts is not simplicity.
>> There is a temptation to use the same mechanism for both purposes in
>> the name of simplicity,
>
>Yes, and that's the spirit of Forth: Simplifly.
Increasing the complexity of the interface for a little simpliciation
in implementation is not a simplification.
If you really want to simplify, get rid of S" and friends, and make
all words either normal or immediate, and then all the internal stuff
we are discussion can be much simpler, and we have a simpler
interface.
>> If we want simplicity, we should go for real simplicity, and get rid
>> of S" and friends. Or, alternatively, if you want S" and friends, be
>> a man and accept the complexity of having both mechanisms.
>
>We want simplicity, that's why we are doing Forth. We do accept that
>simplicity makes some things behave "not perfect". One thing many Forth
>programmers know is that the spec is not always right, and very often in the
>way for a good solution. As Paul Bennet reported, it's the biggest error
>source in total, with 44% (while just 15% were implementation bugs).
In this case, if we consider where Forth-94 is a flawed specification,
it seems to me that the specification error is that Forth-94 included
S" and friends, and that it made words without interpretation
semantics. Lots of complexity in implementation and interfaces fell
out from that.
>Words like S" are originally meant for the text interpreter only - and they
>work well there, regardless if you implement them STATE-smart, dual-xt or
>smart COMPILE,. They are not meant to be used as factors.
Ok, that's a less radical simplification. But then we don't need to
tick and POSTPONE S"; we should just specify that, and also revise
FIND so that it is usable in text interpreters (and not make
guarantees beyond that).
>Moving that into
>a recognizer makes this more explicit: You can't reuse a recognizer as
>factor, but you at least can easily postpone these things. So object.method
>in a dot parser is postponeable, while object method with a parsing object
>isn't.
Yes.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
Page 10 of 26 — ← Prev page 1 … 8 9 [10] 11 12 … 26 Next page →
Back to top | Article view | comp.lang.forth
csiph-web