Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #49278 > unrolled thread
| Started by | Chris Curl <ccurl609@gmail.com> |
|---|---|
| First post | 2016-07-21 07:09 -0700 |
| Last post | 2016-07-28 05:33 -0700 |
| Articles | 20 on this page of 169 — 25 participants |
Back to article view | Back to comp.lang.forth
Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-21 07:09 -0700
Re: Dictionary separated from code ... PROS and CONs Pablo Hugo Reda <pabloreda@gmail.com> - 2016-07-21 07:21 -0700
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-21 14:58 +0000
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-21 11:23 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 12:42 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-21 12:40 -1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 17:07 -0700
Re: Dictionary separated from code ... PROS and CONs Cecil Bayona <cbayona@cbayona.com> - 2016-07-21 19:32 -0500
Re: Dictionary separated from code ... PROS and CONs Paul Rubin <no.email@nospam.invalid> - 2016-07-21 17:40 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 17:50 -0700
Re: Dictionary separated from code ... PROS and CONs Cecil Bayona <cbayona@cbayona.com> - 2016-07-21 19:53 -0500
Re: Dictionary separated from code ... PROS and CONs Ron Aaron <rambamist@gmail.com> - 2016-07-22 06:58 +0300
Re: Dictionary separated from code ... PROS and CONs Ron Aaron <rambamist@gmail.com> - 2016-07-22 06:54 +0300
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-22 06:48 +0000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 00:19 -0700
Re: Dictionary separated from code ... PROS and CONs Cecil Bayona <cbayona@cbayona.com> - 2016-07-22 02:33 -0500
Re: Dictionary separated from code ... PROS and CONs Ron Aaron <rambamist@gmail.com> - 2016-07-22 10:45 +0300
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-21 19:41 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 20:52 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-22 11:22 -0400
Re: Dictionary separated from code ... PROS and CONs Cecil Bayona <cbayona@cbayona.com> - 2016-07-22 10:49 -0500
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-22 11:16 -0400
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 22:11 -0700
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-22 06:32 +0000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 23:58 -0700
Re: Dictionary separated from code ... PROS and CONs missycurl@gmail.com - 2016-07-21 17:02 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-21 17:06 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 17:11 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-21 15:57 -1000
Re: Dictionary separated from code ... PROS and CONs "HAA" <someone@microsoft.com> - 2016-07-22 13:25 +1000
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-21 20:24 -0700
Re: Dictionary separated from code ... PROS and CONs stephen@mpeforth.com (Stephen Pelc) - 2016-07-22 11:32 +0000
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 12:49 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 23:10 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 22:36 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 20:58 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-21 21:56 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 23:38 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 10:43 -0700
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-22 10:56 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-22 14:18 -0400
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 08:55 -1000
Re: Dictionary separated from code ... PROS and CONs "WJ" <w_a_x_man@yahoo.com> - 2016-07-25 11:34 +0000
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-22 11:36 -0400
Re: Dictionary separated from code ... PROS and CONs Lars Brinkhoff <lars.spam@nocrew.org> - 2016-07-22 11:15 +0200
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-22 11:37 -0400
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 08:56 -1000
Re: Dictionary separated from code ... PROS and CONs "HAA" <someone@microsoft.com> - 2016-07-24 13:16 +1000
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-24 12:58 -0700
Re: Dictionary separated from code ... PROS and CONs "HAA" <someone@microsoft.com> - 2016-07-25 18:09 +1000
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-24 22:34 -1000
Re: Dictionary separated from code ... PROS and CONs "HAA" <someone@microsoft.com> - 2016-07-27 23:08 +1000
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-27 08:58 -1000
CREATE...DOES> etc. and flash (was: Dictionary separated ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-28 09:17 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) "HAA" <someone@microsoft.com> - 2016-07-29 00:19 +1000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-28 14:54 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) humptydumpty <ouatubi@gmail.com> - 2016-07-28 10:00 -0700
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) "HAA" <someone@microsoft.com> - 2016-07-29 21:47 +1000
Re: CREATE...DOES> etc. and flash Coos Haak <chforth@hccnet.nl> - 2016-07-29 15:04 +0200
Re: CREATE...DOES> etc. and flash "HAA" <someone@microsoft.com> - 2016-07-30 18:42 +1000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-29 15:05 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) hughaguilar96@gmail.com - 2016-07-30 02:21 -0700
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) "HAA" <someone@microsoft.com> - 2016-07-31 13:05 +1000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) hughaguilar96@gmail.com - 2016-07-30 21:24 -0700
Re: CREATE...DOES> etc. and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-31 19:07 -0500
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-01 06:24 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-01 06:14 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) "HAA" <someone@microsoft.com> - 2016-08-02 10:45 +1000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-02 06:59 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) Julian Fondren <julian.fondren@gmail.com> - 2016-08-02 00:34 -0700
Re: CREATE...DOES> etc. and flash Coos Haak <htrofhc@gmail.com> - 2016-08-02 13:57 +0200
Re: CREATE...DOES> etc. and flash Julian Fondren <julian.fondren@gmail.com> - 2016-08-02 06:19 -0700
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-02 15:28 +0000
Re: CREATE...DOES> etc. and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-02 13:34 -0500
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-03 07:32 +0000
Re: CREATE...DOES> etc. and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-03 11:51 -0500
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-04 08:21 +0000
Re: CREATE...DOES> etc. and flash stephen@mpeforth.com (Stephen Pelc) - 2016-08-04 13:18 +0000
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-04 14:02 +0000
Re: CREATE...DOES> etc. and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-04 12:26 -0500
Re: CREATE...DOES> etc. and flash Mark Wills <markwills1970@gmail.com> - 2016-08-02 07:24 -0700
Re: CREATE...DOES> etc. and flash Julian Fondren <julian.fondren@gmail.com> - 2016-08-02 07:36 -0700
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) humptydumpty <ouatubi@gmail.com> - 2016-08-02 12:14 -0700
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) humptydumpty <ouatubi@gmail.com> - 2016-08-02 12:17 -0700
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) "HAA" <someone@microsoft.com> - 2016-08-06 13:35 +1000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) Mark Wills <markwills1970@gmail.com> - 2016-08-02 07:20 -0700
Re: CREATE...DOES> etc. and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-02 13:43 -0500
Re: CREATE...DOES> etc. and flash "Elizabeth D. Rather" <erather@forth.com> - 2016-07-28 09:19 -1000
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-29 05:15 +0000
Re: CREATE...DOES> etc. and flash "Elizabeth D. Rather" <erather@forth.com> - 2016-07-28 21:50 -1000
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-29 08:24 +0000
Re: CREATE...DOES> etc. and flash Brad Eckert <hwfwguy@gmail.com> - 2016-07-29 10:08 -0700
Re: CREATE...DOES> etc. and flash Brad Eckert <hwfwguy@gmail.com> - 2016-07-29 15:06 -0700
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-30 06:22 +0000
Re: CREATE...DOES> etc. and flash Paul Rubin <no.email@nospam.invalid> - 2016-07-30 01:07 -0700
Re: CREATE...DOES> etc. and flash hughaguilar96@gmail.com - 2016-07-30 01:30 -0700
Re: CREATE...DOES> etc. and flash Brad Eckert <hwfwguy@gmail.com> - 2016-07-30 10:17 -0700
Re: CREATE...DOES> etc. and flash hughaguilar96@gmail.com - 2016-07-30 00:51 -0700
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-22 05:20 -0700
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-22 13:06 +0000
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-22 08:13 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 09:09 -1000
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-22 14:08 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 15:24 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 20:12 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 17:36 -1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 21:54 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 22:03 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 22:00 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 22:19 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 20:40 -1000
Re: Dictionary separated from code ... PROS and CONs "HAA" <someone@microsoft.com> - 2016-07-23 22:23 +1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 15:48 -0700
Re: Dictionary separated from code ... PROS and CONs missycurl@gmail.com - 2016-07-24 16:04 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-24 19:31 -0400
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-24 17:20 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 17:54 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-24 21:27 -0400
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 19:18 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-24 22:25 -0400
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-24 20:39 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 23:32 -0700
Re: Dictionary separated from code ... PROS and CONs Julian Fondren <julian.fondren@gmail.com> - 2016-07-25 00:30 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-24 21:36 -1000
Re: Dictionary separated from code ... PROS and CONs Julian Fondren <julian.fondren@gmail.com> - 2016-07-25 00:46 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-25 09:19 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-25 12:35 -0400
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-25 12:32 -0400
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-24 17:48 -1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 23:09 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-25 12:43 -0400
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-23 06:58 +0000
Re: Dictionary separated from code ... PROS and CONs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-23 04:02 -0500
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-23 10:43 -0700
Re: Dictionary separated from code ... PROS and CONs Paul Rubin <no.email@nospam.invalid> - 2016-07-23 10:48 -0700
Re: Dictionary separated from code ... PROS and CONs humptydumpty <ouatubi@gmail.com> - 2016-07-23 10:53 -0700
Re: Dictionary separated from code ... PROS and CONs Pablo Hugo Reda <pabloreda@gmail.com> - 2016-07-23 11:24 -0700
Re: Dictionary separated from code ... PROS and CONs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-24 03:33 -0500
Re: Dictionary separated from code ... PROS and CONs missycurl@gmail.com - 2016-07-24 08:16 -0700
Re: Dictionary separated from code ... PROS and CONs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-25 04:28 -0500
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-27 11:59 +0000
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-27 07:36 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-27 10:44 -0400
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-27 11:36 -0700
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-27 11:53 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-27 09:09 -1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-27 12:47 -0700
Re: Dictionary separated from code ... PROS and CONs foxaudioresearch@gmail.com - 2016-07-27 13:27 -0700
Re: Dictionary separated from code ... PROS and CONs all2001@spambog.com (Wolfgang Allinger) - 2016-07-27 18:20 -0300
Re: Dictionary separated from code ... PROS and CONs Julian Fondren <julian.fondren@gmail.com> - 2016-07-27 19:40 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-27 19:56 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-28 00:44 -0400
Re: Dictionary separated from code ... PROS and CONs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-27 16:14 -0500
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-27 18:38 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-27 16:03 -0400
Re: Dictionary separated from code ... PROS and CONs missycurl@gmail.com - 2016-07-27 21:09 -0700
Re: Dictionary separated from code ... PROS and CONs missycurl@gmail.com - 2016-07-27 21:13 -0700
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-27 15:25 +0000
Re: Dictionary separated from code ... PROS and CONs Mark Wills <markwills1970@gmail.com> - 2016-07-28 02:53 -0700
Re: Dictionary separated from code ... PROS and CONs JennyB <jennybrien@googlemail.com> - 2016-07-27 09:44 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-24 13:06 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 15:36 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-24 12:43 -1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 15:53 -0700
Re: Dictionary separated from code ... PROS and CONs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-25 04:32 -0500
Re: Dictionary separated from code ... PROS and CONs Roelf Toxopeus <rt4all@nothishetnet.nl> - 2016-07-23 14:47 +0200
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 12:24 -1000
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 19:47 -0700
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-28 05:33 -0700
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-07-22 10:49 -0500 |
| Message-ID | <nmtfat$899$2@dont-email.me> |
| In reply to | #49330 |
On 7/22/2016 10:22 AM, rickman wrote: > On 7/21/2016 11:52 PM, hughaguilar96@gmail.com wrote: >> On Thursday, July 21, 2016 at 7:41:28 PM UTC-7, Brad Eckert wrote: >>> On Thursday, July 21, 2016 at 5:07:46 PM UTC-7, hughag...@gmail.com >>> wrote: >>>> >>>> What most likely happened is that some compiler-writers had code >>>> and data separated, because they knew that this results in >>>> significantly faster execution speed. SwiftForth had code and >>>> data intermixed. Everybody wanted to be ANS-Forth compliant, so >>>> Elizabeth Rather said either method was fine --- data may or may >>>> not be intermixed with code --- nothing was standardized. >>> >>> AFAIK, Rick Van Norman was the primary author of SwiftForth, not >>> Elizabeth. >> >> I'm well aware... > > of precious little for the most part. Your rantings are getting the > better of you here so I snipped the pointless maniacal ravings. I will > point out that computers come in many sizes, shapes and architectures. > Not all of them require or even support the separation of data and code > space. The bottom line is Forth allows you to design a compiler that is > appropriate for your computer system no matter what it is. Well, maybe > not on an abacus. > I do believe he was referring about desktop machines since his Forth project is only for desktops and that seems to be his area of interest, in that case the chips do have mechanisms to enforce the separation of the code and the data, although use of those features is optional. Windows has that feature although it can be turned off for compatibility with old software. Linus also has that capability also. In the embedded field that forced separation is all over the place with many devices offering no protection and separation of data versus code. The assemblers for those embedded devices do provide with commands to separate the two as that feature is vital in creating code that can be placed in ROM or FLASH memories. These two classes of computers have drifted apart over the years, it used to be that desktops used the same processors that embedded computers used, but that has changed although some ARM machines are beginning to blend the two classes again. Raspberry Pi 3 ,or their brethren anyone? The only thing one can count on is that Forth is great, specially for embedded computer devices. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-07-22 11:16 -0400 |
| Message-ID | <nmtdc2$92d$1@dont-email.me> |
| In reply to | #49292 |
On 7/21/2016 8:07 PM, hughaguilar96@gmail.com wrote: > On Thursday, July 21, 2016 at 3:40:35 PM UTC-7, Elizabeth D. Rather > wrote: >> On 7/21/16 4:09 AM, Chris Curl wrote: >>> As you folks may remember, I am implementing my own little >>> Forth. >>> >>> I have implemented two flavors of the memory organization, one >>> where the code and dictionary start at opposite ends of the >>> memory space and grow towards each other, and one where the >>> dictionary entries are interspersed with the code. >> >> I'm not sure what you mean by this. Do you mean segregating code >> and data space, or machine code separate from compiled definitions? >> The former makes a lot of sense in certain cases (dating back to >> some early 8086 implementations using segmented registers, an >> approach that was abandoned when people went to 32-bit >> implementations). The latter is pretty unusual, and I can't offhand >> think of a rationale for it. >> >> The most common mapping for integrated data space is to have the >> dictionary in low memory growing towards high memory and the stacks >> in high memory growing down, with the data stack lower so that it >> and the dictionary basically share unused memory. If there is a >> segregated data space, it would be elsewhere, with the dictionary >> (containing code and high-level definitions) still growing towards >> high memory. This would include the name space for variables and >> other data structures that reside in data space. >> >>> At this point, I don't have a clear favorite or preference >>> between the two. >>> >>> From your perspective, what are the PROs and CONs of the two >>> different approaches, and which would you tend to gravitate to? >>> >>> https://github.com/CCurl/Forth_C >> >> An integrated code/data space dictionary is simpler to create and >> maintain, and results in less implementation code and modestly >> better compilation performance. The segregated dictionary is >> necessary when you need to run from ROM/flash, or on segregated >> code space microcontrollers. >> >> Cheers, Elizabeth > > ANS-Forth failed because it was written by an idiot salesperson who > doesn't know even the most rudimentary concepts of assembly-language > that any first-year assembly-language programmer would be expected to > know. Caches! Ask somebody what they are! > > ANS-Forth should have specified that code and data are separate. HERE > would only be affected by ALLOT and comma (there are several > variations on comma, for different data types). The ANS-Forth > document would define exactly which words cause the HERE value to > change. Someone once said, "there is no correct way to do this stuff --- so, get off your high horse and stop criticizing people for doing things differently than you do them." -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-22 22:11 -0700 |
| Message-ID | <a6abd7e7-a5d7-48e1-8694-d8800e9bb834@googlegroups.com> |
| In reply to | #49329 |
On Friday, July 22, 2016 at 8:16:20 AM UTC-7, rickman wrote: > On 7/21/2016 8:07 PM, hughaguilar96@gmail.com wrote: > > On Thursday, July 21, 2016 at 3:40:35 PM UTC-7, Elizabeth D. Rather > > wrote: > >> An integrated code/data space dictionary is simpler to create and > >> maintain, and results in less implementation code and modestly > >> better compilation performance. The segregated dictionary is > >> necessary when you need to run from ROM/flash, or on segregated > >> code space microcontrollers. > >> > >> Cheers, Elizabeth > > > > ANS-Forth failed because it was written by an idiot salesperson who > > doesn't know even the most rudimentary concepts of assembly-language > > that any first-year assembly-language programmer would be expected to > > know. Caches! Ask somebody what they are! > > > > ANS-Forth should have specified that code and data are separate. HERE > > would only be affected by ALLOT and comma (there are several > > variations on comma, for different data types). The ANS-Forth > > document would define exactly which words cause the HERE value to > > change. > > Someone once said, "there is no correct way to do this stuff --- so, get > off your high horse and stop criticizing people for doing things > differently than you do them." Elizabeth Rather declares her way to be the Standard (with a capital 'S') and declares that anybody who does anything different is non-standard, and hence not a Forth programmer at all --- she alone decides what Forth is! When I made that statement about people criticizing others for doing things differently, I was referring to the debate between infix and postfix arithmetic. Both ways are valid, so neither is "correct." People can go with whichever they want --- obviously infix for that Gareth fellow --- postfix for Forthers. If you are going to implement infix arithmetic however, then it must be done correctly --- if you give addition a higher precedence than multiplication, then that is incorrect --- similarly, if you are compiling for any processor bigger than the 6502 and you intermix code and data, then that is incorrect. It is okay to prefer infix to postfix or vice-versa --- it is okay to prefer chicken salad to chicken soup or vice-versa --- it is not okay to declare chicken shit to be chicken salad, or to declare that this is the Standard and anybody who does anything else with the chicken is non-standard.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-07-22 06:32 +0000 |
| Message-ID | <2016Jul22.083231@mips.complang.tuwien.ac.at> |
| In reply to | #49289 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>I'm not sure what you mean by this. Do you mean segregating code and
>data space, or machine code separate from compiled definitions? The
>former makes a lot of sense in certain cases (dating back to some early
>8086 implementations using segmented registers, an approach that was
>abandoned when people went to 32-bit implementations). The latter is
>pretty unusual, and I can't offhand think of a rationale for it.
Gforth generates both something like threaded code, and native
(machine) code, and the native code is separated from the rest, to
avoid cache consistency problems, but also because the native code is
optional and mostly transparent to the rest of the system: if the
conditions for dynamic native code generations are not met, the
threaded code just points to the original code for the primitives
(like classical threaded code), and no native code is generated.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-21 23:58 -0700 |
| Message-ID | <191139c4-90be-452f-9bb8-aefef1357fdb@googlegroups.com> |
| In reply to | #49312 |
On Thursday, July 21, 2016 at 11:42:33 PM UTC-7, Anton Ertl wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: > >I'm not sure what you mean by this. Do you mean segregating code and > >data space, or machine code separate from compiled definitions? The > >former makes a lot of sense in certain cases (dating back to some early > >8086 implementations using segmented registers, an approach that was > >abandoned when people went to 32-bit implementations). The latter is > >pretty unusual, and I can't offhand think of a rationale for it. It is ridiculous that Elizabeth Rather now claims to understand how 8086 segment registers work. That wasn't the reality at the time. PolyForth for the 8086 had everything (machine-code, threaded-code code, application data, the compiler, the dictionary headers) all in a single 64K segment. It was obvious that the 8086 version of PolyForth was ported from an old version of PolyForth written for a processor (most likely the PDP-11) that only addressed 64K of memory --- the Forth Inc. "programmers" just ported it line-by-line without any modification to take advantage of the 8086's segment registers --- presumably the original version of PolyForth was written by Charles Moore, but after he got kicked out Forth Inc. had to just maintain his old software but were unable to write any software themselves. Weirdly enough, what Elizabeth Rather is describing above sounds like UR/Forth from Laboratory MicroSystems Inc.. UR/Forth was a DTC system with the machine-code in the CS segment, the threaded-code and application data in the DS segment, and the dictionary headers in the ES segment. I wrote some benchmarks in both UR/Forth and Borland Turbo-C (small memory model) and found that the programs ran at pretty close to the same speed. By comparison, PolyForth compared badly to QBASIC. > Gforth generates both something like threaded code, and native > (machine) code, and the native code is separated from the rest, to > avoid cache consistency problems, but also because the native code is > optional and mostly transparent to the rest of the system: if the > conditions for dynamic native code generations are not met, the > threaded code just points to the original code for the primitives > (like classical threaded code), and no native code is generated. The last time I checked, Gforth code ran at about half the speed of SwiftForth code. I assumed that you had made an agreement with Elizabeth Rather that you would make sure that Gforth code was always slower than SwiftForth code so as to not undermine Forth Inc. sales, and in return she would appoint you to be the Forth-200x chair-person. When you describe Gforth however, as you did above, it sounds like it should be pretty fast. Have you improved Gforth now so that it does surpass SwiftForth? The quality of the code generated by SwiftForth is truly awful --- I find it difficult to believe that any Forth system could be slower than SwiftForth, unless the compiler-writers were purposely trying to make it slower.
[toc] | [prev] | [next] | [standalone]
| From | missycurl@gmail.com |
|---|---|
| Date | 2016-07-21 17:02 -0700 |
| Message-ID | <4f88c331-a803-45df-bd8e-27eafefb2986@googlegroups.com> |
| In reply to | #49278 |
Elizabeth, here is what I am talking about ... this is the 2 words HERE and LAST in the integrated version. Note that the dictionary headers at 005e and 0073 are interspersed with the code: 005e 49 00 73 00 ; Prev=0049, Next=0073, HERE 0062 6b 00 00 ; XT=006b, flags=00 0065 04 48 45 52 45 00 006b 18 5e 00 ; DICTP 005e - HERE 006e 0b 43 00 ; CALL 0043 - (HERE) 0071 02 ; FETCH 0072 0c ; RET 0073 5e 00 88 00 ; Prev=005e, Next=0088, LAST 0077 80 00 00 ; XT=0080, flags=00 007a 04 4c 41 53 54 00 0080 18 73 00 ; DICTP 0073 - LAST 0083 0b 58 00 ; CALL 0058 - (LAST) 0086 02 ; FETCH 0087 0c ; RET In the separated version, the code for HERE and LAST are at 0033 and 003b, while the dictionary headers are at 1ec1 and 1ecc: 0033 18 cc 1e ; DICTP 1ecc - HERE 0036 0b 27 00 ; CALL 0027 - (HERE) 0039 02 ; FETCH 003a 0c ; RET 003b 18 c1 1e ; DICTP 1ec1 - LAST 003e 0b 2d 00 ; CALL 002d - (LAST) 0041 02 ; FETCH 0042 0c ; RET ... 1ec1 cc 1e ; Next=1ecc, LAST 1ec3 3b 00 00 ; XT=003b, flags=00 1ec6 04 4c 41 53 54 00 1ecc d7 1e ; Next=1ed7, HERE 1ece 33 00 00 ; XT=0033, flags=00 1ed1 04 48 45 52 45 00
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-07-21 17:06 -0700 |
| Message-ID | <8c63b476-e4fb-491e-a69a-873b51e3d02a@googlegroups.com> |
| In reply to | #49278 |
On Thursday, July 21, 2016 at 7:09:46 AM UTC-7, Chris Curl wrote: > As you folks may remember, I am implementing my own little Forth. > > I have implemented two flavors of the memory organization, one where > the code and dictionary start at opposite ends of the memory space and > grow towards each other, and one where the dictionary entries are interspersed > with the code. > If header space is separate from code space, you can possibly do things like: : place ( a u dest -) 0 over c! [ : +place ( a u dest -) 2dup >r >r count + swap move r> r> c+! ; Also, the code is smaller so you have fewer cache misses. As processors get faster, it seems cache misses get more expensive. That's why small virtual machines sometimes beat native code implementations. The VM fits in cache. You also have the option of discarding the header space, such as when creating a ROM image for an embedded system.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-21 17:11 -0700 |
| Message-ID | <be68cdd3-8a07-42fe-8aeb-6efb8f4c5d19@googlegroups.com> |
| In reply to | #49291 |
On Thursday, July 21, 2016 at 5:06:12 PM UTC-7, Brad Eckert wrote: > On Thursday, July 21, 2016 at 7:09:46 AM UTC-7, Chris Curl wrote: > > As you folks may remember, I am implementing my own little Forth. > > > > I have implemented two flavors of the memory organization, one where > > the code and dictionary start at opposite ends of the memory space and > > grow towards each other, and one where the dictionary entries are interspersed > > with the code. > > > If header space is separate from code space, you can possibly do things like: > > : place ( a u dest -) 0 over c! [ > : +place ( a u dest -) 2dup >r >r count + swap move r> r> c+! ; > > Also, the code is smaller so you have fewer cache misses. As processors get faster, it seems cache misses get more expensive. That's why small virtual machines sometimes beat native code implementations. The VM fits in cache. > > You also have the option of discarding the header space, such as when creating a ROM image for an embedded system. What I learned over on comp.lang.asm.x86 is that cache-thrashing is primarily what kills speed. There are a lot of different optimization techniques, all of which have some effect --- by far however, the most important is to reduce cache-thrashing --- this has more effect than all of the others combined.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-07-21 15:57 -1000 |
| Message-ID | <T6SdnR6UnLQN4AzKnZ2dnUU7-a3NnZ2d@supernews.com> |
| In reply to | #49291 |
On 7/21/16 2:06 PM, Brad Eckert wrote: > On Thursday, July 21, 2016 at 7:09:46 AM UTC-7, Chris Curl wrote: >> As you folks may remember, I am implementing my own little Forth. >> >> I have implemented two flavors of the memory organization, one where >> the code and dictionary start at opposite ends of the memory space and >> grow towards each other, and one where the dictionary entries are interspersed >> with the code. >> > If header space is separate from code space, you can possibly do things like: > > : place ( a u dest -) 0 over c! [ > : +place ( a u dest -) 2dup >r >r count + swap move r> r> c+! ; > > Also, the code is smaller so you have fewer cache misses. As processors get faster, it seems cache misses get more expensive. That's why small virtual machines sometimes beat native code implementations. The VM fits in cache. Yes, but cache sizes have grown much bigger. The system I'm typing on has 6M cache. With integrated code/data your entire system should fit in a small corner of that space. > You also have the option of discarding the header space, such as when creating a ROM image for an embedded system. > Yes, that's the main argument for segregating them. But the OP is talking about segregating the dictionary heads from the code, which is another issue altogether. In a cross-compiler, the heads are in the host, and only the actual code and an image of initialized RAM go in the ROMable image. In a resident system, the advantage of segregating the headers from the code is unclear to me. 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 | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-07-22 13:25 +1000 |
| Message-ID | <nms3hm$j1q$1@gioia.aioe.org> |
| In reply to | #49301 |
Elizabeth D. Rather wrote: > On 7/21/16 2:06 PM, Brad Eckert wrote: > ... > > You also have the option of discarding the header space, such as when creating a ROM > > image for an embedded system. > > > > Yes, that's the main argument for segregating them. > > But the OP is talking about segregating the dictionary heads from the > code, which is another issue altogether. In a cross-compiler, the heads > are in the host, and only the actual code and an image of initialized > RAM go in the ROMable image. In a resident system, the advantage of > segregating the headers from the code is unclear to me. The advantage is that on more than a few occasions potential Forthers and purchasers of commercial systems have asked whether applications can be saved without compiler overhead. That is after all what compilers in other languages traditionally do. In Forth the choices to date have been to live with the bloat, or use a meta-compiler that limits the very interactivity Forth claims is behind its productivity.
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-07-21 20:24 -0700 |
| Message-ID | <27e6a582-0cb5-4eb0-966b-45944e4f85e4@googlegroups.com> |
| In reply to | #49301 |
On Thursday, July 21, 2016 at 6:57:41 PM UTC-7, Elizabeth D. Rather wrote: > But the OP is talking about segregating the dictionary heads from the > code, which is another issue altogether. In a cross-compiler, the heads > are in the host, and only the actual code and an image of initialized > RAM go in the ROMable image. In a resident system, the advantage of > segregating the headers from the code is unclear to me. > I think what you're saying is that headers might as well be in code space because caches are huge anyway. Separating data and code spaces is a separate issue. The hardware has to support interleaved code and data because too many apps use it, so it's really a non-issue to everyone but Intel design teams. However, on the evolution front I think Forth is getting a bit stale. Chris has the chance to implement his Forth without any baggage or customers who are locked into certain ways of doing things. I'm in favor of removing the dependency that headers may or may not be interleaved with code, and saying that they are not. Like in my cute PLACE/+PLACE example. In other words, embedded tricks work on the desktop. Even the normative embedded standard that MPE and FORTH Inc. came up with could use some work. Last I heard, Leon wasn't completely satisfied with it. I think a Forth that fits both desktop and embedded environments would be a good goal. Perhaps it's time to run the code in a tight VM expressed in C, so as to leverage today's C-based IDEs and middleware. You're back down to 16K or 32K caches for $5-$10 chips, enough for the VM to run in cache at an ARM9's 400 MHz speed. -Brad
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2016-07-22 11:32 +0000 |
| Message-ID | <57920312.74801387@news.eternal-september.org> |
| In reply to | #49305 |
On Thu, 21 Jul 2016 20:24:15 -0700 (PDT), Brad Eckert <hwfwguy@gmail.com> wrote: >Even the normative embedded standard that MPE and FORTH Inc. came up with c= >ould use some work. Last I heard, Leon wasn't completely satisfied with it.= The embedded draft standard was designed on a whiteboard in Waterloo (Belgium) during the OTA project. It reflects the design of the FI and MPE cross-compilers of the time, especially in terms of their use of wordlists/vocabularies. A lot of detail is missing from the specification of the COMPILER scope. I have also designed a cross-compiler in which the ideas of the cross-compiler scopes do not work well. Every year, Leon and I discuss overhauling the document, but it really needs input from other people who use cross-compilers every day. 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 | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-07-22 12:49 -0700 |
| Message-ID | <f95306f6-8533-4306-8601-80aa3126f071@googlegroups.com> |
| In reply to | #49321 |
On Friday, July 22, 2016 at 4:32:11 AM UTC-7, Stephen Pelc wrote: > Every year, Leon and I > discuss overhauling the document, but it really needs input from > other people who use cross-compilers every day. > One thing that just occurred to me is that the TARGET scope can be implemented with a group of WORDLISTs, not just one. You could have VOCABULARY, MODULE, etc. work on this group. TARGET would plop the group into the search order. Maybe TARGET FORTH would start you off with the basic target visibility and then you could dig down from there. Search order scoping is one of the things I miss in embedded Forths. There might be other things you can think of. I haven't looked at the document in a while. Do you have a link to it?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-22 23:10 -0700 |
| Message-ID | <d9dc2d2c-86b7-42b1-be15-d0843a4a3f89@googlegroups.com> |
| In reply to | #49342 |
On Friday, July 22, 2016 at 12:49:53 PM UTC-7, Brad Eckert wrote: > One thing that just occurred to me is that the TARGET scope can be implemented with a group of WORDLISTs, not just one. You could have VOCABULARY, MODULE, etc. work on this group. TARGET would plop the group into the search order. Maybe TARGET FORTH would start you off with the basic target visibility and then you could dig down from there. > > Search order scoping is one of the things I miss in embedded Forths. There might be other things you can think of. I don't know what you are talking about here. None of this stuff makes sense to me. I think you are over-complicating cross-compilation because you don't know how it works. MFX was written in UR/Forth that was Forth-83 and had the traditional vocabulary system with CONTEXT and CURRENT --- that worked fine --- there was no need for the wordlist stack that ANS-Forth has. The only limitation is that in MFX the TARG application code could not have vocabularies. This seemed unimportant to me --- the only program I've ever written that used vocabularies was MFX --- I've never needed vocabularies in application code. As for modules, I did upgrade UR/Forth to do that. I could mark a word as being local to a module with LOCAL that was executed after the word definition (it set a smudge-ready flag in the word's header). I also had END-MODULE that searched through the entire dictionary and if it found a word with the smudge-ready flag set, it would set the smudge flag and unset the smudge-ready flag. So, in a file I would mark all of the words that wanted available only within the file with LOCAL and I would put END-MODULE at the end of the file to smudge them all. This reduced namespace pollution a lot. This also made the source-code more readable because the reader would know which words were intended to be used outside of the module (these are the API for the module) and which words were used internally within the module (these he could ignore). Modules don't have anything to do with cross-compiling. I only implemented modules because MFX was a big program with many files, and making files into modules helps to simplify big programs --- I would have implemented modules for any big program that I was writing.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-22 22:36 -0700 |
| Message-ID | <58cac945-48ea-4ada-b7e6-9c53cac32bdb@googlegroups.com> |
| In reply to | #49321 |
On Friday, July 22, 2016 at 4:32:11 AM UTC-7, Stephen Pelc wrote: > On Thu, 21 Jul 2016 20:24:15 -0700 (PDT), Brad Eckert > <hwfwguy@gmail.com> wrote: > > >Even the normative embedded standard that MPE and FORTH Inc. came up with c= > >ould use some work. Last I heard, Leon wasn't completely satisfied with it.= > > The embedded draft standard was designed on a whiteboard in Waterloo > (Belgium) during the OTA project. It reflects the design of the FI > and MPE cross-compilers of the time, especially in terms of their > use of wordlists/vocabularies. A lot of detail is missing from > the specification of the COMPILER scope. > > I have also designed a cross-compiler in which the ideas of the > cross-compiler scopes do not work well. Every year, Leon and I > discuss overhauling the document, but it really needs input from > other people who use cross-compilers every day. I don't think you need input from people who use cross-compilers every day --- I think you need input from somebody who has written a cross-compiler. I find it quite arrogant that you believe that you and Leon Wagner are qualified to write the Standard for cross-compilers, and that people like me have to just RTFM. I wrote MFX in 1994/1995 and it was used to cross-compile the motion-control program. I know how cross-compilers work. I am very dubious that you know how a cross-compiler works. Consider this thread: https://groups.google.com/forum/#!searchin/comp.lang.forth/LC53/comp.lang.forth/wP5nw1ClzsM/E-TV9v2y9RoJ You said this: On Tuesday, December 8, 2009 at 3:18:13 PM UTC-7, Stephen Pelc wrote: > There are three types of compilation involved > 1) Host compilation > 2) Clone compilation (target CPU same as host and memory matches) > 3) Cross compilation (target CPU is not host CPU) > > In the third case you have to simulate *everything* when dealing > with both the definition and execution of defining words. It's not > easy. You also have to extend the normal Forth compiler by at least > two time frames. Forth cross compilers are much more complicated > and much more subtle than they appear to be. > > That's one reason why the cross compiler proposal is the way it is. > The big downside of the proposal is that the original was written in > a hurry to satisfy EuroPay. It also reflects the state of Forth cross > compiler design of about 15 years ago. I have prototyped a design > for which the current proposal is inappropriate. This is totally not true --- you do not have to simulate the target processor on the host processor at compile-time --- wtf??? Forth cross-compilers are not "much more complicated and much more subtle than they appear to be" --- they seem this way to you because you don't know how they work --- they are pretty simple after you have grasped the concept.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-21 20:58 -0700 |
| Message-ID | <ed417360-9605-44aa-a142-73f7e7e5a5cc@googlegroups.com> |
| In reply to | #49301 |
On Thursday, July 21, 2016 at 6:57:41 PM UTC-7, Elizabeth D. Rather wrote: > In a resident system, the advantage of > segregating the headers from the code is unclear to me. If both code and data are in the same cache-line, then you are wasting cache space --- also, there is the awkward problem of what happens if your code writes into data that is in the code-cache. Stupid! Why do you even get involved in these technical discussions? You really know nothing about programming! You should just stick to braying about how you are the "leading expert" who writes the Standard for all Forth programmers, and avoid getting involved in technical discussions because you invariably make fool out of yourself with your ignorance.
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-07-21 21:56 -0700 |
| Message-ID | <e49f35b9-69be-4488-9676-c44aa09bf4d3@googlegroups.com> |
| In reply to | #49308 |
On Thursday, July 21, 2016 at 8:58:15 PM UTC-7, hughag...@gmail.com wrote: > > If both code and data are in the same cache-line, then you are wasting cache space --- also, there is the awkward problem of what happens if your code writes into data that is in the code-cache. > Yes, that is awkward. How do you propose handling two different behaviors of comma (compile to code space or compile to data space)? > Stupid! Why do you even get involved in these technical discussions? You really know nothing about programming! You should just stick to braying about how you are the "leading expert" who writes the Standard for all Forth programmers, and avoid getting involved in technical discussions because you invariably make fool out of yourself with your ignorance. Did I mention the ANS TC was a quarter century ago? She and Ned wrote a nice book on ANS, which is an information-dense reference. Regardless, there's a book. How about you write a book as you write your cool new Forth. If you develop the book and Forth together, you will have a good reference book so people can actually use it. I've never met Elizabeth Rather (now Conklin), so I can't really say much about her apart from what I read on c.l.f. However, I've never seen her call anyone stupid.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-21 23:38 -0700 |
| Message-ID | <08d7c335-307b-4051-9f46-8005788969bb@googlegroups.com> |
| In reply to | #49310 |
On Thursday, July 21, 2016 at 9:56:11 PM UTC-7, Brad Eckert wrote: > On Thursday, July 21, 2016 at 8:58:15 PM UTC-7, hughag...@gmail.com wrote: > > > > If both code and data are in the same cache-line, then you are wasting cache space --- also, there is the awkward problem of what happens if your code writes into data that is in the code-cache. > > > Yes, that is awkward. How do you propose handling two different behaviors of comma (compile to code space or compile to data space)? Comma goes into data space. There is COMPILE, and LITERAL that go into code space. The important thing is that everything that goes into data space is documented so the programmer knows what affects the HERE value. Also, it is important that the HERE value is affected in the same way in every system --- not like in ANS-Forth where ALIGN may or may not modify the HERE value (in SwiftForth-v2 ALIGN and ALIGNED were noops, whereas in SwiftForth-v3 they did what they were expected to do; ALIGN could change HERE in the expected way). I can't think of any reason why the application programmer needs to know what is going into code space. This is going to be different from one compiler to the next, so he can't write a program that depends upon him knowing how code is compiled. Also, there is likely to be a time delay --- COMPILE, etc. will compile code into an intermediate data-structure, then semicolon will call the optimizer to compile that intermediate code into actual code in the code space. I don't think it is a good idea for any of this to be exposed in the Standard --- the Standard should standardize behavior not implementation. > > Stupid! Why do you even get involved in these technical discussions? You really know nothing about programming! You should just stick to braying about how you are the "leading expert" who writes the Standard for all Forth programmers, and avoid getting involved in technical discussions because you invariably make fool out of yourself with your ignorance. > > Did I mention the ANS TC was a quarter century ago? She and Ned wrote a nice book on ANS, which is an information-dense reference. Regardless, there's a book. What book was this? I haven't seen anything from Forth Inc. that I would describe as being an "information-dense reference" --- are you referring to the ANS-Forth document? > How about you write a book as you write your cool new Forth. If you develop the book and Forth together, you will have a good reference book so people can actually use it. Yea, I'll do that. > I've never met Elizabeth Rather (now Conklin), so I can't really say much about her apart from what I read on c.l.f. However, I've never seen her call anyone stupid. When she appoints herself to be the chair-person of the ANS-Forth committee, and declares that ANS-Forth is the Standard for the entire Forth community, that is effectively the same as saying that every Forth programmer is stupid. I think her tactic is to pay a troll such as John Passaniti to attack people such as Jeff Fox and myself. Then she praises the troll lavishly and calls him "brilliant" --- this makes her seem to be saying only positive things, but she doesn't get dirty by directly saying negative things --- if she associates with a troll like Passaniti though, then she is profoundly dirty, and she'll never be able to hide this dirtiness. She also just lies routinely. She used to drive Jeff Fox crazy by continually lying about his and Charles Moore's work. Programmers take pride in their accomplishments, and it bothers them to have lies told about this saying that they actually failed. When she was demanding that I be kicked off the Forth-200x mailing list, she said that I had been fired from Testra after writing MFX. All of the ANS-Forth cult members cheerfully accept everything that she says, even when it is implausible (How would she know anything about Testra? They won't have anything to do with her either.) She tries to act like a sweet old lady, but she is a "deeply dishonest person" (Jeff Fox's words) --- pretty much everything that she says is a lie --- she hates anybody who has accomplished anything with Forth, and she tells gross lies about the person, but she praises those who have never accomplished anything (so long as they praise her as the "leading expert" of Forth). She also lies routinely about Forth Inc. "accomplishments" --- I've never heard any Forth Inc. customer verify any of this --- I think she is lying about all of this. Forth Inc. screws up everything that they get involved in --- OpenForth, for example, failed due to Forth Inc. screwing it all up --- it is the Forth community who gets a black-eye though, as everybody in the world says that Forth is no good. She is mad at me because she made a sales-pitch at Testra to write the cross-compiler for the MiniForth, but I got the job instead (I was told at Testra that her price was "exorbitant" and that they felt insulted that Forth Inc. sent a glib salesperson rather than a programmer to talk to them). She hates anybody who steals a job from Forth Inc.. She said one company declined to use Forth Inc. and hired some C programmers instead, then she says that the C program ended up costing more than the Forth program was going to cost and took several times as long to complete --- how would she know any of this? --- did that potential customer keep her informed on the progress of his project after he rejected her offer? All the ANS-Forth cult members just accept these stories without question though. If Elizabeth Rather just stuck to selling SwiftForth and Forth Inc. programming services, she wouldn't bother me --- declaring herself to be my leader and saying that I (and all other Forth programmers) depend entirely on her for guidance does bother me --- I am amazed that you guys accept such a gross insult without complaint.
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-07-22 10:43 -0700 |
| Message-ID | <28993a04-6a37-4d04-ba2a-f480f568347b@googlegroups.com> |
| In reply to | #49311 |
On Thursday, July 21, 2016 at 11:38:36 PM UTC-7, hughag...@gmail.com wrote: > > > > Did I mention the ANS TC was a quarter century ago? She and Ned wrote a nice book on ANS, which is an information-dense reference. Regardless, there's a book. > > What book was this? I haven't seen anything from Forth Inc. that I would describe as being an "information-dense reference" --- are you referring to the ANS-Forth document? > The Forth Programmer's Handbook, 3rd Edition. You can get it: Free PDF either in the wild or in SwiftForth eval version. $20 used: https://www.amazon.com/Forth-Programmers-Handbook-Elizabeth-Rather/dp/1419675494 > > If Elizabeth Rather just stuck to selling SwiftForth and Forth Inc. programming services, she wouldn't bother me --- declaring herself to be my leader and saying that I (and all other Forth programmers) depend entirely on her for guidance does bother me --- I am amazed that you guys accept such a gross insult without complaint. Well, okay. Elizabeth's role in life has evolved into "Mama Forth" and you disagree with the way she fills the role. She does like to pontificate, but I suppose it goes with being a nice Catholic girl. The pontiff of Forth. Maybe in a previous life you had a run-in with the Grand Inquisitor Torquemada. What I get from all this is that you can't design Forth by committee. You have to do it like Chuck. One committed guy does the whole thing his way. When Chuck left Forth Inc, the basic philosophy was frozen in amber. When the ANS TC came along, Chuck found this amber too hard to chisel through. So, you have you and Chris and others implementing their own Forths. It's a big job to work your way up to Chuck level. Many Forths to write. But, Forth will never be finished. It's a way of life, this pursuit of elegant minimalism. We live in age in which the costs of complexity are almost universally underestimated.
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-07-22 10:56 -0700 |
| Message-ID | <aeabf3bb-5a4d-4648-bafe-fc6ac36e304e@googlegroups.com> |
| In reply to | #49336 |
On Friday, July 22, 2016 at 1:43:55 PM UTC-4, Brad Eckert wrote: > We live in age in which the costs of complexity are almost universally underestimated. Very well put. I agree completely. One of my primary gauges for code is that it should be "intuitively obvious upon casual inspection". If it isn't, then there better be a damn good reason why not.
[toc] | [prev] | [next] | [standalone]
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web