Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #47094 > unrolled thread
| Started by | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| First post | 2016-05-13 20:05 +0000 |
| Last post | 2016-05-17 21:08 +1000 |
| Articles | 20 on this page of 214 — 26 participants |
Back to article view | Back to comp.lang.forth
C to Forth (was Ting) stephen@mpeforth.com (Stephen Pelc) - 2016-05-13 20:05 +0000
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-13 14:06 -0700
Re: C to Forth (was Ting) Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-05-14 00:27 -0400
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-13 21:55 -0700
RTX20xx ...Re: C to Forth (was Ting) Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-05-19 08:58 +0100
Re: RTX20xx ...Re: C to Forth (was Ting) Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-05-21 04:08 -0400
Re: C to Forth (was Ting) Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-05-21 04:09 -0400
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-13 14:33 -0700
Re: C to Forth (was Ting) Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-05-14 00:28 -0400
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-13 21:02 -1000
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-14 15:15 -0700
Re: C to Forth (was Ting) Cecil Bayona <cbayona@cbayona.com> - 2016-05-14 17:39 -0500
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-14 16:56 -0700
Re: C to Forth (was Ting) Cecil Bayona <cbayona@cbayona.com> - 2016-05-14 20:25 -0500
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-15 00:16 -0400
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-15 00:19 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-15 08:58 -0400
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-15 08:24 -1000
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-15 17:18 -0400
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-15 18:52 -1000
Re: C to Forth (was Ting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-16 06:23 +0000
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-16 15:12 -0700
Programmable "people" "WJ" <w_a_x_man@yahoo.com> - 2016-05-20 23:34 +0000
Re: Programmable "people" rickman <gnuarm@gmail.com> - 2016-05-21 00:48 -0400
Re: C to Forth (was Ting) "WJ" <w_a_x_man@yahoo.com> - 2016-05-23 14:21 +0000
Re: C to Forth (was Ting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-15 10:42 +0000
Re: C to Forth (was Ting) "HAA" <someone@microsoft.com> - 2016-05-17 20:33 +1000
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-17 08:39 -0500
Re: C to Forth (was Ting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-17 14:06 +0000
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-17 11:40 -1000
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-17 19:20 -0700
Re: C to Forth (was Ting) Tessa Bonting <tessa.bonting@gmail.com> - 2016-05-15 08:32 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-15 12:18 -0700
Re: C to Forth (was Ting) foxaudioresearch@gmail.com - 2016-05-25 13:41 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-15 17:22 -0400
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-15 17:24 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-15 19:30 -0700
Re: C to Forth (was Ting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-16 13:37 +0000
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-16 07:25 -0700
Re: C to Forth (was Ting) Bernd Paysan <bernd.paysan@gmx.de> - 2016-05-16 21:50 +0000
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-16 16:06 -0700
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-17 01:04 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-17 01:43 -0700
Re: C to Forth (was Ting) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-05-17 10:05 +0100
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-17 11:08 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-18 10:49 -0700
Re: C to Forth (was Ting) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-05-19 13:27 +0100
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-19 06:01 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-19 10:32 -0500
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-19 10:11 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-19 16:29 -0400
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-19 14:16 -0700
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-19 14:07 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-19 14:42 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-20 03:46 -0500
Re: C to Forth (was Ting) Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-05-20 04:53 -0400
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-20 22:16 -0700
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-20 21:43 -1000
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-21 15:56 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-21 02:52 -0500
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-20 22:11 -1000
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-21 03:13 -0500
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-21 15:43 -0700
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-22 22:22 -0700
Re: C to Forth (was Ting) Lars Brinkhoff <lars.spam@nocrew.org> - 2016-05-23 08:30 +0200
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-22 23:39 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-22 23:36 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-23 04:24 -0500
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-24 09:14 -0700
Re: C to Forth (was Ting) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-05-23 10:35 +0100
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-23 18:53 -0700
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-23 19:43 -1000
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-24 00:28 -0700
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-23 21:53 -1000
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-24 01:56 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-24 09:03 -0700
Re: C to Forth (was Ting) "WJ" <w_a_x_man@yahoo.com> - 2016-05-24 22:09 +0000
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-23 22:59 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-24 04:32 -0500
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-24 12:46 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-24 15:26 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-24 15:57 -0700
Re: C to Forth (was Ting) Lars Brinkhoff <lars.spam@nocrew.org> - 2016-05-25 07:44 +0200
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-24 23:29 -0700
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-24 22:09 -1000
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-25 03:57 -0500
Re: C to Forth (was Ting) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-05-24 11:04 +0100
Re: C to Forth (was Ting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-24 14:01 +0000
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-19 15:05 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-19 21:25 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-20 03:57 -0500
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-20 06:48 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-20 09:40 -0500
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-20 09:31 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-20 13:53 -0400
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-20 14:16 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-21 03:01 -0500
Re: C to Forth (was Ting) Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-21 10:23 +0000
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-22 13:37 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-23 04:38 -0500
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-23 23:11 -0700
Re: C to Forth (was Ting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-24 13:15 +0000
Re: C to Forth (was Ting) "WJ" <w_a_x_man@yahoo.com> - 2016-05-24 13:51 +0000
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-24 19:36 -0400
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-20 22:50 -1000
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-21 16:22 -0700
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-22 14:04 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-22 15:33 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-22 19:14 -0400
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-22 17:11 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-22 20:58 -0400
Re: C to Forth (was Ting) "WJ" <w_a_x_man@yahoo.com> - 2016-05-23 13:50 +0000
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-23 08:09 -0700
Re: C to Forth (was Ting) "WJ" <w_a_x_man@yahoo.com> - 2016-05-23 13:38 +0000
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-23 07:58 -0700
Re: C to Forth (was Ting) Ron Aaron <rambamist@gmail.com> - 2016-05-23 18:55 +0300
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-23 16:00 -0700
Re: C to Forth (was Ting) Ron Aaron <rambamist@gmail.com> - 2016-05-24 06:54 +0300
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-24 00:04 -0400
Re: C to Forth (was Ting) Ron Aaron <rambamist@gmail.com> - 2016-05-24 07:19 +0300
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-24 00:40 -0400
Re: C to Forth (was Ting) Ron Aaron <rambamist@gmail.com> - 2016-05-24 08:04 +0300
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-24 03:41 -0400
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-24 01:51 -0700
Re: C to Forth (was Ting) Bruce Axtens <bruce.axtens@gmail.com> - 2016-05-29 10:00 +0800
Re: C to Forth (was Ting) Ron Aaron <rambamist@gmail.com> - 2016-05-29 07:08 +0300
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-24 04:36 -0500
Re: C to Forth (was Ting) Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-05-24 02:48 -0700
Re: C to Forth (was Ting) Cecil Bayona <cbayona@cbayona.com> - 2016-05-23 19:28 -0500
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-23 11:46 -0500
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-23 13:30 -0400
Re: C to Forth (was Ting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-24 13:37 +0000
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-25 14:22 -0700
Re: C to Forth (was Ting) Coos Haak <chforth@hccnet.nl> - 2016-05-26 00:29 +0200
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-25 16:12 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-25 23:29 -0400
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-26 14:06 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-25 19:30 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-25 20:52 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-25 23:27 -0400
Re: C to Forth (was Ting) Ron Aaron <rambamist@gmail.com> - 2016-05-26 07:40 +0300
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-26 10:03 -0700
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-26 14:31 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-27 07:22 -0500
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-27 06:07 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-27 10:00 -0500
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-27 15:51 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-27 16:27 -0700
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-27 19:25 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-28 13:12 -0700
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-28 15:07 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-28 19:15 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-28 23:41 -0400
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-28 14:50 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-29 04:36 -0500
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-29 04:34 -0500
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-29 12:19 -0700
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-29 15:37 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-30 15:31 -0500
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-30 14:54 -0700
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-30 14:44 -1000
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-30 19:21 -0700
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-31 13:49 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-31 04:01 -0500
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-31 15:02 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-31 17:27 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-06-01 07:22 -0700
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-06-01 16:09 -0700
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-06-01 18:03 -1000
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-06-02 06:36 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-01 02:54 -0500
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-06-01 08:50 -0400
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-06-01 07:38 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-06-01 10:58 -0400
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-01 11:32 -0500
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-06-01 17:10 -0400
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-06-01 17:04 -0700
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-06-01 17:57 -1000
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-06-01 22:54 -0700
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-06-02 04:31 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-02 04:59 -0500
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-28 11:44 -0400
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-28 14:58 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-28 23:43 -0400
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-29 15:07 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-29 22:44 -0400
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-30 07:14 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-30 10:33 -0400
Re: C to Forth (was Ting) pahihu <pahihu@gmail.com> - 2016-05-30 10:31 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-30 16:57 -0400
Re: C to Forth (was Ting) pahihu <pahihu@gmail.com> - 2016-05-30 23:57 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-31 09:01 -0400
Re: C to Forth (was Ting) pahihu <pahihu@gmail.com> - 2016-05-31 07:17 -0700
Re: C to Forth (was Ting) humptydumpty <ouatubi@gmail.com> - 2016-05-30 13:12 -0700
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-30 14:09 -0700
Re: C to Forth (was Ting) "WJ" <w_a_x_man@yahoo.com> - 2016-06-01 10:07 +0000
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-06-01 17:13 -0700
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-17 02:14 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-17 11:50 -0700
Re: C to Forth (was Ting) Darin Murphy <murphy.darin@gmail.com> - 2016-05-17 15:28 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-17 18:52 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-18 09:41 -0400
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-17 01:12 -0700
Re: C to Forth (was Ting) Cecil Bayona <cbayona@cbayona.com> - 2016-05-17 04:34 -0500
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-17 10:46 -0700
Re: C to Forth (was Ting) Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-18 09:10 +0000
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-18 09:36 -0400
Re: C to Forth (was Ting) Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-16 17:58 +0000
Cross compilers [Was: C to Forth] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-18 04:58 -0500
Re: Cross compilers [Was: C to Forth] Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-18 11:25 +0000
Re: Cross compilers [Was: C to Forth] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-18 10:28 -0500
Recognizers (was: Cross compilers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-18 16:48 +0000
Re: C to Forth (was Ting) "WJ" <w_a_x_man@yahoo.com> - 2016-05-16 15:11 +0000
Re: C to Forth (was Ting) "HAA" <someone@microsoft.com> - 2016-05-17 21:08 +1000
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-16 16:06 -0700 |
| Message-ID | <9cee1949-05d9-4f78-82c5-b9d9f512f2fa@googlegroups.com> |
| In reply to | #47220 |
On Monday, May 16, 2016 at 2:54:22 PM UTC-7, Bernd Paysan wrote: > A typical thing about a cross compiler is that you have to rewrite the > entire outer interpreter. With recognizers, you could skip that, and > just replace the number recognizer with a cross-compiling one. This > could even resolve some remaining issues with our cross compiler for 32- > >64 bit cross compilations, because it can't deal with 64 bit constants > (we work around that problem were we need these constants). A cross > compiler recognizer could handle 64 bit constants even when it runs on a > 32 bit system. You need to make LITERAL vectored because that is what compiles the number, so it has to be made to compile the number into the target system rather than the host system. If LITERAL is vectored then the built-in outer-interpreter can be used and you can have literal numbers in your cross-compiler, and there is no need to write your own outer-interpreter. Recognizers are a terrible idea. I won't have them in my Straight Forth that is designed primarily to be a platform for cross-compilers. Recognizers give Forth a syntax, which Forth has traditionally not had. The problem with recognizers in Forth-200x is that there are likely to be a lot of them, and they are going to clash with each other. Every Forth-200x program is going to require a mish-mash of recognizers, and so every Forth-200x program will have syntax that is unique to itself. This is very similar to the problem in ANS-Forth in which there is a lot of ambiguity --- we have different ANS-Forth compilers (SwiftForth, gForth, VFX and Win32Forth) that are incompatible with each other regarding fundamental aspects of the language, and yet are all considered to be ANS-Forth (and they can all make a claim that they conform to the ANS-Forth document given their interpretation of the ambiguous aspects because multiple interpretations are valid). Similarly, different Forth-200x compilers will have incompatible syntax and programs written for one won't compile on another, but every Forth-200x compiler will claim to conform to Forth-200x. Normally, if a person is looking at Forth source-code and sees a word that he doesn't recognize, he can look up the word to find out what it does. This is done with WHEREIS in VFX and with LOCATE in most Forth systems. This gives him the source-code for the word, which is hopefully commented. Also, there may be documentation for a code-library that he is using and it will explain each word provided. But what does the person look up when he sees $CAFEBABE or some such thing? LOCATE is not going to work! He is left not knowing what the word does, and not having any way to find out. Actually, I think that it is a good idea to add some syntax to Forth. In Straight Forth, I will allow hexadecimal numbers to be represented by a $ in front --- so $CAFEBABE is effectively the same as: 3405691582. This is part of the language though which will be well-documented, and it isn't going to change. Nobody can install his own recognizer in which the $ in front indicates something else. Recognizers don't have any practical value. They are just provided to allow every Forth-200x user to exercise his creativity and have is own cute syntax. This doesn't help people to write programs though. At best, (such as allowing a $ in front to indicate hexadecimal), it may improve readability. There are few cases in which readability will be improved though --- for the most part, recognizers in Forth-200x are going to be written by people who have too much free time on their hands and who want to cutify Forth --- I predict that Forth-200x will have dozens of incompatible recognizers and all of them will be written late at night by alcoholic failed-artists trying to be cute. Recognizers are not the way to implement a cross-compiler --- anybody who believes this, does not know how to implement a cross-compiler.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2016-05-17 01:04 -0700 |
| Message-ID | <30f7a26d-ee8a-4bb1-a9e6-2fb9c5deec03@googlegroups.com> |
| In reply to | #47226 |
> You need to make LITERAL vectored because that is what compiles the number, so it has to be made to compile the number into the target system rather than the host system. If LITERAL is vectored then the built-in outer-interpreter can be used and you can have literal numbers in your cross-compiler, and there is no need to write your own outer-interpreter. Yes, this is very helpful. Also, I use vectored NUMBER each time literal placing on stack and variable CAN-DISPATCH to minimize actions with this vector. I mean my compilers, of course. This is a snippet of cross-compiler for my Forth-CPU : KF532-LIT // N -- CAN-DISPATCH OFF // placing literal from stack to memory CAN-DISPATCH ON ; : MAIN: ['] KF532-LIT TO DISPATCH-NUMBER CAN-DISPATCH ON ... > Recognizers don't have any practical value. +1 First time I've heard of this new toy :) This is intresting exercise, but in practice it is useless for anybody skilled enough to write cross-compiler (and understood how both PC and target CPU works).
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-17 01:43 -0700 |
| Message-ID | <938662b0-97b1-42dd-951c-df1fdafab845@googlegroups.com> |
| In reply to | #47238 |
On Tuesday, May 17, 2016 at 1:04:10 AM UTC-7, Ilya Tarasov wrote:
> > You need to make LITERAL vectored because that is what compiles the number, so it has to be made to compile the number into the target system rather than the host system. If LITERAL is vectored then the built-in outer-interpreter can be used and you can have literal numbers in your cross-compiler, and there is no need to write your own outer-interpreter.
>
> Yes, this is very helpful. Also, I use vectored NUMBER each time literal placing on stack and variable CAN-DISPATCH to minimize actions with this vector. I mean my compilers, of course.
ANS-Forth could have easily been made to support cross-compilers. All that was needed was to make LITERAL vectored.
A lot of the low-level code in ANS-Forth could have been defined as being vectored. Weirdly enough, nothing in ANS-Forth was defined as being vectored. The book "Starting Forth" discusses vectored execution, so Elizabeth Rather should have been aware of the concept when she wrote ANS-Forth --- the book does describe the subject as being "hairy" (for our Russian readers, that means "difficult") --- so maybe that was a part of the book that she didn't understand.
All in all, ANS-Forth is the work of a non-programmer --- it was just a marketing gimmick from Forth Inc. --- ANS-Forth has to be abandoned if Forth is ever going to succeed.
> > Recognizers don't have any practical value.
>
> +1
Well, my STR>NUM allows either a + or a - in front of the number to indicate positive or negative, with positive being the default if neither is there.
try string-stack.4th
UPPER isn't unique.
OCTAL isn't unique.
2 definitions were hidden
ok
s" +123" str>num ok
.s
123 1 <-Top ok
The 1 is a code telling what kind of number it is. The codes are:
0 \ these are the kinds of numbers
enum #invalid
enum #single
enum #double
enum #float
drop
> First time I've heard of this new toy :) This is intresting exercise, but in practice it is useless for anybody skilled enough to write cross-compiler (and understood how both PC and target CPU works).
Forth-200x is overly concerned with toy programming --- they are not focusing their minds on making the language practical.
I get the impression that very few people are writing programs in Forth. There is no interest in my string-stack.4th apparently because nobody is writing any programs that involve text --- it is not that there is a better way to work with strings, because there is no other string package available, neither better nor worse --- the many Forth experts on Forth-200x just aren't writing programs involving text or any other kind of data.
Forth-200x is full of hobbyists who just want to be experts because being an expert seems pretty fun, and Forth-200x has little or no qualification to be an expert, so it is an opportunity to be an expert programmer without actually programming.
Anyway Ilya --- I'm happy to see that you have built a Forth processor and that you are using Forth for practical work --- I translated that webpage of yours from Russian to English and I'm reading up on your work.
There seems to be more interest in Forth in Russia these days than in America or Europe, and there seems to be little or no interest in ANS-Forth or Forth-200x in Russia --- eventually Forth may become a purely Russian language and people will forget that it actually originated in America during the 20th century --- the Americans dropped the ball, and the Russians picked it up.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-05-17 10:05 +0100 |
| Message-ID | <nhemm8$sr8$1@dont-email.me> |
| In reply to | #47240 |
On 17/05/2016 09:43, hughaguilar96@gmail.com wrote:
> On Tuesday, May 17, 2016 at 1:04:10 AM UTC-7, Ilya Tarasov wrote:
>>> You need to make LITERAL vectored because that is what compiles the number, so it has to be made to compile the number into the target system rather than the host system. If LITERAL is vectored then the built-in outer-interpreter can be used and you can have literal numbers in your cross-compiler, and there is no need to write your own outer-interpreter.
>>
>> Yes, this is very helpful. Also, I use vectored NUMBER each time literal placing on stack and variable CAN-DISPATCH to minimize actions with this vector. I mean my compilers, of course.
>
> ANS-Forth could have easily been made to support cross-compilers. All that was needed was to make LITERAL vectored.
>
I'm puzzled about why you persist in making that claim when instead of
writing in the target code, say
... 1234 ...
instead write
... [ 1234 ] LITERAL ...
and the host redefines LITERAL to stick the number in target code, just
like IF etc have to be redefined.
I admit this is ugly but it *is* ANS Forth whether you like it or not.
Elsewhere you claim smudge is needed for locals, this is also not true
as wordlists can be created and used for locals.
--
Gerry
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-17 11:08 -0700 |
| Message-ID | <4ccd7da9-ce35-434d-afd5-f16c1324ede9@googlegroups.com> |
| In reply to | #47241 |
On Tuesday, May 17, 2016 at 2:05:36 AM UTC-7, Gerry wrote: > On 17/05/2016 09:43, hughaguilar96@gmail.com wrote: > > On Tuesday, May 17, 2016 at 1:04:10 AM UTC-7, Ilya Tarasov wrote: > >>> You need to make LITERAL vectored because that is what compiles the number, so it has to be made to compile the number into the target system rather than the host system. If LITERAL is vectored then the built-in outer-interpreter can be used and you can have literal numbers in your cross-compiler, and there is no need to write your own outer-interpreter. > >> > >> Yes, this is very helpful. Also, I use vectored NUMBER each time literal placing on stack and variable CAN-DISPATCH to minimize actions with this vector. I mean my compilers, of course. > > > > ANS-Forth could have easily been made to support cross-compilers. All that was needed was to make LITERAL vectored. > > > > I'm puzzled about why you persist in making that claim when instead of > writing in the target code, say > ... 1234 ... > instead write > ... [ 1234 ] LITERAL ... > and the host redefines LITERAL to stick the number in target code, just > like IF etc have to be redefined. > > I admit this is ugly but it *is* ANS Forth whether you like it or not. It is ugly and the cross-compiler is ANS-Forth --- I never said otherwise --- ANS-Forth is not able to cross-compile Forth (Forth is supposed to have literal numbers, so what is being cross-compiled here is at best Forth-like code). I actually have this supported: ... [ 1234 ]L ... This is somewhat shorter and less ugly, but it is still not Forth (still not supporting literal numbers). Really, LITERAL needs to be vectored! This need was obvious in 1994, and it continues to be obvious in 2016, and after Forth-200x gets released (if it ever gets released), this need will still be obvious. > Elsewhere you claim smudge is needed for locals, this is also not true > as wordlists can be created and used for locals. Word-lists are created with WORDLIST (see section 16.6.1.2460): "A system shall allow the creation of at least 8 new word lists in addition to any provided as part of the system." You can't call WORDLIST in every function to create a word-list for the locals of that function, and then just forget about that wid --- if you have more than 8 functions with locals then your cross-compiler is not ANS-Forth compliant anymore (your cross-compiler may work on some or all of the major ANS-Forth systems though; as Anton says: "A system that would tell us all non-standard usages would be nice, but we don't have that. For now the solution is to test on as many systems as possible.") If you did use VFX or SwiftForth to write a cross-compiler using this technique of calling WORDLIST for every function with locals (I don't know if this will actually work) and it did work, then Stephen Pelc or Leon Wagner or both would likely modify their compiler so that it would only allow 8 calls to WORDLIST --- they can do this, and still be ANS-Forth compliant --- they would be motivated to do this to prevent you from writing a cross-compiler in competition with them. They are not your friends! They will do everything in their power to prevent you from competing with them! This is the whole purpose of the committee!
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-18 10:49 -0700 |
| Message-ID | <0c344658-0e5b-403c-85b3-28a4d40a58aa@googlegroups.com> |
| In reply to | #47257 |
On Tuesday, May 17, 2016 at 11:08:31 AM UTC-7, hughag...@gmail.com wrote: > On Tuesday, May 17, 2016 at 2:05:36 AM UTC-7, Gerry wrote: > > I'm puzzled about why you persist in making that claim when instead of > > writing in the target code, say > > ... 1234 ... > > instead write > > ... [ 1234 ] LITERAL ... > > and the host redefines LITERAL to stick the number in target code, just > > like IF etc have to be redefined. > > > > I admit this is ugly but it *is* ANS Forth whether you like it or not. > > It is ugly and the cross-compiler is ANS-Forth --- I never said otherwise --- ANS-Forth is not able to cross-compile Forth (Forth is supposed to have literal numbers, so what is being cross-compiled here is at best Forth-like code). > > I actually have this supported: > ... [ 1234 ]L ... > This is somewhat shorter and less ugly, but it is still not Forth (still not supporting literal numbers). > > Really, LITERAL needs to be vectored! This need was obvious in 1994, and it continues to be obvious in 2016, and after Forth-200x gets released (if it ever gets released), this need will still be obvious. This is what I had in MFX for literal numbers: : 8+ [ 8 ]L + ; This is just a shorthand for this: : 8+ [ 8 ] literal + ; I did this because UR/Forth (and Forth-83) also failed to make LITERAL vectored. Now ANS-Forth fails to make LITERAL vectored, so there has been no improvement. Presumably Forth-200x will maintain the tradition of failing to make LITERAL vectored... MFX used the built-in outer-interpreter. This problem can be avoided by writing your own outer-interpreter with its own LITERAL etc.. There are problems here too though! QUIT is not vectored either, so there is no way to make it call your new-and-improved outer-interpreter. If you have an abort on an error, QUIT will be called internally by the word that aborted and it will return to the old outer-interpreter. You will have to manually restart your new outer-interpreter. If you don't do this, and you try to cross-compile the program when you're in the wrong outer-interpreter, chaos will result! All in all, the solution is to make LITERAL vectored --- this was obvious in 1994 and continues to be obvious in 2016. There are some other features that are also needed, such as a way to examine an xt and determine its attributes (what vocabulary it is in, immediate or not immediate, smudged or not smudged, etc.), and to modify all of these attributes. Moving a word from one vocabulary to another is important! In MFX I had modules. This means that I could mark words as being smudge-ready . I had a word END-MODULE that would search the entire dictionary and smudge all of of the smudge-ready words (and also turn off the smudge-ready flag). This allowed me to have only certain words in the module visible outside of the module --- all the words that were used only within the module were marked as smudge-ready and got smudged by END-MODULE that was at the end of the module (each file was a module). This really reduces name-space pollution in a large program. I had only one level of module --- it would be possible to have multiple levels of modules. This would be a good way to implement locals. The locals are marked as smudge-ready-level1 and the semi-colon smudges all the smudge-ready-level1 words, so it smudges the locals in that function (IIRC that is how I did it in MFX, although my memory is somewhat fuzzy after 22 years). We could also have a way to mark words as smudge-ready-level2 and END-MODULE would smudge all the smudge-ready-level2 words. There could also be smudge-ready-level3 words and we would have END-LIBRARY that would smudge all of the smudge-ready-level3 words, with a library containing multiple modules. All in all, making a Forth system friendly toward cross-compilers is easy --- all of these suggestions of mine are trivial to implement --- I think most of the self-proclaimed experts on cross-compilation have not actually written a cross-compiler, because if they had then they would consider all of this stuff that I'm saying to be obvious.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-05-19 13:27 +0100 |
| Message-ID | <nhkb98$gpn$1@dont-email.me> |
| In reply to | #47281 |
On 18/05/2016 18:49, hughaguilar96@gmail.com wrote: > On Tuesday, May 17, 2016 at 11:08:31 AM UTC-7, hughag...@gmail.com wrote: >> On Tuesday, May 17, 2016 at 2:05:36 AM UTC-7, Gerry wrote: >>> I'm puzzled about why you persist in making that claim when instead of >>> writing in the target code, say >>> ... 1234 ... >>> instead write >>> ... [ 1234 ] LITERAL ... >>> and the host redefines LITERAL to stick the number in target code, just >>> like IF etc have to be redefined. >>> >>> I admit this is ugly but it *is* ANS Forth whether you like it or not. >> >> It is ugly and the cross-compiler is ANS-Forth --- I never said otherwise --- ANS-Forth is not able to cross-compile Forth (Forth is supposed to have literal numbers, so what is being cross-compiled here is at best Forth-like code). >> >> I actually have this supported: >> ... [ 1234 ]L ... >> This is somewhat shorter and less ugly, but it is still not Forth (still not supporting literal numbers). >> >> Really, LITERAL needs to be vectored! This need was obvious in 1994, and it continues to be obvious in 2016, and after Forth-200x gets released (if it ever gets released), this need will still be obvious. > > This is what I had in MFX for literal numbers: > : 8+ [ 8 ]L + ; > > This is just a shorthand for this: > : 8+ [ 8 ] literal + ; > I was only pointing out that, despite your claim, you could get literals into a target system and you agree. Just because I did that doesn't mean that I disagree with your points that things, such as your suggestions, could things could make the writing of cross compilers easier, of course they can. Incidentally I was wrong about stating that wordlists could be used for locals - I'd overlooked the fact that the number of wordlists caould be limited. > I did this because UR/Forth (and Forth-83) also failed to make LITERAL vectored. Now ANS-Forth fails to make LITERAL vectored, so there has been no improvement. Presumably Forth-200x will maintain the tradition of failing to make LITERAL vectored... Well the proposed recognisers could do the job instead. > > MFX used the built-in outer-interpreter. This problem can be avoided by writing your own outer-interpreter with its own LITERAL etc.. There are problems here too though! QUIT is not vectored either, so there is no way to make it call your new-and-improved outer-interpreter. If you have an abort on an error, QUIT will be called internally by the word that aborted and it will return to the old outer-interpreter. You will have to manually restart your new outer-interpreter. If you don't do this, and you try to cross-compile the program when you're in the wrong outer-interpreter, chaos will result! A well-written outer interpreter would use CATCH to intercept errors, including executions of ABORT and QUIT. What errors would you want to recover from to continue cross compilation? Most would be fatal. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2016-05-19 06:01 -0700 |
| Message-ID | <c84553c2-62c8-49db-8501-ace635d95e3f@googlegroups.com> |
| In reply to | #47303 |
> A well-written outer interpreter would use CATCH to intercept errors, > including executions of ABORT and QUIT. What errors would you want to > recover from to continue cross compilation? Most would be fatal. Why do we need to rewrite an entire interpreter, when cross-compilation requires well-defined and limited features? 'Recognizers' means 'you are about to write all you need and stop annoying us'. There are several point in interpreter, there vectorized words may be helpful. Now programmers must rewrite everything... so what surprising in rewriting all Forth system as needed for qualified programmer? Why do you expect ANS-compatibility will remains, if nobody in committee wants to hear real requirements? How they really can prevent writing more usable Forth systems?
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-05-19 10:32 -0500 |
| Message-ID | <KZGdnWYYzb4SQaDKnZ2dnUU7-VnNnZ2d@supernews.com> |
| In reply to | #47304 |
Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: >> A well-written outer interpreter would use CATCH to intercept errors, >> including executions of ABORT and QUIT. What errors would you want to >> recover from to continue cross compilation? Most would be fatal. > > Why do we need to rewrite an entire interpreter, when > cross-compilation requires well-defined and limited features? Because it's the best way to do it. The "entire interpreter" is a small piece of code, and it makes sense to write one which is extended to include cross compilation. You're pretending to choke on a gnat. > 'Recognizers' means 'you are about to write all you need and stop > annoying us'. There are several point in interpreter, there > vectorized words may be helpful. Now programmers must rewrite > everything... so what surprising in rewriting all Forth system as > needed for qualified programmer? Why do you expect ANS-compatibility > will remains, if nobody in committee wants to hear real > requirements? How they really can prevent writing more usable Forth > systems? This is Forth! We have the choice of putting a bunch of hooks in the base system so that it fits some people's idea of how a cross-compiler can be written, or keeping the base system simple. We will choose the wrong hooks for some people. There's no-one better than Chuck Moore on this: "Do not leave hooks on which you can hang extensions. The things you might want to do are infinite; that means that each has 0 probability of realization. If you need an extension later, you can code it later -- and probably do a better job than if you did it now. And if someone else adds the extension, will he notice the hooks you left?" Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-19 10:11 -0700 |
| Message-ID | <4c85e17d-0276-4595-8f17-3c3c048ee3b9@googlegroups.com> |
| In reply to | #47310 |
On Thursday, May 19, 2016 at 8:32:32 AM UTC-7, Andrew Haley wrote: > Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: > >> A well-written outer interpreter would use CATCH to intercept errors, > >> including executions of ABORT and QUIT. What errors would you want to > >> recover from to continue cross compilation? Most would be fatal. > > > > Why do we need to rewrite an entire interpreter, when > > cross-compilation requires well-defined and limited features? > > Because it's the best way to do it. The "entire interpreter" is a > small piece of code, and it makes sense to write one which is extended > to include cross compilation. You're pretending to choke on a gnat. If you do write your own outer-interpreter, you will need my disambiguifiers because otherwise FIND will have ambiguous behavior on over 50 of the words in ANS-Forth (everything, such as IF etc., that was immediate in traditional Forths). If you do write your own outer-interpreter, you will need need my STR>NUM to convert strings into numbers so you can have literal strings. This is in my string-stack.4th (I wrote STR>NUM specifically to support an outer interpreter). So, it is not a "small piece of code" --- you need my novice-package. This would be the latest version which I can email --- the old version on www.forth.org doesn't support cross-compilation. This is an unofficial release --- I have some more code and documentation that I want to put in before I officially release it, plus I have to test it all on multiple versions of ANS-Forth compilers as usual because they all have their incompatible quirks. I may put a cross-compiler for a simple processor in the next official release of the novice-package, but most likely not. I got paid for this stuff in the past --- I'm not enthusiastic about giving it away for free --- especially because all of Elizabeth Rather's sycophants will just say that it "sucks" and is "crap" etc., because that is what they do. > > 'Recognizers' means 'you are about to write all you need and stop > > annoying us'. There are several point in interpreter, there > > vectorized words may be helpful. Now programmers must rewrite > > everything... so what surprising in rewriting all Forth system as > > needed for qualified programmer? Why do you expect ANS-compatibility > > will remains, if nobody in committee wants to hear real > > requirements? How they really can prevent writing more usable Forth > > systems? To answer Ilya --- the whole purpose of the committee is to prevent programmers from using ANS-Forth to compete against the commercial closed-source (not actually written in ANS-Forth internally) cross-compilers. But no, they can't succeed. The ANS-Forth committee sabotaged tick and FIND with section (4.1.2): "Ambiguous Conditions. ... attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics." But they left a loophole! POSTPONE wasn't sabotaged and it did work correctly, so it was possible to write disambiguifiers that used POSTPONE internally: : if state @ 0= abort" *** no interpretation semantics for: IF ***" postpone if ; immediate The POSTPONE of the old IF works because POSTPONE wasn't sabotaged the way that FIND was sabotaged. The new IF is no longer special-cased as a word that FIND won't work on, so FIND works on the new IF perfectly (meet the new IF, same as the old IF). Also, we no longer have the bizarre circumstance (VFX) of IF being non-immediate --- IF and all the special-case words were traditionally immediate, and thanks to the disambiguifiers, they are immediate again! In gForth FIND will return a different xt value depending upon what STATE is at the time that FIND is called. This is beyond bizarre! But now, thanks to the disambiguifiers, gForth's FIND doesn't recognize the new IF as being a special-case word that it is supposed to act bizarrely on, and so it acts on the new IF in a normal manner just like it would on any other Forth word. The disambiguifiers are really the key to writing your own outer-interpreter, and this is a valid way to write a cross-compiler. As I said before, there are two ways to write a cross-compiler. The other way, in which the built-in outer-interpreter is used, is also valid. If you do this however, then you can't have literal numbers because LITERAL is not vectored. The simplest solution, would be to make LITERAL vectored. Then the built-in outer-interpreter can be used --- why have two outer-interpreters, except that the built-in outer-interpreter is sabotaged (it doesn't support literal numbers because LITERAL is not vectored)? --- obviously, it would be better to have one outer-interpreter than worked, rather than a built-in outer-interpreter that doesn't work, and another one that does work and is used instead. Elizabeth Rather is a truly evil person! She has devoted her entire life to preventing Forth programmers from writing Forth programs in competition with Forth Inc.. The whole purpose of the ANS-Forth standard was to trap the Forth community in a pit of incompetence that they can't get out of without becoming non-standard. Fortunately, Elizabeth Rather is also dumber than a box of rocks --- she should have sabotaged POSTPONE as well as FIND to prevent cross-compilers from being written --- she left a loophole in ANS-Forth, and my disambiguifiers drive right through the loophole to make FIND work correctly again. > This is Forth! We have the choice of putting a bunch of hooks in the > base system so that it fits some people's idea of how a cross-compiler > can be written, or keeping the base system simple. We will choose the > wrong hooks for some people. > > There's no-one better than Chuck Moore on this: "Do not leave hooks on > which you can hang extensions. The things you might want to do are > infinite; that means that each has 0 probability of realization. If > you need an extension later, you can code it later -- and probably do > a better job than if you did it now. And if someone else adds the > extension, will he notice the hooks you left?" > > Andrew. ANS-Forth is a cult. Whenever the cult members get pushed into a corner, they respond by claiming to have a monopoly on "the Forth Way" and they say, "This is Forth!," as if only they know what Forth is. Most humorously, they always act like they can channel Charles Moore and speak for him. This is what Elizabeth Rather does routinely with her shtick about being the "second Forth programmer" and being taught personally by Charles Moore. Typically they trot out some quote from Charles Moore, similar to the way that wanna-be leaders often trot out quotes from the Bible to make it seem as if they have God's support for their agenda. This is all a great steaming pile of horse-shit! If Charles Moore wants to tell us what to believe, then he will show up on c.l.f. and do so himself --- the fact that he doesn't, seems to imply that he doesn't give a damn what we believe --- people who claim to speak for Charles Moore are just flinging the horse-shit in a mad attempt to fertilize their own poisonous weeds that they planted. This business of channeling a great hero, and putting your own words in the hero's mouth, works a lot better if the hero is dead --- Elizabeth Rather would be more believable if she channeled some Egyptian Pharaoh from 4000 years ago --- channeling Charles Moore is stupid because it should be obvious to anybody that if he actually believed in all this horse-shit then he would shovel it himself. Anyway, I just do whatever the hell I want to do, and I don't get permission from any hero first. In 1994 I wanted to write a Forth cross-compiler, because that was what I was getting paid to do --- this is why I now know how to write a Forth cross-compiler.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-19 16:29 -0400 |
| Message-ID | <nhl7fs$v8s$1@dont-email.me> |
| In reply to | #47313 |
On 5/19/2016 1:11 PM, hughaguilar96@gmail.com wrote: > > ANS-Forth is a cult. It won't be much longer before Hugh has a manifesto. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-19 14:16 -0700 |
| Message-ID | <a7241447-1170-4245-bdcd-53abd2bdc0e2@googlegroups.com> |
| In reply to | #47323 |
On Thursday, May 19, 2016 at 1:29:10 PM UTC-7, rickman wrote: > On 5/19/2016 1:11 PM, hughaguilar96@gmail.com wrote: > > > > ANS-Forth is a cult. > > It won't be much longer before Hugh has a manifesto. > > -- > > Rick C Elizabeth Rather has a manifesto called ANS-Forth --- that is just her special way of informing the world that she is the "leading expert" on Forth who sets the standard that all Forth programmers rely on --- you seem to like her manifesto just fine. "You hypocrite, first cast out the beam out of your own eye; and then shall you see clearly to cast out the speck out of your brother's eye." This seems to be a constant theme with you. This is from the 2010: On Nov 11, 5:31 am, rickman <gnu...@gmail.com> wrote: > I estimate it is just a matter of time... and not much of it... before > Hugh has a manifesto... > > Anyone disagree? > > Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-19 14:07 -0700 |
| Message-ID | <87shxdeoz7.fsf@jester.gateway.pace.com> |
| In reply to | #47310 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> Why do we need to rewrite an entire interpreter > The "entire interpreter" is a small piece of code, The dictionary/wordlist mechanism is part of the interpreter, so the code isn't THAT small. It would be great if the cross-compiler could re-use the host Forth's existing dictionary implementation. Maybe that's doable using just the ANS definitions, but it doesn't seem that easy. ANS could have defined a different wordlist interface that wouldn't have complicated implementations significantly yet would have made cross-compilation easier, I think. > There's no-one better than Chuck Moore on this: "Do not leave hooks on > which you can hang extensions. The things you might want to do are > infinite; that means that each has 0 probability of realization. A lot of the ANS spec, and the vocabularies of historical Forths pre-ANS, seems constructed for the specific purpose of providing enough stuff to write a self-hosted interpreter. Cross-compilation doesn't seem like an unpredictable or unlikely an extension. There is a proposed ANS spec for it, after all. Also, while it's reasonable to avoid expending extra effort implementing generality that you don't immediately need, if you can get the generality with no extra effort you might as well take it. In fact a lot of the time it makes the code simpler.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-19 14:42 -0700 |
| Message-ID | <e0448d04-6dd4-4ceb-a71a-671eb35a185f@googlegroups.com> |
| In reply to | #47325 |
On Thursday, May 19, 2016 at 2:07:41 PM UTC-7, Paul Rubin wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >> Why do we need to rewrite an entire interpreter > > The "entire interpreter" is a small piece of code, > > The dictionary/wordlist mechanism is part of the interpreter, so the > code isn't THAT small. It would be great if the cross-compiler could > re-use the host Forth's existing dictionary implementation. Maybe > that's doable using just the ANS definitions, but it doesn't seem that > easy. ANS could have defined a different wordlist interface that > wouldn't have complicated implementations significantly yet would have > made cross-compilation easier, I think. If FIND works then you can use it in your outer-interpreter, and you get the whole dictionary implementation with word-lists and all that. My disambiguifiers make FIND work, so you are good to go! I have not actually written an outer-interpreter however. MFX used the built-in outer-interpreter and we just put up with the lack of literal numbers (it looks unprofessional, but it is not really a major setback because constants are used for most constant numbers anyway). I think that, given STR>NUM and given a FIND that is uncrippled, the outer-interpreter should be easy to write. You still have the problem of QUIT going to the wrong outer-interpreter, but it may be possible to fix that with CATCH and THROW. Until I actually do this however, I can't say if it is easy or even possible --- past experience ANS-Forth indicates that there may be unexpected pit-falls... > > There's no-one better than Chuck Moore on this: "Do not leave hooks on > > which you can hang extensions. The things you might want to do are > > infinite; that means that each has 0 probability of realization. > > A lot of the ANS spec, and the vocabularies of historical Forths > pre-ANS, seems constructed for the specific purpose of providing enough > stuff to write a self-hosted interpreter. Cross-compilation doesn't > seem like an unpredictable or unlikely an extension. There is a > proposed ANS spec for it, after all. Also, while it's reasonable to > avoid expending extra effort implementing generality that you don't > immediately need, if you can get the generality with no extra effort you > might as well take it. In fact a lot of the time it makes the code > simpler. UR/Forth just had CONTEXT and CURRENT --- I was able to write MFX just fine. MFX itself didn't have vocabularies, but I didn't consider this to be a problem --- it did imply, however, that Forth-83 can't be used to write a cross-compiler for Forth-83 --- it may be possible to write an ANS-Forth cross-compiler for ANS-Forth, complete with word-lists, but I don't know as I haven't tried to do so yet. I don't know of any use for word-lists or vocabularies other than to write a cross-compiler, so getting the cross-compiler itself to support word-lists or vocabularies isn't a priority (I can't think of anything they would be used for). In 1993, Ray Duncan was on c.l.f. describing the ONLY ALSO word-list scheme as being "brain-damaged." It really is! I fixed this in the novice-package two years ago. See the section in NOVICE.4TH with the heading: "Some word-list stuff." It is too big and complicated for me to describe here. I already did describe some or all of this on c.l.f. at the time that I wrote it --- this was when I discovered the bug in VFX in which a word-list called LOCAL-VARS was pushed on the word-list stack by colon words that had locals, and this got in the way of word-list manipulations done by immediate words in the colon word --- Stephen Pelc supposedly fixed this bug in version 4.71.3523 of Oct.8,2014 (I didn't actually check that the bug was fixed, because I had already written code that worked around the bug). All of this was discussed here: https://groups.google.com/forum/#!topic/comp.lang.forth/olO-VHXJa1Q%5B1-25%5D
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-05-20 03:46 -0500 |
| Message-ID | <Q9WdnVzo-cdzU6PKnZ2dnUU7-N_NnZ2d@supernews.com> |
| In reply to | #47325 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> Why do we need to rewrite an entire interpreter >> The "entire interpreter" is a small piece of code, > > The dictionary/wordlist mechanism is part of the interpreter, so the > code isn't THAT small. You say potato, I say potahtoe. I say it's not part of the interpeter, and historically it's never been thought of as such. > It would be great if the cross-compiler could re-use the host > Forth's existing dictionary implementation. Maybe that's doable > using just the ANS definitions, but it doesn't seem that easy. Sure, you use the host Forth's existing dictionary to hold the name-address mapping for target words while cross-compiling. It's not difficult at all. I can't imagine what problem you're thinking of. >> There's no-one better than Chuck Moore on this: "Do not leave hooks >> on which you can hang extensions. The things you might want to do >> are infinite; that means that each has 0 probability of >> realization. > > A lot of the ANS spec, and the vocabularies of historical Forths > pre-ANS, seems constructed for the specific purpose of providing > enough stuff to write a self-hosted interpreter. Cross-compilation > doesn't seem like an unpredictable or unlikely an extension. There > is a proposed ANS spec for it, after all. Also, while it's > reasonable to avoid expending extra effort implementing generality > that you don't immediately need, if you can get the generality with > no extra effort you might as well take it. In fact a lot of the > time it makes the code simpler. Not in this case, AFAIK. But as I said, I don't know what problem you're thinking of. And indeed, it's quite likely that whatever hooks you think might be needed will be the wrong hooks for me. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> |
|---|---|
| Date | 2016-05-20 04:53 -0400 |
| Message-ID | <20160520045319.2353b4fb@_> |
| In reply to | #47334 |
On Fri, 20 May 2016 03:46:38 -0500 Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: <OT> > You say potato, I say potahtoe. WHO says potahtoe? ... It's tomato and tomahtoe. The fact that no one says potahtoe is the clue tomahtoe is a wrong pronunciation. RP
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-20 22:16 -0700 |
| Message-ID | <87bn40c7oo.fsf@jester.gateway.pace.com> |
| In reply to | #47334 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> The dictionary/wordlist mechanism is part of the interpreter, so the >> code isn't THAT small. > You say potato, I say potahtoe. I say it's not part of the > interpeter, and historically it's never been thought of as such. I defer to your knowledge of Forth history, but I would have counted it. It's easy for me to envision a Forth system with no text interpreter, and that system would also not have dictionary/wordlist code. The more featureful text interpreters can also get somewhat complicated: think of gforth locals, for example. > you use the host Forth's existing dictionary to hold the name-address > mapping for target words while cross-compiling. It's not difficult at > all. I can't imagine what problem you're thinking of. You want the host's version of DUP to be different than the target's version. Maybe there's a way to do this with word lists, but it would have been a lot cleaner to supply a generalized dictionary interface. Gforth has something like that under the covers, I think. And no it doesn't mean adding more code. It just means having a more convenient calling interface to code that has to be written anyway. > it's quite likely that whatever hooks you think might be needed will > be the wrong hooks for me. Well, the ANS cross-compiler extension proposal linked earlier seems like it has been useful in practice.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-05-20 21:43 -1000 |
| Message-ID | <MPidnXMYbc4wjN3KnZ2dnUU7-enNnZ2d@supernews.com> |
| In reply to | #47393 |
On 5/20/16 7:16 PM, Paul Rubin wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> The dictionary/wordlist mechanism is part of the interpreter, so the
>>> code isn't THAT small.
>> You say potato, I say potahtoe. I say it's not part of the
>> interpeter, and historically it's never been thought of as such.
>
> I defer to your knowledge of Forth history, but I would have counted it.
> It's easy for me to envision a Forth system with no text interpreter,
> and that system would also not have dictionary/wordlist code.
Strictly speaking, the Forth interpreter is a single, modest, definition
a few lines long. An only slightly simplified version is:
: INTERPRET BEGIN -' IF NUMBER ELSE DROP
EXECUTE DEPTH 0< ABORT" Stack empty"
THEN AGAIN ;
( -' searches the dictionary and returns TRUE if the word is not found;
everything else here is pretty standard)
> The more featureful text interpreters can also get somewhat complicated:
> think of gforth locals, for example.
>
>> you use the host Forth's existing dictionary to hold the name-address
>> mapping for target words while cross-compiling. It's not difficult at
>> all. I can't imagine what problem you're thinking of.
>
> You want the host's version of DUP to be different than the target's
> version. Maybe there's a way to do this with word lists, but it would
> have been a lot cleaner to supply a generalized dictionary interface.
> Gforth has something like that under the covers, I think. And no it
> doesn't mean adding more code. It just means having a more convenient
> calling interface to code that has to be written anyway.
Yes, you do it with word lists, and it's really quite simple. Read the
SwiftX manual that comes with the free evaluation downloads.
>> it's quite likely that whatever hooks you think might be needed will
>> be the wrong hooks for me.
>
> Well, the ANS cross-compiler extension proposal linked earlier seems
> like it has been useful in practice.
Indeed, it is now nearly 20 years old, and has been used in many, many
challenging applications by FORTH, Inc., MPE, and our many various
customers. No surprise, the technology has matured some, but the
principles are still there.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-21 15:56 -0700 |
| Message-ID | <30e75cd5-cad4-4751-b568-4d6f4369ebb6@googlegroups.com> |
| In reply to | #47396 |
On Saturday, May 21, 2016 at 12:43:42 AM UTC-7, Elizabeth D. Rather wrote: > On 5/20/16 7:16 PM, Paul Rubin wrote: > Strictly speaking, the Forth interpreter is a single, modest, definition > a few lines long. An only slightly simplified version is: > > : INTERPRET BEGIN -' IF NUMBER ELSE DROP > EXECUTE DEPTH 0< ABORT" Stack empty" > THEN AGAIN ; > > ( -' searches the dictionary and returns TRUE if the word is not found; > everything else here is pretty standard) NUMBER is not in the ANS-Forth standard --- so no, it is not "pretty standard." NUMBER has to be vectored so the cross-compiler can have the number compiled into the target system rather than the host system --- either that or vector LITERAL which NUMBER calls internally to do the compiling. > > Well, the ANS cross-compiler extension proposal linked earlier seems > > like it has been useful in practice. > > Indeed, it is now nearly 20 years old, and has been used in many, many > challenging applications by FORTH, Inc., MPE, and our many various > customers. No surprise, the technology has matured some, but the > principles are still there. That is bullshit --- I don't think that either the Forth Inc. or MPE cross-compilers are written in ANS-Forth. What I have seen of VFX from MPE is that very little of the code is ANS-Forth. Pelc claims that it is ANS-Forth, but that is just a hand-waving argument based on the idea that because he is on the Forth-200x committee everything he writes is automatically Standard. The code is not ANS-Forth however --- he routinely breaks with ANS-Forth compatibility --- all of that code is VFX-specific, and anybody who uses it is trapped in vendor lock-in. Elizabeth Rather is presenting the argument that only Forth Inc. and MPE "customers" can have a cross-compiler --- ANS-Forth was crippled to prevent ordinary programmers from writing cross-compilers in competition with Forth INc. and MPE --- anybody who does write a cross-compiler will necessarily break with ANS-Forth compatibility and they will get denounced by the committee for being non-standard.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-05-21 02:52 -0500 |
| Message-ID | <wPmdnXexvuo5jt3KnZ2dnUU7-IPNnZ2d@supernews.com> |
| In reply to | #47393 |
Paul Rubin <no.email@nospam.invalid> wrote: > > The more featureful text interpreters can also get somewhat > complicated: think of gforth locals, for example. Sure, but it's quite possible that a target's way of handling locals will be different from that of the host. I can't see much advantage to sharing just the text interpreter part of that. > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> you use the host Forth's existing dictionary to hold the name-address >> mapping for target words while cross-compiling. It's not difficult at >> all. I can't imagine what problem you're thinking of. > > You want the host's version of DUP to be different than the target's > version. Maybe there's a way to do this with word lists, but it would > have been a lot cleaner to supply a generalized dictionary interface. Eh? This is exactly the sort of thing for which wordlists have been used for more than thirty years. They're exactly what is needed for cross-compiling. > Gforth has something like that under the covers, I think. And no it > doesn't mean adding more code. It just means having a more convenient > calling interface to code that has to be written anyway. > >> it's quite likely that whatever hooks you think might be needed will >> be the wrong hooks for me. > > Well, the ANS cross-compiler extension proposal linked earlier seems > like it has been useful in practice. Shrug. That proposal was incomplete and unsuccessful IIRC. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | comp.lang.forth
csiph-web