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 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2016-08-02 07:24 -0700 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <3e2b00ef-bd1a-4edb-ae17-d259c9bb77f0@googlegroups.com> |
| In reply to | #49727 |
On Tuesday, 2 August 2016 12:57:20 UTC+1, Coos Haak wrote: > Op Tue, 2 Aug 2016 00:34:27 -0700 (PDT) schreef Julian Fondren: > > > Welp, looks like quotations are a bad idea. Discarded. > > > > > > ** five minutes later ** > > > > > > Hey guys look at this cool thing with return stack stuff: > > > > : call ( a -- ) >r ; > > : with-base ( n -- ) > > base @ swap base ! ( origbase ) > > r> swap >r ( continuation ) > > ['] call catch > > r> base ! throw ; > > : .hex ( n -- ) > > 16 with-base . ; > > > > Words like WITH-BASE don't stand out well in longer code. > > > > If only there were some more readable way to do this :( > > > > > > -- Julian > > What about this: > > : with-base ( n xt -- ) > swap base @ >r base ! > catch > r> base ! > throw > ; > > : .hex ( n -- ) > 16 ['] . with-base > ; > > As a bonus, it works also outside a definition: > 4095 16 ' . with-base FFF ok > No (non-standard) return address manipulation > > groet Coos Why so complicated? : .hex ( n -- ) base @ swap 16 base ! . base ! ;
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-08-02 07:36 -0700 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <1aa226ff-e4a9-4690-93fa-0e77010006f2@googlegroups.com> |
| In reply to | #49734 |
On Tuesday, August 2, 2016 at 9:24:32 AM UTC-5, Mark Wills wrote: > Why so complicated? > > : .hex ( n -- ) base @ swap 16 base ! . base ! ; Because the point isn't to write .HEX The point is to write WITH-BASE WITH-BASE restores the original base even on error.
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2016-08-02 12:14 -0700 |
| Subject | Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) |
| Message-ID | <ff3042e6-28ed-445c-a32b-a944cb411e49@googlegroups.com> |
| In reply to | #49724 |
On Tuesday, August 2, 2016 at 10:34:28 AM UTC+3, Julian Fondren wrote: > Welp, looks like quotations are a bad idea. Discarded. > > > ** five minutes later ** > > > Hey guys look at this cool thing with return stack stuff: > > : call ( a -- ) >r ; > : with-base ( n -- ) > base @ swap base ! ( origbase ) > r> swap >r ( continuation ) > ['] call catch > r> base ! throw ; > : .hex ( n -- ) > 16 with-base . ; > > Words like WITH-BASE don't stand out well in longer code. > > If only there were some more readable way to do this :( > > > -- Julian Hi! Or use continuations at compile-time: : ends r> ; : end >r ; immediate : addr-with postpone dup postpone dup postpone >r postpone @ postpone >r postpone ! ends> postpone r> postpone r> postpone ! ; immediate usage: : test base addr-with ['] u. catch end throw ; 32 16 test .s 20 <0> ok see test : test useraddr <112> dup dup >r @ >r ! 140139968134760 catch r> r> ! throw ; ok Have a nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2016-08-02 12:17 -0700 |
| Subject | Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) |
| Message-ID | <e4937b42-48ff-4ee6-90e3-9f85f9ea6305@googlegroups.com> |
| In reply to | #49745 |
On Tuesday, August 2, 2016 at 10:14:42 PM UTC+3, humptydumpty wrote: > On Tuesday, August 2, 2016 at 10:34:28 AM UTC+3, Julian Fondren wrote: > > Welp, looks like quotations are a bad idea. Discarded. > > > > > > ** five minutes later ** > > > > > > Hey guys look at this cool thing with return stack stuff: > > > > : call ( a -- ) >r ; > > : with-base ( n -- ) > > base @ swap base ! ( origbase ) > > r> swap >r ( continuation ) > > ['] call catch > > r> base ! throw ; > > : .hex ( n -- ) > > 16 with-base . ; > > > > Words like WITH-BASE don't stand out well in longer code. > > > > If only there were some more readable way to do this :( > > > > > > -- Julian > > Hi! > > Or use continuations at compile-time: > > : ends r> ; > : end >r ; immediate > : addr-with postpone dup postpone dup postpone >r postpone @ postpone >r postpone ! ends> postpone r> postpone r> postpone ! ; immediate > > usage: > > : test base addr-with ['] u. catch end throw ; > > 32 16 test .s 20 <0> ok see test > : test > useraddr <112> dup dup >r @ >r ! 140139968134760 catch r> r> ! throw ; ok > > Have a nice day, > humptydumpty > : ends r> ; > : end >r ; immediate : ends> r> ; : end >r ; immediate Have a nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-08-06 13:35 +1000 |
| Subject | Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) |
| Message-ID | <no3lto$f9s$1@gioia.aioe.org> |
| In reply to | #49722 |
Anton Ertl wrote: > "HAA" <someone@microsoft.com> writes: > >Anton Ertl wrote: > >> "HAA" <someone@microsoft.com> writes: > >> >Consider this, which is less complicated than a cross-compiler. > >> >Your dictionary is separated into compiler and application words. > >> >Words may be defined in either space and be referenced by either. > >> >Without quotations this is no problem ... > >> > > >> > application \ switch to application space > >> > > >> > : foo1 ... ; \ run-time code for definer foo2 > >> > > >> > compiler \ switch to compiler space > >> > > >> > : foo2 ['] foo1 <does-create> ... ; \ works like CREATE DOES> > >> > > >> > : foo3 ... ; \ a subroutine in compiler space > >> > > >> > : foo4 ... foo3 ... ; \ a routine in compiler space > >> > > >> > application > >> > > >> >You decide you want foo1 and foo3 as quotations. How do you ensure > >> >their code, resulting xt's, and parent words get compiled into the correct > >> >dictionary spaces? > >> > >> You can do it for top-level definitions, by introducing COMPILER and > >> APPLICATION, so why should you be unable to do it for quotations, > >> maybe as follows: > >> > >> compiler > >> : foo2 application[: ... ;] <does-create ... ; > >> .... > >> > >> If you don't like this syntax, I am sure you have no problem coming up > >> with a better one. > >> > >> - anton > > > >It's more than syntax - it's a new word. > > So are APPLICATION and COMPILER They are existing words. Win32Forth has equivalents. > But if you prefer, you can also > define APPLICATION, COMPILER, [:, and ;] such that > > : foo2 [ application ] [: ... ;] <does-create ... ; > compiler > > works. The challenge was to make quotations work for every situation. It's not enough to direct [: where to begin a definition, ;] must be directed where to revert. The effort becomes such that nobody would bother when a regular named definition does the job without fuss.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2016-08-02 07:20 -0700 |
| Subject | Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) |
| Message-ID | <af776dbd-8e4f-40cb-ab38-4af298b3f03f@googlegroups.com> |
| In reply to | #49721 |
On Tuesday, 2 August 2016 01:42:23 UTC+1, HAA wrote: > Anton Ertl wrote: > > "HAA" <someone@microsoft.com> writes: > > >Consider this, which is less complicated than a cross-compiler. > > >Your dictionary is separated into compiler and application words. > > >Words may be defined in either space and be referenced by either. > > >Without quotations this is no problem ... > > > > > > application \ switch to application space > > > > > > : foo1 ... ; \ run-time code for definer foo2 > > > > > > compiler \ switch to compiler space > > > > > > : foo2 ['] foo1 <does-create> ... ; \ works like CREATE DOES> > > > > > > : foo3 ... ; \ a subroutine in compiler space > > > > > > : foo4 ... foo3 ... ; \ a routine in compiler space > > > > > > application > > > > > >You decide you want foo1 and foo3 as quotations. How do you ensure > > >their code, resulting xt's, and parent words get compiled into the correct > > >dictionary spaces? > > > > You can do it for top-level definitions, by introducing COMPILER and > > APPLICATION, so why should you be unable to do it for quotations, > > maybe as follows: > > > > compiler > > : foo2 application[: ... ;] <does-create ... ; > > .... > > > > If you don't like this syntax, I am sure you have no problem coming up > > with a better one. > > > > - anton > > It's more than syntax - it's a new word. The point is that quotations > are more than nameless words. They limit functionality. If the end > goal is removing a name from a word, forth had that capability > decades ago e.g. unlinking names. > > I supported Hugh's bid that quotations should access the parent's > locals. I dislike locals as much as quotations but at least it would > have given quotations one advantage over regular words. Tend to agree. Quotations. Can't see why you can't just write a colon definition and refer to it, as we have done for forty years, with all the advantages (locals) that one gets. Isn't it just trying to be clever for the sake of being clever? Can we open an (obsolete) serial port in standard Forth yet?
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-08-02 13:43 -0500 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <_IWdnS-okKNKdD3KnZ2dnUU78KnNnZ2d@supernews.com> |
| In reply to | #49733 |
Mark Wills <markwills1970@gmail.com> wrote: > > Tend to agree. Quotations. Can't see why you can't just write a colon > definition and refer to it, as we have done for forty years, with all > the advantages (locals) that one gets. > > Isn't it just trying to be clever for the sake of being clever? It's purely a notational convenience; but notation is a tool of thought: By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race. A.N. Whitehead I'm opposed to adding syntax for its own sake, but this extra expressiveness seems to be a reasonable tradeoff, especially as a Forth could provide quotations as optional source. > Can we open an (obsolete) serial port in standard Forth yet? No, any more than you can in any standard language, as discussed, and it's not that great an idea anyway, as also discussed. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-07-28 09:19 -1000 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <s9adnZ925JJTxwfKnZ2dnUU7-UfNnZ2d@supernews.com> |
| In reply to | #49607 |
On 7/27/16 11:17 PM, Anton Ertl wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> On 7/27/16 3:08 AM, HAA wrote: >>> Elizabeth D. Rather wrote: >>>> Historical note: ;: was Chuck's original name for the structure which >>>> for many years now has been CREATE DOES> (by separating the creation >>>> from the instance behaviors you get more flexibility). > ... >> I don't really remember the details, but as I recall it didn't have the >> separate CREATE step, > > That's interesting, because I have been thinking about how to deal > with the problem that Forth systems compiling to flash have > difficulties with CREATE...DOES>, because DOES> overwrites a field > that ideally would lie in flash (and which we don't want to > overwrite). That's one of the many charms of using a cross-compiler. It constructs a complete image in the host's RAM that is downloaded to the target flash before opening an interactive link for testing. It offers all the advantages of interactive development that Forthers love while managing the trickiness of dealing with flash and other issues. 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-07-29 05:15 +0000 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <2016Jul29.071534@mips.complang.tuwien.ac.at> |
| In reply to | #49623 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 7/27/16 11:17 PM, Anton Ertl wrote:
>> That's interesting, because I have been thinking about how to deal
>> with the problem that Forth systems compiling to flash have
>> difficulties with CREATE...DOES>, because DOES> overwrites a field
>> that ideally would lie in flash (and which we don't want to
>> overwrite).
>
>That's one of the many charms of using a cross-compiler. It constructs a
>complete image in the host's RAM that is downloaded to the target flash
>before opening an interactive link for testing. It offers all the
>advantages of interactive development that Forthers love while managing
>the trickiness of dealing with flash and other issues.
There is no trickiness of dealing with flash. Write once, and
everything is fine. We just need interfaces that fit this
restriction. Most of Forth is fine, but DOES> and IMMEDIATE have a
model of first defining a word in one way, and later changing it to be
different, and that does not go well with the flash restriction.
Words are only used in their final form (except for proof-of-concept
examples such as the one below), so this property of the interface is
unnecessary, and an interface that does not have this property would
not take any capability away that is really being used.
As for the charms of using a cross-compiler, my experience is
different. Cross-compiling sucks, big time. Of course it is possible
to do better than the Gforth cross-compiler, but some limitations of
cross-compilers are fundamental, not implementation issues: In
particular, in Forth there is no hard line between compile-time and
run-time; programs can run words during what the programmer thinks of
as compilation (e.g., for initialization, or as macros), and compile
code during what the programmer thinks of as run-time.
Cross-compilers restrict that and demand that we draw a hard line, and
identify what is run on the host, and (if they allow it at all) what
is compiled in the target.
And if they compile to flash, they have the same problem with DOES> as
compilers running on the target, e.g., the following will not work
with headers in flash:
\ on the host
: recital ( -- )
." Your daddy is standing on the table. Ask him 'WHY?' "
does> drop ." To change the light bulb."
does> drop ." Because it's burned out."
does> drop ." Because it was old."
does> drop ." Because we put it in there a long time ago."
does> drop ." Because it was dark!"
does> drop ." Because it was night time!!"
does> drop ." Stop saying WHY?"
does> drop ." Because it's driving me crazy."
does> drop ." Just let me change this light bulb!"
;
create why?
\ on the target
recital
why?
why?
why?
why?
why?
why?
why?
why?
why?
- 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-07-28 21:50 -1000 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <LZ6dnT6aWvwolwbKnZ2dnUU7-UXNnZ2d@supernews.com> |
| In reply to | #49637 |
On 7/28/16 7:15 PM, Anton Ertl wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> On 7/27/16 11:17 PM, Anton Ertl wrote: >>> That's interesting, because I have been thinking about how to deal >>> with the problem that Forth systems compiling to flash have >>> difficulties with CREATE...DOES>, because DOES> overwrites a field >>> that ideally would lie in flash (and which we don't want to >>> overwrite). >> >> That's one of the many charms of using a cross-compiler. It constructs a >> complete image in the host's RAM that is downloaded to the target flash >> before opening an interactive link for testing. It offers all the >> advantages of interactive development that Forthers love while managing >> the trickiness of dealing with flash and other issues. > > There is no trickiness of dealing with flash. Write once, and > everything is fine. We just need interfaces that fit this > restriction. Most of Forth is fine, but DOES> and IMMEDIATE have a > model of first defining a word in one way, and later changing it to be > different, and that does not go well with the flash restriction. > Words are only used in their final form (except for proof-of-concept > examples such as the one below), so this property of the interface is > unnecessary, and an interface that does not have this property would > not take any capability away that is really being used. > > As for the charms of using a cross-compiler, my experience is > different. Cross-compiling sucks, big time. Of course it is possible > to do better than the Gforth cross-compiler, but some limitations of > cross-compilers are fundamental, not implementation issues: In > particular, in Forth there is no hard line between compile-time and > run-time; programs can run words during what the programmer thinks of > as compilation (e.g., for initialization, or as macros), and compile > code during what the programmer thinks of as run-time. > Cross-compilers restrict that and demand that we draw a hard line, and > identify what is run on the host, and (if they allow it at all) what > is compiled in the target. Have you ever actually tried SwiftX? Yes, one has to be aware of compile time vs. run time, but there's a surprising amount of stuff you can do interactively during testing, and the protocols are extremely simple. > And if they compile to flash, they have the same problem with DOES> as > compilers running on the target, e.g., the following will not work > with headers in flash: > > \ on the host > : recital ( -- ) > ." Your daddy is standing on the table. Ask him 'WHY?' " > does> drop ." To change the light bulb." > does> drop ." Because it's burned out." > does> drop ." Because it was old." > does> drop ." Because we put it in there a long time ago." > does> drop ." Because it was dark!" > does> drop ." Because it was night time!!" > does> drop ." Stop saying WHY?" > does> drop ." Because it's driving me crazy." > does> drop ." Just let me change this light bulb!" > ; > > create why? > > \ on the target > recital > why? > why? > why? > why? > why? > why? > why? > why? > why? Have you ever actually seen a requirement for something like this? In an embedded application? Didn't think so. 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-07-29 08:24 +0000 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <2016Jul29.102446@mips.complang.tuwien.ac.at> |
| In reply to | #49639 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 7/28/16 7:15 PM, Anton Ertl wrote:
>> As for the charms of using a cross-compiler, my experience is
>> different. Cross-compiling sucks, big time. Of course it is possible
>> to do better than the Gforth cross-compiler, but some limitations of
>> cross-compilers are fundamental, not implementation issues: In
>> particular, in Forth there is no hard line between compile-time and
>> run-time; programs can run words during what the programmer thinks of
>> as compilation (e.g., for initialization, or as macros), and compile
>> code during what the programmer thinks of as run-time.
>> Cross-compilers restrict that and demand that we draw a hard line, and
>> identify what is run on the host, and (if they allow it at all) what
>> is compiled in the target.
>
>Have you ever actually tried SwiftX? Yes, one has to be aware of compile
>time vs. run time, but there's a surprising amount of stuff you can do
>interactively during testing, and the protocols are extremely simple.
No, I have not. Why should I? I have a real Forth system, no need
for a substitute, however close it may come to the real thing.
>> And if they compile to flash, they have the same problem with DOES> as
>> compilers running on the target, e.g., the following will not work
>> with headers in flash:
>>
>> \ on the host
>> : recital ( -- )
>> ." Your daddy is standing on the table. Ask him 'WHY?' "
>> does> drop ." To change the light bulb."
>> does> drop ." Because it's burned out."
>> does> drop ." Because it was old."
>> does> drop ." Because we put it in there a long time ago."
>> does> drop ." Because it was dark!"
>> does> drop ." Because it was night time!!"
>> does> drop ." Stop saying WHY?"
>> does> drop ." Because it's driving me crazy."
>> does> drop ." Just let me change this light bulb!"
>> ;
>>
>> create why?
>>
>> \ on the target
>> recital
>> why?
>> why?
>> why?
>> why?
>> why?
>> why?
>> why?
>> why?
>> why?
>
>Have you ever actually seen a requirement for something like this?
No, and that's my point. We don't need this capability of DOES>, and
it causes implementation problems, so let's go for an interface that
provides what we need and can be implemented without contortions, even
on systems that compile directly to flash.
- 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 | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-07-29 10:08 -0700 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <4d5333e7-95e0-4e18-a351-509d24755629@googlegroups.com> |
| In reply to | #49637 |
On Thursday, July 28, 2016 at 10:51:48 PM UTC-7, Anton Ertl wrote: > We just need interfaces that fit this > restriction. Most of Forth is fine, but DOES> and IMMEDIATE have a > model of first defining a word in one way, and later changing it to be > different, and that does not go well with the flash restriction. It's not necessarily a restriction. When using flash, you can change a 1 to a 0 but not vice versa. So, it's feasible for CREATE to have a field of FFh bytes that's resolved by DOES>. Likewise, a word's header could have its immediate bit cleared by IMMEDIATE (default = 1). For that matter, forward branches such as IF would start off as FFFFh until resolved by THEN. The speed of modern communication interfaces and capacity of modern embedded MCUs seem to be bringing us back around to the feasibility of target-hosted Forths. The host ends up being mostly a dumb terminal with file upload capability.
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-07-29 15:06 -0700 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <ef4f3080-05a5-4847-8f05-f2e13b05783e@googlegroups.com> |
| In reply to | #49658 |
On Friday, July 29, 2016 at 10:08:45 AM UTC-7, Brad Eckert wrote: > On Thursday, July 28, 2016 at 10:51:48 PM UTC-7, Anton Ertl wrote: > > We just need interfaces that fit this > > restriction. Most of Forth is fine, but DOES> and IMMEDIATE have a > > model of first defining a word in one way, and later changing it to be > > different, and that does not go well with the flash restriction. > > It's not necessarily a restriction. When using flash, you can change a 1 to a 0 but not vice versa. So, it's feasible for CREATE to have a field of FFh bytes that's resolved by DOES>. Likewise, a word's header could have its immediate bit cleared by IMMEDIATE (default = 1). For that matter, forward branches such as IF would start off as FFFFh until resolved by THEN. > > The speed of modern communication interfaces and capacity of modern embedded MCUs seem to be bringing us back around to the feasibility of target-hosted Forths. The host ends up being mostly a dumb terminal with file upload capability. Of course, with cross compilation you can bloat the header space as much as you want with glossary text, links to source code, etc. Adding HTML source code translation would be a nice added feature.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-07-30 06:22 +0000 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <2016Jul30.082202@mips.complang.tuwien.ac.at> |
| In reply to | #49658 |
Brad Eckert <hwfwguy@gmail.com> writes:
>On Thursday, July 28, 2016 at 10:51:48 PM UTC-7, Anton Ertl wrote:
>> We just need interfaces that fit this
>> restriction. Most of Forth is fine, but DOES> and IMMEDIATE have a
>> model of first defining a word in one way, and later changing it to be
>> different, and that does not go well with the flash restriction.
>
>It's not necessarily a restriction. When using flash, you can change a 1 to=
> a 0 but not vice versa.
That is a restriction. Also, from what I read (IIRC Bernd Paysan
posted that here), the (or at least some) manufacturers only allow
writing once after each erase cycle, so changing a cell bit-by-bit is
not guaranteed to work.
>So, it's feasible for CREATE to have a field of FF=
>h bytes that's resolved by DOES>.
Yes, that's the trick that's being used now. So they have to arrange
that a word with $f..f in its code field (or code field replacement)
actually pushes it's body address on the stack, which incurs extra
cost. And they still cannot use DOES> several times on the same word.
> Likewise, a word's header could have its =
>immediate bit cleared by IMMEDIATE (default =3D 1).
If you can write a cell only once, you have to keep the immediate bit
in a cell by itself.
> For that matter, forwar=
>d branches such as IF would start off as FFFFh until resolved by THEN.
That's easy: just don't write to the target-address cell until you
actually know the target address. You cannot use the classical LEAVE
trick, though.
- 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-07-30 01:07 -0700 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <87k2g38s6f.fsf@jester.gateway.pace.com> |
| In reply to | #49671 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > If you can write a cell only once, you have to keep the immediate bit > in a cell by itself. Maybe you can use a ram cell to remember the immediate bit and other such bits, until the next definition comes along.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-30 01:30 -0700 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <3d7c8d55-5882-4245-9e0a-fc94fa70e567@googlegroups.com> |
| In reply to | #49676 |
On Saturday, July 30, 2016 at 1:07:53 AM UTC-7, Paul Rubin wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > > If you can write a cell only once, you have to keep the immediate bit > > in a cell by itself. > > Maybe you can use a ram cell to remember the immediate bit and other > such bits, until the next definition comes along. You guys don't know what you are talking about! The cross-compiler runs on the host computer, not on the target computer! The host computer is the big thing on your desk with the keyboard and monitor; it has gigabytes of RAM in it --- not to be confused with the target computer which is a small circuit-board; it has a few tens of kilobytes of RAM and a few hundred kilobytes of FLASH --- the first step toward being a cross-compiler writer is to figure out which is which.
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-07-30 10:17 -0700 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <a20216ef-6bbb-4737-a7bb-96955e78c2e6@googlegroups.com> |
| In reply to | #49671 |
On Friday, July 29, 2016 at 11:42:21 PM UTC-7, Anton Ertl wrote: > That is a restriction. Also, from what I read (IIRC Bernd Paysan > posted that here), the (or at least some) manufacturers only allow > writing once after each erase cycle, so changing a cell bit-by-bit is > not guaranteed to work. Yes, but guarantees are subject to sleight of hand. It's like saying RC4 is bad crypto. Yes, but with care it can be good. Bitwise writing of flash bytes, I understand, would have the restriction of "do not program twice" without much explanation of the physics of the flash in question. But I think the caution applies to writing two '0's twice, which overcharges the floating gate, which leads to possible read errors in adjacent cells and erasure problems. If you know the byte you're programming has '1' as its MSB, you could write 7Fh to clear the bit and none of the other floating gates in the byte get over-programmed. Of course, if you're using multilevel flash, with 4 levels of charge representing 2 bits, all bets are off. > >>So, it's feasible for CREATE to have a field of FFh >>bytes that's resolved by DOES>. > > Yes, that's the trick that's being used now. So they have to arrange > that a word with $f..f in its code field (or code field replacement) > actually pushes it's body address on the stack, which incurs extra > cost. And they still cannot use DOES> several times on the same word. > Good catch. DOES> needs to make sure the field is blank and throw an error if it's not. >> Likewise, a word's header could have its >>immediate bit cleared by IMMEDIATE (default = 1). > > If you can write a cell only once, you have to keep the immediate bit > in a cell by itself. A byte by itself, at least. And, who knows how long we will be using NOR flash? Another 10 to 20 years? RRAM will replace it and then these problems will go away.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-30 00:51 -0700 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <bd842399-e062-4f1e-a6a0-b3af166d253d@googlegroups.com> |
| In reply to | #49637 |
On Thursday, July 28, 2016 at 10:51:48 PM UTC-7, Anton Ertl wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: > >On 7/27/16 11:17 PM, Anton Ertl wrote: > >> That's interesting, because I have been thinking about how to deal > >> with the problem that Forth systems compiling to flash have > >> difficulties with CREATE...DOES>, because DOES> overwrites a field > >> that ideally would lie in flash (and which we don't want to > >> overwrite). > > > >That's one of the many charms of using a cross-compiler. It constructs a > >complete image in the host's RAM that is downloaded to the target flash > >before opening an interactive link for testing. It offers all the > >advantages of interactive development that Forthers love while managing > >the trickiness of dealing with flash and other issues. > > There is no trickiness of dealing with flash. Write once, and > everything is fine. We just need interfaces that fit this > restriction. Most of Forth is fine, but DOES> and IMMEDIATE have a > model of first defining a word in one way, and later changing it to be > different, and that does not go well with the flash restriction. > Words are only used in their final form (except for proof-of-concept > examples such as the one below), so this property of the interface is > unnecessary, and an interface that does not have this property would > not take any capability away that is really being used. What??? Elizabeth Rather was correct that the cross-compiler builds an image in the host memory (which is RAM) and then uploads this into the target computer --- the upload is done in one fell swoop, so the write-once limitation is not an issue --- the MiniForth predates the invention of FLASH and it used EPROMS, which are even more restrictive than FLASH. > As for the charms of using a cross-compiler, my experience is > different. Cross-compiling sucks, big time. Of course it is possible > to do better than the Gforth cross-compiler, but some limitations of > cross-compilers are fundamental, not implementation issues: In > particular, in Forth there is no hard line between compile-time and > run-time; programs can run words during what the programmer thinks of > as compilation (e.g., for initialization, or as macros), and compile > code during what the programmer thinks of as run-time. > Cross-compilers restrict that and demand that we draw a hard line, and > identify what is run on the host, and (if they allow it at all) what > is compiled in the target. My MFX didn't suck. I don't think you know very much about Forth cross-compilation --- I would even say that you suck at this --- what you describe as "fundamental limitations" are only a problem in your own head. Of course, there is going to be a distinction between words defined in HOST and words defined in TARG --- why do you consider this to be a problem? In MFX, all the TARG words had two versions of themselves (this was not "dual-xt" which sounds like nonsense to me; they were just separate words in separate vocabularies). On version was compiled into the target system and is what would execute at run-time. The other version was an IMMEDIATE word compiled into the host system and it executed at compile-time --- it generated the code in the target system to call that other version of itself. MFX was significantly easier to understand than ANS-Forth. In ANS-Forth, a word such as DUP may be an IMMEDIATE word that generates code. It also has to be a run-time word that does what it does (you need to have a run-time version in order to be able to tick it). So, what is DUP exactly? Is DUP only one thing, or is it two things, and if it is two things then how do you articulate which is which? Nobody knows! This is going to vary from one ANS-Forth system to another. By comparison, in MFX every word had two versions in two vocabularies as described above --- consistency is a big step toward understandability --- MFX was consistent throughout and easy to understand after you grasped the basic concept. In Gforth you have FIND return a different xt value some words (not all words) depending upon whether STATE is on or off at the time that FIND is executed. This is stupid!!! If you want FIND to return different xt values given the same word name, just set CONTEXT to different values before executing FIND --- this is easy and obvious --- this is the way Forth systems have always worked (FIG-Forth, Forth-79 and Forth-83) but only in ANS-Forth is your idiotic idea considered to be standard (the idea that FIND can return different xt values depending upon whether STATE is on or off at the time that FIND is executed). In a cross-compiler, colon changes CONTEXT and semicolon changes CONTEXT back again --- how obvious is this? --- very obvious! ANS-Forth is frustrating to me! Traditionally, Forth was simple and easy to understand (that is why most Forthers, including myself, got interested in Forth originally). Now ANS-Forth is a minder-binder that baffles the mind with its complexity --- all of this weird and gratuitous complexity is the product of language designers who don't understand the basic concepts of the language --- I knew basic concepts of Forth programming in 1994/1995 (when I wrote MFX) that the Forth-200x committee members seem to be unaware of in 2016.
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-07-22 05:20 -0700 |
| Message-ID | <8ade9c44-c041-4fe6-83c9-2d58bed130f2@googlegroups.com> |
| In reply to | #49278 |
So if I am understanding the discussion here, in many Forth implementations, the actual machine code is static (the system's primitives), and essentially everything else is data. The dictionary headers are obviously data, but the words' definitions are also really just data, in that they are just a list of identifiers for the primitives that are to be executed in order, along with whatever other data the primitives are to work on. Do I have that right? If so, why would an additional layer of separation be necessary or desired? And exactly what is split apart? In my little world, I am generating executable machine code (albeit for my VM's CPU). It currently uses the same "code" area for the ALLOTed data as well as VARIABLEs. I suppose separating code and data in my little world would mean having a 3rd, non-dictionary header area where VARIABLEs and ALLOTed memory would go. Then the "code" area would truly be all code, and for an embedded implementation, I could include the code and data areas, but not the dictionary headers. But in either case, keeping the dictionary headers out of the code area sounds like the right way to go. I guess for a more "traditional" Forth, separation would also have two data areas, one for the dictionary headers, the other for the data the primitives work on.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-07-22 13:06 +0000 |
| Message-ID | <2016Jul22.150632@mips.complang.tuwien.ac.at> |
| In reply to | #49322 |
Chris Curl <ccurl609@gmail.com> writes:
>So if I am understanding the discussion here, in many Forth implementations,
>the actual machine code is static (the system's primitives), and essentially
>everything else is data.
That would be a classic threaded-code implementation. The current
mainstream is to have a native-code implementation, though, e.g.,
SwiftForth, VFX, iForth, bigForth. Gforth is in-between: with
--no-dynamic your description fits, but in the default configuration
it generates native code at run-time (unless there is some red flag
that turns this off).
- 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]
Page 5 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