Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #49278 > unrolled thread

Dictionary separated from code ... PROS and CONs

Started byChris Curl <ccurl609@gmail.com>
First post2016-07-21 07:09 -0700
Last post2016-07-28 05:33 -0700
Articles 20 on this page of 169 — 25 participants

Back to article view | Back to comp.lang.forth

Contents

  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 1 of 9  [1] 2 3 4 5 6 7 8 9  Next page →

#49278 — Dictionary separated from code ... PROS and CONs

FromChris Curl <ccurl609@gmail.com>
Date2016-07-21 07:09 -0700
SubjectDictionary separated from code ... PROS and CONs
Message-ID<3d8511c7-8cbf-4ef5-bdc3-eb33c5399d42@googlegroups.com>
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.

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

Thanks, Chris

[toc] | [next] | [standalone]

#49279

FromPablo Hugo Reda <pabloreda@gmail.com>
Date2016-07-21 07:21 -0700
Message-ID<72b2d70e-3395-4acc-bf10-0d851067b584@googlegroups.com>
In reply to#49278
El jueves, 21 de julio de 2016, 11:09:46 (UTC-3), Chris Curl  escribió:
> 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.
> 
> 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
> 
> Thanks, Chris

In Intel, asm guys tell diferent places for code and data are better for speed, but I don't test this.

[toc] | [prev] | [next] | [standalone]

#49280

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2016-07-21 14:58 +0000
Message-ID<2016Jul21.165813@mips.complang.tuwien.ac.at>
In reply to#49279
Pablo Hugo Reda <pabloreda@gmail.com> writes:
>In Intel, asm guys tell diferent places for code and data are better for sp=
>eed, but I don't test this.

Look at slide 12 of
<http://www.complang.tuwien.ac.at/anton/euroforth/ef09/papers/ertl-slides.pdf>.
You can see that bigForth is slower than Gforth for cd16sim (by more
than a factor of 4), brew, and lexex.  The reason is that bigForth
mixes native code and data, and Gforth keeps them separate.

If your system generates native code, keep the native code separated
from the data.  However, AFAIK Chris Curl's system uses some
interpreted virtual machine code.  Mixing that with the data does not
hurt, on the first order, and the system becomes simpler.

- 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]

#49285

FromChris Curl <ccurl609@gmail.com>
Date2016-07-21 11:23 -0700
Message-ID<fdf340d8-e0b3-4013-876b-40a77caf9c03@googlegroups.com>
In reply to#49280
On Thursday, July 21, 2016 at 11:13:55 AM UTC-4, Anton Ertl wrote:
> Pablo Hugo Reda <pabloreda@gmail.com> writes:
> >In Intel, asm guys tell diferent places for code and data are better for sp=
> >eed, but I don't test this.
> 
> Look at slide 12 of
> <http://www.complang.tuwien.ac.at/anton/euroforth/ef09/papers/ertl-slides.pdf>.
> You can see that bigForth is slower than Gforth for cd16sim (by more
> than a factor of 4), brew, and lexex.  The reason is that bigForth
> mixes native code and data, and Gforth keeps them separate.
> 
> If your system generates native code, keep the native code separated
> from the data.  However, AFAIK Chris Curl's system uses some
> interpreted virtual machine code.  Mixing that with the data does not
> hurt, on the first order, and the system becomes simpler.
> 
> - 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/

Yes, mine is not native code. However, I do hope to get to the point where 
I am able to generate native code.

[toc] | [prev] | [next] | [standalone]

#49286

Fromhughaguilar96@gmail.com
Date2016-07-21 12:42 -0700
Message-ID<edb5ef4a-cd7c-4919-99e9-826c949ddb11@googlegroups.com>
In reply to#49285
On Thursday, July 21, 2016 at 11:23:34 AM UTC-7, Chris Curl wrote:
> On Thursday, July 21, 2016 at 11:13:55 AM UTC-4, Anton Ertl wrote:
> > Pablo Hugo Reda <pabloreda@gmail.com> writes:
> > >In Intel, asm guys tell diferent places for code and data are better for sp=
> > >eed, but I don't test this.
> > 
> > Look at slide 12 of
> > <http://www.complang.tuwien.ac.at/anton/euroforth/ef09/papers/ertl-slides.pdf>.
> > You can see that bigForth is slower than Gforth for cd16sim (by more
> > than a factor of 4), brew, and lexex.  The reason is that bigForth
> > mixes native code and data, and Gforth keeps them separate.
> > 
> > If your system generates native code, keep the native code separated
> > from the data.  However, AFAIK Chris Curl's system uses some
> > interpreted virtual machine code.  Mixing that with the data does not
> > hurt, on the first order, and the system becomes simpler.
> > 
> > - 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/
> 
> Yes, mine is not native code. However, I do hope to get to the point where 
> I am able to generate native code.

