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-06-15 23:35 +0000 |
| Articles | 20 on this page of 325 — 39 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 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 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-23 10:30 +0000
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
Page 9 of 17 — ← Prev page 1 … 7 8 [9] 10 11 … 17 Next page →
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-06-23 06:55 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <c4826291-e45f-4a2a-8894-e460058ed79d@googlegroups.com> |
| In reply to | #39987 |
On Tuesday, 23 June 2015 13:55:25 UTC+1, 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. Have another read :-) In my post above, ' and ['] would return the "true" (for want of a better word) XT of the word being ticked. FIND would return the interpretation XT of the the word if in interpretation mode, because the chances are that's what will be directly used (i.e. passed to EXECUTE in the outer interpreter). Conversely, FIND would return the compilation XT of a word in compile mode, because it's probably going to be compiled. > Having to have separate xts doubles the size of the table and forces > people to go through contortions to get the compilation xt This is true. But what are the alternatives? I believe the following to be true: * Words have a single name; * A single word can have different behaviours depending on system state (i.e. interpreting, compiling, executing); * It may be desirable, or essential to access the different behaviour modes of a single word in order to either compile it, or execute it. * It is not possible to access all of the behaviour modes (semantics) in standard Forth code, because whilst the standard recognises their existence, it provides no tools to explicitly access them. So, I'm trying to come up with a way in which a single word can have different behaviours. The most Forthy way seems to be to write each behaviour as a separate definition(s) (factoring) and "plug them in" to the word in question. > and then there are the words with no interpretation semantics or > no compilation semantics and the systems that refuse to tick a word. I believe that systems that refuse to tick a word contravene the standard. They contravene 6.1.0070 (Forth 200x, 14.5): 6.1.0070 ' "tick" CORE ( "hspacesiname" - - xt ) Skip leading space delimiters. Parse name delimited by a space. Find name and return xt, the execution token for name. An ambiguous condition exists if name is not found. When interpreting, ' xyz EXECUTE is equivalent to xyz. ' XYZ EXECUTE cannot be "equivalent to XYZ" if ' refuses to supply an XT. Therefore, there inference (for it is not explicitly stated) is clear: A *word* must object to its being invoked in a particular state, not ancilliary words. I believe that systems that do not produce an XT for a given word violate the above. However, we shouldn't allow ourselves to get side-tracked on that! It's a QOI issue :-) > 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. > Okay, but how would I access (to say, compile) the compilation behaviour (the code after comp:)? Is there a way to do that in VFX? It occurs to me that most vendors will have come across this issue many times and have home-grown their own solutions. Mark
[toc] | [prev] | [next] | [standalone]
| 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-23 10:30 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <2015Jun23.123030@mips.complang.tuwien.ac.at> |
| In reply to | #39983 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>A name token would be a good solution, but I certainly want=20
>a tick that is optimized and fast and not derived from a name token with
>some other navigation after.
You seem to be unaware of the various costs involved in ': First, the
text interpreter has to parse, find and execute ', then ' itself has
to parse and find the ticked word, and finally has to do
NAME>INTERPRET (the "navigation after"). Let's do some benchmarking
(with gforth-fast-0.7.0):
perfex /nfs/nfstmp/anton/xxxgforthtest/c8/gcc-4.2.0/install/bin/gforth-fast-0.7.0 -e ': x 10000000 00 do S" '\'' dup" evaluate drop loop ; x bye'
This loop takes 2820 cycles per iteration on a Core 2 Duo (Wolfdale):
perfex /nfs/nfstmp/anton/xxxgforthtest/c8/gcc-4.2.0/install/bin/gforth-fast-0.7.0 -e ': x 100000000 0 do [ s" dup" find-name ]l name>int drop loop ; x bye'
This loop takes 205 cycles per iteration. That's surprisingly much,
but still only 7% of the time taken by processing "' DUP".
Why does NAME>INT take so much time? The Gforth 0.7.0 header
structure suffers from feature creep: ALIAS, COMPILE-ONLY, and
INTERPRET/COMPILE: are all reflected with some conditional processing
plus some surrounding code.
Here's data from a relatively recent Gforth version on a Core i3 (Ivy
Bridge):
2751 cycles per iteration for the first benchmark, 57 cycles per
iteration for the second one.
The ALIAS and COMPILE-ONLY conditionals are still present, and the
INTERPRET/COMPILE: stuff is covered in some other way (which might be
elegant, if it was understandable).
It's interesting that all this work is necessary, even for a word like
dup, although one of the central ideas of the new header design is to
use the xt as nt.
- 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-19 15:07 +0200 |
| Message-ID | <mm143n$6ft$1@dont-email.me> |
| In reply to | #39867 |
Anton Ertl wrote: > Somehow I think that Gforth's error message is more helpful > (unfortunately, it is not as helpful in the current development > version), and that it is also more helpful to report the error right > away rather than much later, potentially in a different context, which > may be (as in this case) confusing. Ok, fixed that, now the error message is more helpful: defer endif immediate :1: warning: redefined ENDIF with endif ok ' then is endif :2: error: Cannot tick compile-only word (try COMP' ... DROP) ' >>>then<<< is endif Backtrace: $7F261A57DBE8 throw $7F261A57EA70 name?int comp' then drop is endif ok : test if ." hello" endif ; ok true test hello ok false test ok see test : test IF s\" hello" type THEN ; ok Note that for copying semantics like that, SYNONYM was standardized. -- 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-20 16:09 +0000 |
| Message-ID | <2015Jun20.180918@mips.complang.tuwien.ac.at> |
| In reply to | #39870 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Note that for copying semantics like that, SYNONYM was standardized.
But you cannot use DEFER! (or IS) on a SYNONYM of THEN and get a
portable result. Extended example:
defer endif immediate
' then is endif
: foo if ." hello" endif ;
variable pre-endif
variable post-endif
:noname ]] 1 pre-endif +! then 1 post-endif +! [[ ; is endif
\ standardizing ]] ... [[ is left as an exercise to the reader.
: bar if ." hello" endif ;
- 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-06-22 16:24 -0700 |
| Message-ID | <ccf1992d-9379-451a-a377-6c68d907de6b@googlegroups.com> |
| In reply to | #39757 |
On Sunday, June 14, 2015 at 6:38:47 PM UTC-7, Michael Barry wrote: > On Sunday, June 14, 2015 at 6:53:21 AM UTC-7, Rod Pemberton wrote: > > [...] ... Have you tried a Forth forum > > where no one knows of you? Here, I'll help you with a plan > > of attack: > > > > Step 1) Help the NEWBs for a year or two to build up your cachet. > > Step 2) Pronounce ANS to be dead. The NEWBs won't know any better. > > Step 3) Declare your Forth to be the way of the future and provide > > some straw man arguments or other logical fallacies to prove it to > > them. They simply can't tell the difference. You're great at this > > form of misdirection. Like politics, an outrageous lie is the power > > backing all great leaders. > > Step 4) Convince your minions to go forth and spread the new prophecy. > > Step 5) Once the outside world partakes, claim your vindication. > > > > Wait. Did I mix that up? > > > > I'm not entirely sure (feigned), but those might just be the > > directions for building a cult or resurrecting Nazism ... The hallmark of a cult is to declare itself to be the standard. I'm not the one declaring myself to be standard, so I'm not building a cult. I'm okay with people doing their own thing. I wouldn't mind ANS-Forth if it was just presented as being yet-another Forth implementation --- declaring it to be the standard, especially without testing it in a reference compiler or getting any input from the Forth community, was offensive though. > I have been in private contact with Hugh regarding his project, > and it looks really promising (at least through a n00b's eyes). > I am not at liberty to discuss it, but I thought that I would > share just that small tidbit. Well, I posted my design publicly --- so you and Mark are at liberty to discuss it now if you want to. http://www.forth.org/FMITE.txt It is here: http://www.forth.org/literature.html With this description: This article describes a 16-bit Forth processor called FMITE that could be built into an FPGA. It is designed to have compact machine-code. It has support for quotations (a kind of lambda function), which Forth-200x lacks. Forth-200x's failure to support quotations makes it obsolete before it is even out the gate. My design is much more realistic to gain traction in the real world among people who understand computer-science concepts. Michael Barry has helped me a lot with my grammar and spelling. Looking at that description above I notice that I should have used "that" rather than "which" --- unfortunately, he didn't proofread the description, or he would have caught the mistake --- whenever I'm left alone with a keyboard, trouble results...
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-06-15 17:41 +0000 |
| Message-ID | <mln2nn$l5d$1@dont-email.me> |
| In reply to | #39735 |
Rod Pemberton wrote:
> Since I already know C is the "god language", why would
> I'm not entirely sure (feigned), but those might just be the
Let's try to read between the lines.
Gauche Scheme:
(define words (string-split
"Since I already know C is the \"god language\", why would
I'm not entirely sure (feigned), but those might just be the"
#/[\s"]+/))
(let1 i 3
(string-join
(map
(^(op n) (set! i (op i n)) (~ words i))
(list - * * -)
(lrange 2))))
===>
"I know I'm god"
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-06-15 16:54 +0000 |
| Message-ID | <mlmvvg$9g5$1@dont-email.me> |
| In reply to | #39717 |
Rod Pemberton wrote: > He must've gotten bored with Ms. Rather. > s/disambiguifiers/"is-not-an-actual-word-Hugh..." This pitiful wretch complains that "disambiguifiers" is not a word, but he meekly accepts "Ms.". Another who willingly licks the spittle of the cultural Marxists. -- "A woman's place is in the home." --- Wise old saying
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-06-15 22:57 -0400 |
| Message-ID | <mlo390$ftb$3@dont-email.me> |
| In reply to | #39761 |
On 6/15/2015 12:54 PM, WJ wrote: > Rod Pemberton wrote: > > >> He must've gotten bored with Ms. Rather. > >> s/disambiguifiers/"is-not-an-actual-word-Hugh..." > > This pitiful wretch complains that "disambiguifiers" is not a word, > but he meekly accepts "Ms.". > > Another who willingly licks the spittle of the cultural Marxists. We were talking so much about Hugh and I guess WJ got a little jealous... I wonder who left the gate open again at the nut house? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-13 10:51 +0000 |
| Message-ID | <557c0989.201972029@news.eternal-september.org> |
| In reply to | #39710 |
On Fri, 12 Jun 2015 18:40:17 -0700 (PDT), hughaguilar96@gmail.com wrote: >, can you explain why your SYNONYM wasn't written in ANS-Forth? --- as a me= >mber of the Forth-200x standards committee, can you tell of any purpose for= > a language standard other than portability of code? Because the action of SYNONYM is very implementation-dependent. I discussed this with several implementers. That there is one system on which SYNONYM can be written in ANS Forth does not disprove the need. You have been told this many times before, but you seem to have a desire for repetition. >Obviously this paper won't be in EuroForth --- Anton Ertl decides what gets= > in EuroForth, If you worked hard enough to buy an airline ticket to come to EuroForth, you might be surprised. Have you finished your Forth yet? 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 | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-06-13 12:57 +0100 |
| Message-ID | <mlh5p5$6v7$1@dont-email.me> |
| In reply to | #39719 |
on 13/06/2015 11:51:21, wrote: > If you worked hard enough to buy an airline ticket to come to > EuroForth, you might be surprised. I'd be surprised.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-06-13 21:53 -0700 |
| Message-ID | <81f8414b-bd50-49d9-aaf6-46911ba4a20f@googlegroups.com> |
| In reply to | #39719 |
On Saturday, June 13, 2015 at 3:51:20 AM UTC-7, Stephen Pelc wrote: > On Fri, 12 Jun 2015 18:40:17 -0700 (PDT), hughaguilar96@gmail.com > wrote: > > >, can you explain why your SYNONYM wasn't written in ANS-Forth? --- as a me= > >mber of the Forth-200x standards committee, can you tell of any purpose for= > > a language standard other than portability of code? > > Because the action of SYNONYM is very implementation-dependent. > I discussed this with several implementers. That there is one > system on which SYNONYM can be written in ANS Forth does not > disprove the need. My SYNONYM SYNONYM-FAST and ALIAS work on all ANS-Forth systems (I've tested it on VFX and gForth, but it should work on any compiler that conforms to ANS-Forth, specifically to section 4.1.2. of the document, which is where the sabotage is). My disambiguifiers disambiguify all ANS-Forth systems. This includes both VFX and gForth, despite the fact that VFX and gForth special-case the special words differently (VFX special-cases them in COMPILE, and gForth special-cases them in FIND). The ambiguity is sabotage that was artificially imposed on ANS-Forth --- ambiguity is not inherent in Forth. My disambiguifiers get rid of the ambiguity in all ANS-Forth systems across the board --- this is because only FIND but not POSTPONE is sabotaged in section 4.1.2. in the ANS-Forth document, so by using POSTPONE on every special-case word I totally work around the sabotage of FIND. Also btw, your SYNONYM has a bug in it. If you make a synonym of a word that was originally defined with CREATE and then you use >BODY on the synonym you won't get the body-address of the original word --- my ALIAS handles this situation correctly. > You have been told this many times before, but you seem to have > a desire for repetition. You ANS-Forth cult members are totally lying when you claim that there is some valid reason why FIND can't return an xt for dozens of words in the standard. The reason for this (invalid by my estimation) was to prevent cross-compilers from being written using ANS-Forth compilers --- the ANS-Forth compiler-writer (Anton Ertl) wants to be able to explain that his compiler is ANS-Forth compliant despite the fact that FIND fails on dozens of words in the standard --- this is clearly sabotage. You don't like the repetition because you don't enjoy lying --- I'm not going to drop the subject --- you are going to have to tell the same lie over and over again, even as it becomes increasingly obvious that you are lying. > >Obviously this paper won't be in EuroForth --- Anton Ertl decides what gets= > > in EuroForth, > > If you worked hard enough to buy an airline ticket to come to > EuroForth, you might be surprised. That is baloney -- Anton Ertl wrote gForth in such a way that FIND would abort on all of those special-case words --- he is truly guilty of sabotage. Anton Ertl won't acknowledge the fact that ANS-Forth can be disambiguified --- Anton Ertl won't acknowledge that I am a Forth programmer at all --- Anton Ertl is totally focused on keeping his job as the Forth-200x chairperson, which means that he is totally focused on doing what his boss Leon Wagner tells him to do. By comparison, you wrote VFX so that FIND provided an xt for the special-case words, but the xt can't be executed so it is not a valid "execution token". You also prevent an outer-interpreter from being written, because during interpretation mode (STATE is false) the outer-interpreter needs to give the xt to EXECUTE, and your EXECUTE will abort because it has been sabotaged. You won't acknowledge the fact that ANS-Forth can be disambiguified --- you won't acknowledge that I am a Forth programmer at all Both yourself and Anton Ertl have sabotage your respective compilers to prevent outer-interpreters from being written --- the difference is that you sabotaged EXECUTE to abort on some words and he sabotaged FIND to abort on some words. > Have you finished your Forth yet? I have a cross-compiler written in VFX --- it is pretty much just MFX ported from UR/Forth and retargeted for a different micro-controller --- it actually uses the built-in outer-interpreter rather than a custom outer-interpreter, but now that I know how to disambiguify ANS-Forth to allow a custom outer-interpreter to be written, I am rewriting it to use a custom outer-interpreter. Why do you ask? Do you expect me to email you the source-code? I'd be happy to do so --- the day after you email me the source-code for VFX --- oh wait, these are both closed-source commercial products, so that isn't going to happen. BTW: Using the built-in outer-interpreter works reasonably well. The major problem with this is that numbers don't work in compilation mode. For example: TARG : TEST ( -- 123 ) 123 ; This doesn't work because the 123 gets compiled into the host-computer memory rather than the target-computer memory. By comparison: TARG : TEST ( -- 123 ) [ 123 ] LITERAL ; This does work because LITERAL was defined as an immediate word in HOST mode and consequently it executes on the host-computer but works on target-computer memory. In MFX I had a short-hand version to help reduce source-code bloat: TARG : TEST ( -- 123 ) [ 123 ]L ; This is still somewhat ugly, but it was acceptable at Testra. It wasn't a big deal because they mostly used constants rather than raw numbers anyway. Also, they were building a Forth processor on a Lattice isp1048 PLD, which is difficult to do --- they weren't concerned about such a trivial issue as this --- so long as MFX had all the major features of a Forth cross-compiler, they were happy. This isn't really acceptable for a commercial cross-compiler though, which is why I'm rewriting the cross-compiler to use a custom outer-interpreter --- now that I have figured out how to disambiguify ANS-Forth to allow custom outer-interpreters to be written.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-06-13 22:41 -0700 |
| Message-ID | <c6a0eff5-a0ea-440a-ab13-710baafb198e@googlegroups.com> |
| In reply to | #39719 |
On Saturday, June 13, 2015 at 3:51:20 AM UTC-7, Stephen Pelc wrote:
> On Fri, 12 Jun 2015 18:40:17 -0700 (PDT), hughaguilar96@gmail.com
> wrote:
>
> >, can you explain why your SYNONYM wasn't written in ANS-Forth? --- as a me=
> >mber of the Forth-200x standards committee, can you tell of any purpose for=
> > a language standard other than portability of code?
>
> Because the action of SYNONYM is very implementation-dependent.
> I discussed this with several implementers. That there is one
> system on which SYNONYM can be written in ANS Forth does not
> disprove the need.
My SYNONYM SYNONYM-FAST and ALIAS work on all ANS-Forth systems (I've tested it on VFX and gForth, but it should work on any compiler that conforms to ANS-Forth, specifically to section 4.1.2. of the document, which is where the sabotage is).
My disambiguifiers disambiguify all ANS-Forth systems. This includes both VFX and gForth, despite the fact that VFX and gForth special-case the special words differently (VFX special-cases them in COMPILE, and gForth special-cases them in FIND). The ambiguity is sabotage that was artificially imposed on ANS-Forth --- ambiguity is not inherent in Forth. My disambiguifiers get rid of the ambiguity in all ANS-Forth systems across the board --- this is because only FIND but not POSTPONE is sabotaged in section 4.1.2. in the ANS-Forth document, so by using POSTPONE on every special-case word I totally work around the sabotage of FIND.
Also btw, your SYNONYM has a bug in it. If you make a synonym of a word that was originally defined with CREATE and then you use >BODY on the synonym you won't get the body-address of the original word --- my ALIAS handles this situation correctly.
> You have been told this many times before, but you seem to have
> a desire for repetition.
You ANS-Forth cult members are totally lying when you claim that there is some valid reason why FIND can't return an xt for dozens of words in the standard. The reason for this (invalid by my estimation) was to prevent cross-compilers from being written using ANS-Forth compilers --- the ANS-Forth compiler-writer (Anton Ertl) wants to be able to explain that his compiler is ANS-Forth compliant despite the fact that FIND fails on dozens of words in the standard --- this is clearly sabotage.
You don't like the repetition because you don't enjoy lying --- I'm not going to drop the subject --- you are going to have to tell the same lie over and over again, even as it becomes increasingly obvious that you are lying.
> >Obviously this paper won't be in EuroForth --- Anton Ertl decides what gets=
> > in EuroForth,
>
> If you worked hard enough to buy an airline ticket to come to
> EuroForth, you might be surprised.
That is baloney -- Anton Ertl wrote gForth in such a way that FIND would abort on all of those special-case words --- he is truly guilty of sabotage. Anton Ertl won't acknowledge the fact that ANS-Forth can be disambiguified --- Anton Ertl won't acknowledge that I am a Forth programmer at all --- Anton Ertl is totally focused on keeping his job as the Forth-200x chairperson, which means that he is totally focused on doing what his boss Leon Wagner tells him to do.
By comparison, you wrote VFX so that FIND provided an xt for the special-case words, but the xt can't be executed so it is not a valid "execution token". This doesn't prevent an outer-interpreter from being written, because these are all words that don't have intepretation semantics so they shouldn't be given to EXECUTE by the outer-interpreter anyway. Weirdly enough, some of these words are non-immediate (IF) and some are immediate (;), although all of them would have been immediate in a traditional Forth. The immediate ones do have to be given to EXECUTE by the outer-interpreter, but this seems to work:
c" ;" find ok-2
.s
DATA STACK
top
1 0000:0001
5062384 004D:3EF0
ok-2
: my-; [ ' ; ] literal execute ; immediate ok-2
: ttt ." hello" my-; ok-2
ttt hello ok-2
So you are not preventing VFX users in writing a cross-compiler --- but you are okay with Anton Ertl preventing gForth users from writing a cross-compiler --- but it doesn't matter anyway, as my disambiguifiers work around the sabotage.
> Have you finished your Forth yet?
I have a cross-compiler written in VFX --- it is pretty much just MFX ported from UR/Forth and retargeted for a different micro-controller --- it actually uses the built-in outer-interpreter rather than a custom outer-interpreter, but now that I know how to disambiguify ANS-Forth to allow a custom outer-interpreter to be written, I am rewriting it to use a custom outer-interpreter.
Why do you ask? Do you expect me to email you the source-code? I'd be happy to do so --- the day after you email me the source-code for VFX --- oh wait, these are both closed-source commercial products, so that isn't going to happen.
BTW: Using the built-in outer-interpreter works reasonably well. The major problem with this is that numbers don't work in compilation mode. For example:
TARG
: TEST ( -- 123 ) 123 ;
This doesn't work because the 123 gets compiled into the host-computer memory rather than the target-computer memory. By comparison:
TARG
: TEST ( -- 123 ) [ 123 ] LITERAL ;
This does work because LITERAL was defined as an immediate word in HOST mode and consequently it executes on the host-computer but works on target-computer memory.
In MFX I had a short-hand version to help reduce source-code bloat:
TARG
: TEST ( -- 123 ) [ 123 ]L ;
This is still somewhat ugly, but it was acceptable at Testra. It wasn't a big deal because they mostly used constants rather than raw numbers anyway. Also, they were building a Forth processor on a Lattice isp1048 PLD, which is difficult to do --- they weren't concerned about such a trivial issue as this --- so long as MFX had all the major features of a Forth cross-compiler, they were happy.
This isn't really acceptable for a commercial cross-compiler though, which is why I'm rewriting the cross-compiler to use a custom outer-interpreter --- now that I have figured out how to disambiguify ANS-Forth to allow custom outer-interpreters to be written.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-14 11:42 +0000 |
| Message-ID | <557d6684.291311275@news.eternal-september.org> |
| In reply to | #39730 |
On Sat, 13 Jun 2015 22:41:09 -0700 (PDT), hughaguilar96@gmail.com wrote: >Also btw, your SYNONYM has a bug in it. If you make a synonym of a word tha= >t was originally defined with CREATE and then you use >BODY on the synonym = >you won't get the body-address of the original word --- my ALIAS handles th= >is situation correctly.=20 VFX Forth for Windows IA32 © MicroProcessor Engineering Ltd, 1998-2015 Version: 4.72 [build 3538] Build date: 11 June 2015 Free dictionary = 7550062 bytes [7373kb] create foo 5 , 6 , ok synonym poo foo ok ' poo >body @ . 5 ok foo .dword 004C:ABC0 ok ' poo >body .dword 004C:ABC0 ok No bug to be seen. 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-14 09:26 -0700 |
| Message-ID | <4c83bf4f-cdd3-4c21-aac0-4dac17690f8c@googlegroups.com> |
| In reply to | #39733 |
On Sunday, June 14, 2015 at 4:42:48 AM UTC-7, Stephen Pelc wrote: > On Sat, 13 Jun 2015 22:41:09 -0700 (PDT), hughaguilar96@gmail.com > wrote: > > >Also btw, your SYNONYM has a bug in it. If you make a synonym of a word tha= > >t was originally defined with CREATE and then you use >BODY on the synonym = > >you won't get the body-address of the original word --- my ALIAS handles th= > >is situation correctly.=20 > > VFX Forth for Windows IA32 > © MicroProcessor Engineering Ltd, 1998-2015 > > Version: 4.72 [build 3538] > Build date: 11 June 2015 > > Free dictionary = 7550062 bytes [7373kb] > > create foo 5 , 6 , ok > synonym poo foo ok > ' poo >body @ . 5 ok > > foo .dword 004C:ABC0 ok > ' poo >body .dword 004C:ABC0 ok > > No bug to be seen. > > Stephen You are using VFX version 4.72 with a build-date of 3 days ago. This is the result I get: VFX Forth for Windows IA32 © MicroProcessor Engineering Ltd, 1998-2012 Version: 4.60 [build 3388] Build date: 24 October 2012 Free dictionary = 7562654 bytes [7385kb] create foo 5 , 6 , ok synonym poo foo ok ' poo >body @ . 5012107 ok ' foo >body @ . 5 ok locate synonym Definition found in /Kernel/Common/kernel.fth at line 5696. ok I couldn't find the Kernel/Common/ directory anywhere --- apparently it is not available in the evaluation version.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-14 23:15 +0000 |
| Message-ID | <557e0a20.333195063@news.eternal-september.org> |
| In reply to | #39738 |
On Sun, 14 Jun 2015 09:26:01 -0700 (PDT), hughaguilar96@gmail.com wrote: >You are using VFX version 4.72 with a build-date of 3 days ago. > >This is the result I get: > > > VFX Forth for Windows IA32 > =A9 MicroProcessor Engineering Ltd, 1998-2012=20 > > Version: 4.60 [build 3388] > Build date: 24 October 2012 > > Free dictionary =3D 7562654 bytes [7385kb] > > >create foo 5 , 6 , ok >synonym poo foo ok >' poo >body @ . 5012107 ok >' foo >body @ . 5 ok >locate synonym=20 >Definition found in /Kernel/Common/kernel.fth at line 5696. > ok Ah - rather than report a bug to see if it has been fixed, you carry on using an old version. Sounds familiar. According to the release notes, that bug was fixed in 4.62.3444 of 16 August 2013. 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-14 16:39 -0700 |
| Message-ID | <119c024d-ecb1-4b5d-926b-8a94ddb91bd9@googlegroups.com> |
| In reply to | #39750 |
On Sunday, June 14, 2015 at 4:15:34 PM UTC-7, Stephen Pelc wrote: > On Sun, 14 Jun 2015 09:26:01 -0700 (PDT), hughaguilar96@gmail.com > wrote: > > >You are using VFX version 4.72 with a build-date of 3 days ago. > > > >This is the result I get: > > > > > > VFX Forth for Windows IA32 > > =A9 MicroProcessor Engineering Ltd, 1998-2012=20 > > > > Version: 4.60 [build 3388] > > Build date: 24 October 2012 > > > > Free dictionary =3D 7562654 bytes [7385kb] > > > > > >create foo 5 , 6 , ok > >synonym poo foo ok > >' poo >body @ . 5012107 ok > >' foo >body @ . 5 ok > >locate synonym=20 > >Definition found in /Kernel/Common/kernel.fth at line 5696. > > ok > > Ah - rather than report a bug to see if it has been fixed, you > carry on using an old version. Sounds familiar. > > According to the release notes, that bug was fixed in 4.62.3444 of > 16 August 2013. > > Stephen Why am I supposed to care? I'm not a customer. I write ANS-Forth code that works --- you write VFX-specific code in an effort to trap the VFX users in vendor lock-in --- but I'm blameworthy because I don't keep up to date on your bug fixes? Even if I had known that your bug was fixed, I would have still written my own code that is portable to any ANS-Forth compiler --- my code is always better than everybody else's --- for the most part, I don't even look at other people's code. You're dodging the issue --- your claim that carnal knowledge is necessary to write SYNONYM was not true --- my disambiguifiers make code such as SYNONYM trivial to write in ANS-Forth, and they work on every ANS-Forth compiler everywhere. Considering that you are on the standards's committee, you seem to be overly focused on telling people that code is impossible to write in standard Forth and that they have to buy your compiler to get basic features such as SYNONYM that are actually trivial to write in standard Forth (given the disambiguifiers). You don't want to admit that my disambiguifiers work.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-06-14 15:21 -0700 |
| Message-ID | <0fce1302-0492-4e8e-9e13-c0c90620814e@googlegroups.com> |
| In reply to | #39730 |
On Saturday, June 13, 2015 at 10:41:10 PM UTC-7, hughag...@gmail.com wrote: > Using the built-in outer-interpreter works reasonably well. The major problem with this is that numbers don't work in compilation mode. For example: > > TARG > : TEST ( -- 123 ) 123 ; > > This doesn't work because the 123 gets compiled into the host-computer memory rather than the target-computer memory. By comparison: > > TARG > : TEST ( -- 123 ) [ 123 ] LITERAL ; > > This does work because LITERAL was defined as an immediate word in HOST mode and consequently it executes on the host-computer but works on target-computer memory. > > In MFX I had a short-hand version to help reduce source-code bloat: > > TARG > : TEST ( -- 123 ) [ 123 ]L ; > > This is still somewhat ugly, but it was acceptable at Testra. It wasn't a big deal because they mostly used constants rather than raw numbers anyway. Also, they were building a Forth processor on a Lattice isp1048 PLD, which is difficult to do --- they weren't concerned about such a trivial issue as this --- so long as MFX had all the major features of a Forth cross-compiler, they were happy. > > This isn't really acceptable for a commercial cross-compiler though, which is why I'm rewriting the cross-compiler to use a custom outer-interpreter --- now that I have figured out how to disambiguify ANS-Forth to allow custom outer-interpreters to be written. This whole problem could be solved if LITERAL were standardized as being vectored. LITERAL is presumably used by the built-in outer-interpreter to compile numbers in compilation mode (such as 123 above). If LITERAL were vectored, then the HOST version of : could switch in the HOST version of LITERAL for the duration of the colon word and the problem would be solved. This would actually be much better than writing a custom outer-interpreter just so that numbers compile correctly --- it is much simpler to use the built-in outer-interpreter. What do you say Stephen Pelc? Can you make LITERAL a vectored word in your next VFX release? Help the cross-compiler writers of the world --- and, how about making LITERAL vectored in Forth-200x while you are at it.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-14 23:20 +0000 |
| Message-ID | <557e0b74.333535519@news.eternal-september.org> |
| In reply to | #39748 |
On Sun, 14 Jun 2015 15:21:11 -0700 (PDT), hughaguilar96@gmail.com wrote: rant, rant, rant >What do you say Stephen Pelc? Can you make LITERAL a vectored word in your = >next VFX release? Help the cross-compiler writers of the world --- and, how= > about making LITERAL vectored in Forth-200x while you are at it. If you had made the slightest effort, e.g. by disassembling LITERAL and what it contains, or by reading the manual, you would find that LITERAL is already effectively DEFERred. So is NUMBER? 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]
Page 9 of 17 — ← Prev page 1 … 7 8 [9] 10 11 … 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web