Even with a threaded system, it is best to keep the threaded-code separate from the headers --- this way the data-cache contains threaded-code and not headers which are rarely accessed (certainly not at run-time).

Note that ITC should be faster than DTC on a cached system. In DTC you have DOCOLON machine-code in front of every colon words, and none of those share a cache-line with the others. In ITC there is only one DOCOLON that all of the colon words use, and it stays in the code-cache continuously.

This last point is surprising to many Forthers with experience on the 16-bit x86. In the old days of MS-DOS, DTC was significantly faster than ITC because it was shorter code and had one less memory-access (this is one of the many reasons for why UR/Forth was significantly faster than PolyForth). This is not true on modern processors with a code-cache however --- as I said above, ITC should generally be faster --- Straight Forth is ITC.

[toc] | [prev] | [next] | [standalone]

#49289

From"Elizabeth D. Rather" <erather@forth.com>
Date2016-07-21 12:40 -1000
Message-ID<weSdnZmlaO_A0gzKnZ2dnUU7-fvNnZ2d@supernews.com>
In reply to#49278
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

-- 
==================================================
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]

#49292

Fromhughaguilar96@gmail.com
Date2016-07-21 17:07 -0700
Message-ID<1310374b-be2c-4cd8-ae3e-b9f206c9fe60@googlegroups.com>
In reply to#49289
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. What we have now is ambiguity, because the programmer doesn't know if the HERE value changes or not (for example, when CONSTANT is executed) and his programs work on some ANS-Forth systems but not on other ANS-Forth systems. Also, the advantage of separating code and data is faster speed. You never have data in a code-cache line or code in a data cache-line, which is obviously going to slow down the system considerably.

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.

[toc] | [prev] | [next] | [standalone]

#49296

FromCecil Bayona <cbayona@cbayona.com>
Date2016-07-21 19:32 -0500
Message-ID<nmrpii$ksl$1@dont-email.me>
In reply to#49292
On 7/21/2016 7: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. What we have now is ambiguity, because the programmer doesn't know if the HERE value changes or not (for example, when CONSTANT is executed) and his programs work on some ANS-Forth systems but not on other ANS-Forth systems. Also, the advantage of separating code and data is faster speed. You never have data in a code-cache line or code in a data cache-line, which is obviously going to slow down the system considerably.
>
> 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.
>
Besides the speed advantage, as time progresses more of the OSes and CPU 
chips are implementing protection of the code area from data writes, 
it's an option now but its easy to see that in the future  writing to 
the code area will be prohibited so having separate data headers and 
code headers can prevent future issues.

This will be done as a safety issue because so many system hijacking 
malware/viruses is done by buffer overflows which ends up changing the 
software code. That can' happen if code and data are separate, and the 
code area is protected.

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#49297

FromPaul Rubin <no.email@nospam.invalid>
Date2016-07-21 17:40 -0700
Message-ID<8737n2cxnv.fsf@jester.gateway.pace.com>
In reply to#49296
Cecil Bayona <cbayona@cbayona.com> writes:
> its easy to see that in the future writing to the code area will be
> prohibited

No I don't think it will be prohibited in the forseeable future.  Too
much code depends on JIT compilers.

[toc] | [prev] | [next] | [standalone]

#49299

Fromhughaguilar96@gmail.com
Date2016-07-21 17:50 -0700
Message-ID<299c2cf4-7664-43df-8144-7dd959106a0a@googlegroups.com>
In reply to#49297
On Thursday, July 21, 2016 at 5:40:53 PM UTC-7, Paul Rubin wrote:
> Cecil Bayona <cbayona@cbayona.com> writes:
> > its easy to see that in the future writing to the code area will be
> > prohibited
> 
> No I don't think it will be prohibited in the forseeable future.  Too
> much code depends on JIT compilers.

What happens when you write to memory that has already been loaded into the code-cache? I've never been clear on this and it seems like an ambiguous aspect of the processor --- I couldn't find an answer in the Intel books; maybe I didn't look hard enough though --- I wouldn't try a stunt like that and expect it to work on every processor.

[toc] | [prev] | [next] | [standalone]

#49300

FromCecil Bayona <cbayona@cbayona.com>
Date2016-07-21 19:53 -0500
Message-ID<nmrqph$neg$1@dont-email.me>
In reply to#49299
On 7/21/2016 7:50 PM, hughaguilar96@gmail.com wrote:
> On Thursday, July 21, 2016 at 5:40:53 PM UTC-7, Paul Rubin wrote:
>> Cecil Bayona <cbayona@cbayona.com> writes:
>>> its easy to see that in the future writing to the code area will be
>>> prohibited
>>
>> No I don't think it will be prohibited in the forseeable future.  Too
>> much code depends on JIT compilers.
>
> What happens when you write to memory that has already been loaded into the code-cache? I've never been clear on this and it seems like an ambiguous aspect of the processor --- I couldn't find an answer in the Intel books; maybe I didn't look hard enough though --- I wouldn't try a stunt like that and expect it to work on every processor.
>
The cache area written to is updated or flushed depending on the CPU 
hardware.

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#49309

FromRon Aaron <rambamist@gmail.com>
Date2016-07-22 06:58 +0300
Message-ID<nms5ko$f0u$2@dont-email.me>
In reply to#49299

On 22/07/2016 03:50, hughaguilar96@gmail.com wrote:

> 
> What happens when you write to memory that has already been loaded into the code-cache? 

You generally need to inform the CPU that it needs to refresh its caches.

[toc] | [prev] | [next] | [standalone]

#49307

FromRon Aaron <rambamist@gmail.com>
Date2016-07-22 06:54 +0300
Message-ID<nms5cu$f0u$1@dont-email.me>
In reply to#49296

On 22/07/2016 03:32, Cecil Bayona wrote:
> On 7/21/2016 7:07 PM, hughaguilar96@gmail.com wrote:

> Besides the speed advantage, as time progresses more of the OSes and CPU
> chips are implementing protection of the code area from data writes,
> it's an option now but its easy to see that in the future  writing to
> the code area will be prohibited so having separate data headers and
> code headers can prevent future issues.

Doubtful it will be prohibited since it is necessary for loading code
from external sources, JIT, etc.

However, it is good practice to separate data and code on modern
processors (not just Intel ones), particularly writable data -- since
writing to data which shares cache with code will cause a delay while
the CPU make sure the cached data are consistent.  You avoid that
penalty simply by not putting data in with code (yes, you must do it
sometimes).

[toc] | [prev] | [next] | [standalone]

#49314

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2016-07-22 06:48 +0000
Message-ID<2016Jul22.084816@mips.complang.tuwien.ac.at>
In reply to#49307
Ron Aaron <rambamist@gmail.com> writes:
>However, it is good practice to separate data and code on modern
>processors (not just Intel ones)

Yes, AMD ones, too; and IBM 360 successors.  I think that's pretty
much all.  The others require software intervention to ensure cache
consistency; the upside is that the same memory can be in both the
I-cache and the D-cache, and storing into the D-cache will not throw
the line out of the I-cache; it will not be up-to-date, but for the
false sharing that is under discussion here that does not hurt.

- 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]

#49316

Fromhughaguilar96@gmail.com
Date2016-07-22 00:19 -0700
Message-ID<b3c00958-25c8-45ae-9972-67e077c74741@googlegroups.com>
In reply to#49314
On Thursday, July 21, 2016 at 11:58:44 PM UTC-7, Anton Ertl wrote:
> Ron Aaron <rambamist@gmail.com> writes:
> >However, it is good practice to separate data and code on modern
> >processors (not just Intel ones)
> 
> Yes, AMD ones, too; and IBM 360 successors.  I think that's pretty
> much all.  The others require software intervention to ensure cache
> consistency; the upside is that the same memory can be in both the
> I-cache and the D-cache, and storing into the D-cache will not throw
> the line out of the I-cache; it will not be up-to-date, but for the
> false sharing that is under discussion here that does not hurt.

All modern assemblers separate data and code --- this has been true going back to the late 1980s --- in those days, the leading-edge processors (i8086, MC68000) separated data and code, whereas the trailing-edge processors (6502, Z80, 6809) intermixed data and code. Actually, the IBM360 separated data and code, and that goes back to the 1960s --- it was quite expensive though --- it wasn't until the 1980s that this kind of technology reached the personal-computer world.

It is depressing to me that a basic topic such as this has to be debated on comp.lang.forth --- this was well-known when I was a teenager --- nobody has an excuse to not know this in the year 2016.

[toc] | [prev] | [next] | [standalone]

#49317

FromCecil Bayona <cbayona@cbayona.com>
Date2016-07-22 02:33 -0500
Message-ID<nmsi8l$fkb$1@dont-email.me>
In reply to#49316
On 7/22/2016 2:19 AM, hughaguilar96@gmail.com wrote:
> On Thursday, July 21, 2016 at 11:58:44 PM UTC-7, Anton Ertl wrote:
>> Ron Aaron <rambamist@gmail.com> writes:
>>> However, it is good practice to separate data and code on modern
>>> processors (not just Intel ones)
>>
>> Yes, AMD ones, too; and IBM 360 successors.  I think that's pretty
>> much all.  The others require software intervention to ensure cache
>> consistency; the upside is that the same memory can be in both the
>> I-cache and the D-cache, and storing into the D-cache will not throw
>> the line out of the I-cache; it will not be up-to-date, but for the
>> false sharing that is under discussion here that does not hurt.
>
> All modern assemblers separate data and code --- this has been true going back to the late 1980s --- in those days, the leading-edge processors (i8086, MC68000) separated data and code, whereas the trailing-edge processors (6502, Z80, 6809) intermixed data and code. Actually, the IBM360 separated data and code, and that goes back to the 1960s --- it was quite expensive though --- it wasn't until the 1980s that this kind of technology reached the personal-computer world.
>
> It is depressing to me that a basic topic such as this has to be debated on comp.lang.forth --- this was well-known when I was a teenager --- nobody has an excuse to not know this in the year 2016.
>
Actually the Z80 assemblers had facilities to separate code and data, 
some didn't use it and lumped everything together but that was the 
programmers choice.

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#49318

FromRon Aaron <rambamist@gmail.com>
Date2016-07-22 10:45 +0300
Message-ID<nmsitv$hjk$1@dont-email.me>
In reply to#49316

On 22/07/2016 10:19, hughaguilar96@gmail.com wrote:

> All modern assemblers separate data and code --- this has been true going back to the late 1980s

Wrong.  You can easily insert data into the code (text) section in
modern assemblers.  Similarly you can define code in the data section.

What is correct is that assemblers make it easy to separate data and
code.  They do not, generally, enforce any such separation.

[toc] | [prev] | [next] | [standalone]

#49303

FromBrad Eckert <hwfwguy@gmail.com>
Date2016-07-21 19:41 -0700
Message-ID<c4b571a1-70c9-405a-9c6e-b84560f4a91f@googlegroups.com>
In reply to#49292
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. Does this interleaving make much difference on a PC? Caches keep getting bigger to accommodate monster bloatware. SwiftForth is not VFX and will never be VFX. Horses for courses, as Wil Baden liked to say.

The ANS Standard is 22 years old. In the intervening 22 years, has anyone proposed an alternative standard? Perhaps a cleaner subset that ANS can ride on top of, something to bridge the embedded and desktop worlds.

You are aware that Elizabeth is 75 and still programming in Forth. My mom is 72 and still banging out website code in MS Access. Because they like it. I hope I'm still programming decent code when I'm that age.

-Brad

[toc] | [prev] | [next] | [standalone]

#49306

Fromhughaguilar96@gmail.com
Date2016-07-21 20:52 -0700
Message-ID<9e811fc2-2463-45a9-b85c-10f57ebb277e@googlegroups.com>
In reply to#49303
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 that Elizabeth Rather has never written a Forth program in her life. I wasn't aware of which employee of Forth Inc. did write SwiftForth. This Rick Van Norman apparently is a crappy programmer --- he did a terrible job --- I hope he got paid well.

> Does this interleaving make much difference on a PC? Caches keep getting bigger to accommodate monster bloatware. 

The code-cache and data-cache on the 64-bit x86 is 32KB each --- same as on the 32-bit x86 --- each cache-line is 16 bytes.

> The ANS Standard is 22 years old. In the intervening 22 years, has anyone proposed an alternative standard? Perhaps a cleaner subset that ANS can ride on top of, something to bridge the embedded and desktop worlds.

You can't have ANS-Forth with its ambiguity being part of any Standard that doesn't have ambiguity! 

Also, I have said many times that it is a mistake for ANS-Forth to be a Standard for both desktop-computers and micro-controllers. This made some sense in 1984 when the same processors (the 6502 and Z80) were used for both, but it did not make sense in 1994, and it becomes a worse idea with every year. Straight Forth is only for desktop-computers. The "killer app" for Straight Forth is a cross-compiler to LFTforth which is for micro-controllers. Straight Forth and LFTforth aren't compatible at all. LFTforth is really Raimond Dragomir's thing, not mine, as he has a lot more experience with micro-controllers than I do.

> You are aware that Elizabeth is 75 and still programming in Forth. 

Elizabeth Rather was stupid in 1994 when she wrote ANS-Forth, and she was stupid in 1974 when she was a COBOL programmer --- she has been stupid her entire life --- age has nothing to do with it.

Also, Elizabeth Rather is not "still programming in Forth" --- she has never written a Forth program in her life --- the only code she ever posts on comp.lang.forth (for as long as comp.lang.forth has existed) are code snippets copied directly out of the "Starting Forth" book.

[toc] | [prev] | [next] | [standalone]

#49330

Fromrickman <gnuarm@gmail.com>
Date2016-07-22 11:22 -0400
Message-ID<nmtdnc$92d$2@dont-email.me>
In reply to#49306
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.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

Page 1 of 9  [1] 2 3 4 5 6 7 8 9  Next page →

Back to top | Article view | comp.lang.forth

csiph-web