Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #42410 > unrolled thread
| Started by | Chris Curl <ccurl609@gmail.com> |
|---|---|
| First post | 2015-10-06 21:44 -0700 |
| Last post | 2016-01-02 02:25 -0800 |
| Articles | 20 on this page of 142 — 22 participants |
Back to article view | Back to comp.lang.forth
Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-10-06 21:44 -0700
Re: Boring for most of you, but I'm having fun ... :) Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-07 08:24 +0200
Re: Boring for most of you, but I'm having fun ... :) Mark Wills <markwills1970@gmail.com> - 2015-10-07 00:48 -0700
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-10-07 05:41 -0700
Re: Boring for most of you, but I'm having fun ... :) Jason Damisch <jasondamisch@yahoo.com> - 2015-10-07 12:05 -0700
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-27 18:04 -0800
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-27 18:12 -0800
Re: Boring for most of you, but I'm having fun ... :) Coos Haak <chforth@hccnet.nl> - 2015-12-28 13:33 +0100
Re: Boring for most of you, but I'm having fun ... :) humptydumpty <ouatubi@gmail.com> - 2015-12-28 00:54 -0800
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-28 12:32 -0800
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-28 12:43 -0800
Re: Boring for most of you, but I'm having fun ... :) Coos Haak <chforth@hccnet.nl> - 2015-12-28 22:13 +0100
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-28 13:21 -0800
Re: Boring for most of you, but I'm having fun ... :) Coos Haak <chforth@hccnet.nl> - 2015-12-28 23:47 +0100
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-28 13:13 -0800
Re: Boring for most of you, but I'm having fun ... :) Coos Haak <chforth@hccnet.nl> - 2015-12-28 23:50 +0100
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-28 15:33 -0800
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-28 15:37 -1000
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-28 22:18 -0800
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-28 22:31 -0800
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-28 23:30 -0800
Re: Boring for most of you, but I'm having fun ... :) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-29 02:47 -0800
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-29 08:19 -0800
Re: Boring for most of you, but I'm having fun ... :) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-29 08:26 -0800
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-29 09:34 -0800
Re: Boring for most of you, but I'm having fun ... :) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-29 10:22 -0800
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-30 12:15 +0000
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-30 08:26 -0800
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-31 16:10 +0000
Re: Boring for most of you, but I'm having fun ... :) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-30 08:35 -0800
Re: Boring for most of you, but I'm having fun ... :) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-30 08:51 -0800
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-30 12:21 -0800
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-30 10:46 -1000
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-30 13:15 -0800
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-30 13:11 -1000
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-30 15:35 -0800
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-30 15:00 -1000
Re: Boring for most of you, but I'm having fun ... :) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-31 00:13 -0800
Re: Boring for most of you, but I'm having fun ... :) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-12-31 10:09 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-31 13:46 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-31 13:56 +0000
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-31 17:24 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-01 14:23 +0000
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-01 20:24 +0000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-01 22:38 +0100
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-02 13:24 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-02 15:32 +0000
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-02 16:41 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-03 14:43 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-02 13:13 +0000
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-31 16:57 +0000
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-31 16:41 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-31 14:13 +0000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2015-12-31 22:27 +0100
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-01 13:38 +0000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-01 18:46 +0100
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2016-01-01 09:01 -1000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-01 22:35 +0100
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2016-01-01 08:39 -1000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-01 21:01 +0100
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-01 20:18 +0000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2015-12-31 22:19 +0100
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2016-01-01 21:43 -0800
Re: Boring for most of you, but I'm having fun ... :) Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-01 23:36 -0800
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-02 15:36 +0000
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2016-01-02 12:18 -0800
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-03 14:34 +0000
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-03 19:57 -0800
Re: Boring for most of you, but I'm having fun ... :) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-01-04 22:49 +0000
Re: Boring for most of you, but I'm having fun ... :) Julian Fondren <julian.fondren@gmail.com> - 2016-01-04 15:05 -0800
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-04 20:36 -0800
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-05 13:03 -0800
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2016-01-05 14:30 -0800
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-05 21:10 -0800
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-05 21:26 -0800
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2016-01-06 05:01 -0800
Re: Boring for most of you, but I'm having fun ... :) "WJ" <w_a_x_man@yahoo.com> - 2016-01-06 00:13 +0000
Re: Boring for most of you, but I'm having fun ... :) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-01-06 19:47 +0000
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-07 21:43 -0800
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2016-01-08 05:54 -0800
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-08 16:44 +0000
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-08 16:27 -0800
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-08 17:18 +0000
Re: Boring for most of you, but I'm having fun ... :) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-01-08 17:00 +0000
Re: Boring for most of you, but I'm having fun ... :) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-08 04:52 -0600
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-08 11:27 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-08 16:44 +0000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-08 21:17 +0100
Re: Boring for most of you, but I'm having fun ... :) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-01-08 16:57 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-08 17:06 +0000
Re: Boring for most of you, but I'm having fun ... :) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-01-08 20:24 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-09 17:05 +0000
Re: Boring for most of you, but I'm having fun ... :) stephen@mpeforth.com (Stephen Pelc) - 2016-01-08 20:02 +0000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-08 21:49 +0100
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-09 22:06 -0800
Re: Boring for most of you, but I'm having fun ... :) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-10 07:46 -0600
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-10 14:35 +0000
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-10 11:55 -0800
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-12 13:26 +0000
Re: Boring for most of you, but I'm having fun ... :) peter.m.falth@gmail.com - 2016-01-12 15:10 -0800
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2016-01-12 13:23 -1000
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-12 20:42 -0800
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-12 21:08 -0800
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-13 15:17 +0000
Re: Boring for most of you, but I'm having fun ... :) peter.m.falth@gmail.com - 2016-01-13 13:26 -0800
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-04 14:19 -0800
Re: Boring for most of you, but I'm having fun ... :) "WJ" <w_a_x_man@yahoo.com> - 2016-01-05 07:24 +0000
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-31 16:24 +0000
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-29 12:31 -1000
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-29 14:52 -0800
Re: Boring for most of you, but I'm having fun ... :) Coos Haak <chforth@hccnet.nl> - 2015-12-30 02:11 +0100
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-29 23:46 -1000
Re: Boring for most of you, but I'm having fun ... :) "HAA" <someone@microsoft.com> - 2015-12-30 21:25 +1100
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-30 09:17 -1000
Re: Boring for most of you, but I'm having fun ... :) "HAA" <someone@microsoft.com> - 2015-12-31 12:55 +1100
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-30 16:26 -1000
Re: Boring for most of you, but I'm having fun ... :) "HAA" <someone@microsoft.com> - 2016-01-02 12:30 +1100
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2016-01-01 16:31 -1000
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2016-01-01 21:31 -0800
Re: Boring for most of you, but I'm having fun ... :) stephen@mpeforth.com (Stephen Pelc) - 2016-01-02 12:04 +0000
Re: Boring for most of you, but I'm having fun ... :) stephen@mpeforth.com (Stephen Pelc) - 2015-12-31 12:04 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-31 13:31 +0000
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-31 08:50 -1000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-01 14:13 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-31 14:34 +0000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2015-12-31 22:39 +0100
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-01 10:05 +0000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-01 18:16 +0100
Re: Boring for most of you, but I'm having fun ... :) Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-01-01 17:49 +0000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-01 19:23 +0100
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2016-01-01 15:53 -0800
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-02 14:20 +0100
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-02 16:34 +0000
Re: Boring for most of you, but I'm having fun ... :) Mikael Nordman <oh2aun@gmail.com> - 2016-01-02 14:08 -0800
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2015-12-30 20:40 -0800
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-30 08:28 -0800
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-30 11:11 +0000
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-28 15:40 -0800
Re: Boring for most of you, but I'm having fun ... :) "HAA" <someone@microsoft.com> - 2015-12-30 10:14 +1100
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-28 15:35 -1000
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2015-12-30 20:58 -0800
Re: Boring for most of you, but I'm having fun ... :) Julian Fondren <julian.fondren@gmail.com> - 2016-01-02 02:25 -0800
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-12-31 12:04 +0000 |
| Message-ID | <568518af.1269454220@news.eternal-september.org> |
| In reply to | #44443 |
On Wed, 30 Dec 2015 09:17:25 -1000, "Elizabeth D. Rather" <erather@forth.com> wrote: >I totally understand this with respect to CONSTANT, :, and other words, >but I don't remember and have trouble imagining an implementation of >VARIABLE that wouldn't simply assign an allocated data space cell to a >definition that could potentially be expanded. Consider a system that provides data space in chunks within the main dictionary. When a chunk is filled, a new chunk is obtained. It is quite possible that VARIABLE FOO generates data space in one chunk, and 600 ALLOT does not have room in that chunk, so is placed in a new chunk. It is for reasons such as this that BUFFER: ( u -- ; -- addr ) is useful on destop systems as well as embedded systems. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-12-31 13:31 +0000 |
| Message-ID | <2015Dec31.143130@mips.complang.tuwien.ac.at> |
| In reply to | #44464 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Wed, 30 Dec 2015 09:17:25 -1000, "Elizabeth D. Rather"
><erather@forth.com> wrote:
>
>>I totally understand this with respect to CONSTANT, :, and other words,
>>but I don't remember and have trouble imagining an implementation of
>>VARIABLE that wouldn't simply assign an allocated data space cell to a
>>definition that could potentially be expanded.
>
>Consider a system that provides data space in chunks within the main
>dictionary. When a chunk is filled, a new chunk is obtained. It is
>quite possible that
> VARIABLE FOO
>generates data space in one chunk, and
> 600 ALLOT
>does not have room in that chunk, so is placed in a new chunk.
Such a system would make a very poor Forth, because it would likely
fail at
create foo 1 cells allot 600 allot
and at lots of other cases that are guaranteed to be contiguous by the
standard and also by traditional practice.
Viewed another way, if that Forth system fails at both usages, that's
not a good reason to keep the first usage non-standard. And if the
file system succeeds at the second usage, why not implement VARIABLE
such that the first usage succeeds, too?
>It
>is for reasons such as this that
> BUFFER: ( u -- ; -- addr )
>is useful on destop systems as well as embedded systems.
Given the way contiguous regions (and UNUSED) work in Forth, chunky
memory is a bad choice for dictionary memory, and consequently all
systems I know of use one large area for the data space part of
dictionary. And BUFFER: is not particularly useful on desktop
systems.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-12-31 08:50 -1000 |
| Message-ID | <BJKdnddJ9ph25RjLnZ2dnUU7-TGdnZ2d@supernews.com> |
| In reply to | #44466 |
On 12/31/15 3:31 AM, Anton Ertl wrote: > stephen@mpeforth.com (Stephen Pelc) writes: >> On Wed, 30 Dec 2015 09:17:25 -1000, "Elizabeth D. Rather" >> <erather@forth.com> wrote: >> >>> I totally understand this with respect to CONSTANT, :, and other words, >>> but I don't remember and have trouble imagining an implementation of >>> VARIABLE that wouldn't simply assign an allocated data space cell to a >>> definition that could potentially be expanded. >> >> Consider a system that provides data space in chunks within the main >> dictionary. When a chunk is filled, a new chunk is obtained. It is >> quite possible that >> VARIABLE FOO >> generates data space in one chunk, and >> 600 ALLOT >> does not have room in that chunk, so is placed in a new chunk. > > Such a system would make a very poor Forth, because it would likely > fail at > > create foo 1 cells allot 600 allot > > and at lots of other cases that are guaranteed to be contiguous by the > standard and also by traditional practice. > > Viewed another way, if that Forth system fails at both usages, that's > not a good reason to keep the first usage non-standard. And if the > file system succeeds at the second usage, why not implement VARIABLE > such that the first usage succeeds, too? > >> It >> is for reasons such as this that >> BUFFER: ( u -- ; -- addr ) >> is useful on destop systems as well as embedded systems. > > Given the way contiguous regions (and UNUSED) work in Forth, chunky > memory is a bad choice for dictionary memory, and consequently all > systems I know of use one large area for the data space part of > dictionary. And BUFFER: is not particularly useful on desktop > systems. I agree with Anton, except for the last sentence. What's the matter with BUFFER: on a desktop? 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-01-01 14:13 +0000 |
| Message-ID | <2016Jan1.151357@mips.complang.tuwien.ac.at> |
| In reply to | #44477 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 12/31/15 3:31 AM, Anton Ertl wrote:
>> stephen@mpeforth.com (Stephen Pelc) writes:
>>> It
>>> is for reasons such as this that
>>> BUFFER: ( u -- ; -- addr )
>>> is useful on destop systems as well as embedded systems.
[...]
>> And BUFFER: is not particularly useful on desktop
>> systems.
>
>I agree with Anton, except for the last sentence. What's the matter with
>BUFFER: on a desktop?
What I had in mind when I wrote that is that
CREATE <word> <u> ALLOT
is just as good on the desktop.
But now that you got me thinking about it, I notice that, except for
throwaway code, I rarely use CREATE in that way (and don't use BUFFER:
at all). Why? Because the size is typically given at run-time to
allow flexibility, or the size may even grow (e.g., with RESIZE).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-12-31 14:34 +0000 |
| Message-ID | <2015Dec31.153422@mips.complang.tuwien.ac.at> |
| In reply to | #44443 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>I wonder if it's time to ask whether that
>restriction on VARIABLE is still critical in common practice.
Not in Gforth, where VARIABLE is defined as
: Variable
Create 0 , ; ok
The question is: If your question does not bring up a real system
where that restriction is actually used, will anybody make a proposal
to remove this restriction?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-12-31 22:39 +0100 |
| Message-ID | <n64756$tdg$1@dont-email.me> |
| In reply to | #44470 |
Anton Ertl wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >>I wonder if it's time to ask whether that >>restriction on VARIABLE is still critical in common practice. > > Not in Gforth, where VARIABLE is defined as > > : Variable > Create 0 , ; ok > > The question is: If your question does not bring up a real system > where that restriction is actually used, will anybody make a proposal > to remove this restriction? VFX uses a separate address space for variables now, to avoid the problems of coherent, but separated code&data caches. variable foo hex foo . here . 80A2440 80BF324 Also, embedded systems like Mecrisp do similar things, mostly to make VARIABLE possible if you compile to flash (CREATE in that case is only useful for constant data). -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-01 10:05 +0000 |
| Message-ID | <2016Jan1.110522@mips.complang.tuwien.ac.at> |
| In reply to | #44485 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> The question is: If your question does not bring up a real system
>> where that restriction is actually used, will anybody make a proposal
>> to remove this restriction?
>
>VFX uses a separate address space for variables now, to avoid the problems
>of coherent, but separated code&data caches.
>
>variable foo hex foo . here . 80A2440 80BF324
And it puts code HERE? Checking, I see that it does. So it still
gets the cache consistency when there is CREATEd or otherwise ALLOTed
data somewhere, but at least it works for benchmarks that use
variables, but don't ALLOT. Example:
0 value addr
: foo 100000000 0 do i addr ! loop ;
here to addr 0 ,
>time vfxlin "0 value addr : foo 100000000 0 do i addr ! loop ; here to addr 0 , foo bye"
18.655u 0.004s 18.668r 99.95%
>time ~/gforth/gforth-fast -e "0 value addr : foo 100000000 0 do i addr ! loop ; here to addr 0 , foo bye"
0.512u 0.004s 0.515r 100.15%
I.e., for this particular microbenchmark VFX is 36 times slower than
Gforth, because of the cache consistency issue.
A better solution is to put the code in a separate address space. Then
you can leave the variables HERE, and traditional usage works.
>Also, embedded systems like Mecrisp do similar things, mostly to make
>VARIABLE possible if you compile to flash (CREATE in that case is only
>useful for constant data).
Well, that system obviously has restrictions beyond even those that
the standard imposes, so it's not a good argument for keeping that
particular restriction. If we lifted that restriction from the
standard, Mecrisp would not become any less standard than it is now.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-01-01 18:16 +0100 |
| Message-ID | <n66c57$4on$1@dont-email.me> |
| In reply to | #44493 |
Anton Ertl wrote: >>Also, embedded systems like Mecrisp do similar things, mostly to make >>VARIABLE possible if you compile to flash (CREATE in that case is only >>useful for constant data). > > Well, that system obviously has restrictions beyond even those that > the standard imposes, so it's not a good argument for keeping that > particular restriction. If we lifted that restriction from the > standard, Mecrisp would not become any less standard than it is now. It has, because the standard does not care about systems in flash. This concerns CREATE DOES> which is replaced by <BUILDS DOES> and the variable space, which is separated from the dictionary (plus that all variables in Mecrisp have Forth-79 initializers, because bulk initialization saves space in the flash). Otherwise, Mecrisp is pretty standard. Other flash-based systems have similar problems, though only Mecrisp has been ported to systems with a wide variety of different restrictions imposed by different flash implementations (thanks to ARM Cortex Mx implementation from many different manufacturers), so other systems could deal better (e.g. Gforth EC R8C can use CREATE and modify it with DOES> exactly one time, but the variable space is separated from the dictionary there, too). We simply should accept that an embedded system has write-once and write- often memory. That's a constraint the implementer can't ignore, and then he will instead ignore the standard in this particular case. The cache coherence issues in modern CPUs suggest that you probably want to have something similar there - you can mix code and constant data fine, but you can't mix code and changing data, as your microbenchmark shows. So this separation is not only good for microcontrollers, but also for high-end CPUs. Instead of having all variables initialized with a constant (Mecrisp), I would rather go at having a separate initialized version of VARIABLE, since this is not always needed, and then, the variable initializing region can be even smaller. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> |
|---|---|
| Date | 2016-01-01 17:49 +0000 |
| Message-ID | <20160101174953.26fab232@t500> |
| In reply to | #44498 |
On Fri, 01 Jan 2016 18:16:52 +0100 Bernd Paysan <bernd.paysan@gmx.de> wrote: > [...] > > Instead of having all variables initialized with a constant > (Mecrisp), I would rather go at having a separate initialized > version of VARIABLE, since this is not always needed, and > then, the variable initializing region can be even smaller. This sounds good, especially for very small systems. There will need an additional way to allocate RAM, so that only the section for the new variable is initialized to individual values. Perhaps: #VARIABLE ( n -- ; -- addr ) An alternate would be to mandate that all VARIABLEs are initialized to zero, and frig your code to match. Jan Coombs
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-01-01 19:23 +0100 |
| Message-ID | <n66g1f$it1$1@dont-email.me> |
| In reply to | #44500 |
Jan Coombs wrote: > On Fri, 01 Jan 2016 18:16:52 +0100 > Bernd Paysan <bernd.paysan@gmx.de> wrote: >> [...] >> >> Instead of having all variables initialized with a constant >> (Mecrisp), I would rather go at having a separate initialized >> version of VARIABLE, since this is not always needed, and >> then, the variable initializing region can be even smaller. > > This sounds good, especially for very small systems. There will > need an additional way to allocate RAM, so that only the section > for the new variable is initialized to individual values. > > Perhaps: > > #VARIABLE ( n -- ; -- addr ) Yes, that's the idea. > An alternate would be to mandate that all VARIABLEs are > initialized to zero, and frig your code to match. Initializing the variables at cold requires additional code, which uses up way more space than just store all the values in one array. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-01-01 15:53 -0800 |
| Message-ID | <87k2nseu0i.fsf@jester.gateway.pace.com> |
| In reply to | #44485 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > Also, embedded systems like Mecrisp do similar things, mostly to make > VARIABLE possible if you compile to flash (CREATE in that case is only > useful for constant data). Wait, do you mean CREATE FOO 20 CELLS ALLOT in Mecrisp doesn't allocate a 20-cell ram vector? There are some words that switch the compilation target between ram and flash, so maybe that's the workaround. It slightly complicates writing code portable between ANS and Mecrisp though.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-01-02 14:20 +0100 |
| Message-ID | <n68iln$nkn$1@dont-email.me> |
| In reply to | #44513 |
Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> Also, embedded systems like Mecrisp do similar things, mostly to make >> VARIABLE possible if you compile to flash (CREATE in that case is only >> useful for constant data). > > Wait, do you mean CREATE FOO 20 CELLS ALLOT in Mecrisp doesn't allocate > a 20-cell ram vector? There are some words that switch the compilation > target between ram and flash, so maybe that's the workaround. Sure, there are - compiletoram and compiletoflash. One problem with that approach however is that you lose all compiletoram stuff after a reset or power cycle, but the flash stuff still is there. Therefore, you should use BUFFER: for uninitialized RAM buffers, and NVARIABLE for initialized arrays. NVARIABLE takes the initialization content from the stack in the form of ( x1 .. xn n -- ). > It slightly complicates writing code portable between ANS and Mecrisp > though. Yes, that's because ANS and Forth-2012 ignore the Flash reality. In compiletoram mode, Mecrisp is pretty standard, but useless (programs should survive a reset and power cycle on an embedded controller). -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-01-02 16:34 +0000 |
| Message-ID | <5687fc11$0$23777$e4fe514c@news.xs4all.nl> |
| In reply to | #44529 |
Bernd Paysan <bernd.paysan@gmx.de> writes: >Paul Rubin wrote: >> Bernd Paysan <bernd.paysan@gmx.de> writes: >>> Also, embedded systems like Mecrisp do similar things, mostly to make >>> VARIABLE possible if you compile to flash (CREATE in that case is only >>> useful for constant data). >> >> Wait, do you mean CREATE FOO 20 CELLS ALLOT in Mecrisp doesn't allocate >> a 20-cell ram vector? There are some words that switch the compilation >> target between ram and flash, so maybe that's the workaround. >Sure, there are - compiletoram and compiletoflash. One problem with that >approach however is that you lose all compiletoram stuff after a reset or >power cycle, but the flash stuff still is there. Therefore, you should use >BUFFER: for uninitialized RAM buffers, and NVARIABLE for initialized arrays. >NVARIABLE takes the initialization content from the stack in the form of ( >x1 .. xn n -- ). >> It slightly complicates writing code portable between ANS and Mecrisp >> though. >Yes, that's because ANS and Forth-2012 ignore the Flash reality. In >compiletoram mode, Mecrisp is pretty standard, but useless (programs should >survive a reset and power cycle on an embedded controller). These issues are discussed in the context of noforth in http://home.hccnet.nl/anij/nof/ram&rom.pdf Starting point of other documentation (some pertaining to this subject) http://home.hccnet.nl/anij/nof/noforth.html >-- >Bernd Paysan Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Mikael Nordman <oh2aun@gmail.com> |
|---|---|
| Date | 2016-01-02 14:08 -0800 |
| Message-ID | <14e50a0c-ec05-4437-9299-2e7ba9dd8aca@googlegroups.com> |
| In reply to | #44529 |
On Saturday, January 2, 2016 at 3:20:23 PM UTC+2, Bernd Paysan wrote: > Paul Rubin wrote: > > > Bernd Paysan <bernd.paysan@> writes: > >> Also, embedded systems like Mecrisp do similar things, mostly to make > >> VARIABLE possible if you compile to flash (CREATE in that case is only > >> useful for constant data). > > > > Wait, do you mean CREATE FOO 20 CELLS ALLOT in Mecrisp doesn't allocate > > a 20-cell ram vector? There are some words that switch the compilation > > target between ram and flash, so maybe that's the workaround. > > Sure, there are - compiletoram and compiletoflash. One problem with that > approach however is that you lose all compiletoram stuff after a reset or > power cycle, but the flash stuff still is there. Therefore, you should use > BUFFER: for uninitialized RAM buffers, and NVARIABLE for initialized arrays. > NVARIABLE takes the initialization content from the stack in the form of ( > x1 .. xn n -- ). > > > It slightly complicates writing code portable between ANS and Mecrisp > > though. > > Yes, that's because ANS and Forth-2012 ignore the Flash reality. In > compiletoram mode, Mecrisp is pretty standard, but useless (programs should > survive a reset and power cycle on an embedded controller). In FlashForth I decided to have three writable dataspaces, RAM, EEPROM and FLASH. So you can do RAM CREATE 10 ALLOT EEPROM CREATE 10 ALLOT FLASH CREATE 10 ALLOT From user point of view it is very convenient. It causes more erase/write cycles to flash, since the flash blocks are erased and rewritten. By having an intelligent write routine that waits for a few hundred milliseconds for more words to be compiled until the flash block is written, the flash wear is not too bad. In fact I have never yet managed to wear out a single chip since I started with FlashForth in 2006. The buffered flash write also speeds up the compilations since the compiler writes the code first to a ram buffer which is later written to flash in one go. The MECRISP compiletoflash and compiletoram words should not decide anything about the current data space, only where to compiled code is going.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-12-30 20:40 -0800 |
| Message-ID | <62e5c3a9-efe8-4af7-bc9a-b271ed47ef4c@googlegroups.com> |
| In reply to | #44433 |
On Wednesday, December 30, 2015 at 3:25:33 AM UTC-7, HAA wrote: > Elizabeth D. Rather wrote: > > Yikes, you are right. Both ANS and Forth2012 contain this caution: > > > > 3.3.3.3 Variables > > The region allocated for a variable may be non-contiguous with regions > > subsequently allocated with , (comma) or ALLOT. For example, in: > > > > VARIABLE X 1 CELLS ALLOT > > > > the region X and the region ALLOTted could be non-contiguous. > > > > ------------- > > > > I've never encountered (or, indeed, heard of) such a system, but > > apparently they exist. However, if you write: > > > > CREATE tStack 65 CELLS ALLOT > > > > that is certainly contiguous, and everything else is fine. > > > > Cheers, > > Elizabeth > > The full explanation is here. > > E.4.1 Definitions > ... > Only words defined with CREATE or with other defining words that call > CREATE have data fields. The other defining words in the Standard > (VARIABLE, CONSTANT, :, etc.) might not be implemented with CREATE. > Consequently, a Standard Program must assume that words defined by > VARIABLE, CONSTANT, : , etc., may have no data fields. > > VARIABLE <name> n ALLOT was commonly used in FigForth which didn't > have a compatible CREATE. The problem with ANS-Forth is that pretty much anybody can have an ANS-Forth compliant system, but programs aren't going to be portable from one system to another --- ANS-Forth compliance is all about politics, and has nothing to do with the technical aspects of programming. Yikes!
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2015-12-30 08:28 -0800 |
| Message-ID | <797067c9-73cf-43ea-812b-6454c339fb08@googlegroups.com> |
| In reply to | #44432 |
On Wednesday, December 30, 2015 at 4:46:53 AM UTC-5, Elizabeth D. Rather wrote: > ... > ... However, if you write: > > CREATE tStack 65 CELLS ALLOT > > that is certainly contiguous, and everything else is fine. This is what I do now, thanks.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-12-30 11:11 +0000 |
| Message-ID | <2015Dec30.121132@mips.complang.tuwien.ac.at> |
| In reply to | #44417 |
Paul Rubin <no.email@nospam.invalid> writes:
>"Elizabeth D. Rather" <erather@forth.com> writes:
>> VARIABLE A 64 CELLS ALLOT
>> ...will create a data space 65 cells in size, and A returns the
>> address of the first. The data space is contiguous on all
>> systems.
>
>Is that guaranteed?
No.
|3.3.3.3 Variables
|
|The region allocated for a variable may be non-contiguous with regions
|subsequently allocated with , (comma) or ALLOT. For example, in:
|
|VARIABLE X 1 CELLS ALLOT
|
|the region X and the region ALLOTted could be non-contiguous.
>It seeme possible to me that some code could be
>emitted after the first cell, depending on the implementation.
That line of argument does not prove anything. For any requirement
one can imagine an implementation that does not meet it. That does
not mean that the requirement is not required by the standard, nor
that it is. You have to go to the standard document to see whether
the requirement is required by the standard.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2015-12-28 15:40 -0800 |
| Message-ID | <bf679a4c-efeb-49b2-9384-127eb0d96fad@googlegroups.com> |
| In reply to | #44397 |
On Monday, December 28, 2015 at 5:50:16 PM UTC-5, Coos Haak wrote: > Why? Because it can? > > groet Coos Oh, and FWIW ... no, not just because it can ... because it is a useful word that can be used in many places. There are lots of words like that.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2015-12-30 10:14 +1100 |
| Message-ID | <n5v45e$qrb$1@speranza.aioe.org> |
| In reply to | #44400 |
Chris Curl wrote: > On Monday, December 28, 2015 at 5:50:16 PM UTC-5, Coos Haak wrote: > > Why? Because it can? > > > > groet Coos > Oh, and FWIW ... no, not just because it can ... because it is a useful > word that can be used in many places. There are lots of words like that. If that were true they would have appeared in Forth 40 years ago. For the very rare occasion it's needed n NEGATE adr +! works fine.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-12-28 15:35 -1000 |
| Message-ID | <7OidnUsCmornfhzLnZ2dnUU7-QWdnZ2d@supernews.com> |
| In reply to | #44397 |
On 12/28/15 12:50 PM, Coos Haak wrote: > Op Mon, 28 Dec 2015 13:13:31 -0800 (PST) schreef Chris Curl: > >> On Monday, December 28, 2015 at 3:43:05 PM UTC-5, Paul Rubin wrote: >>> Chris Curl <cc...@gmail.com> writes: >>>> : -CELL! ( addr -- ) CELL SWAP -! ; >>> >>> \ -! doesn't appear to be a standard word >>> : -CELL! ( addr -- ) CELL NEGATE SWAP +! ; >> >> I added it to my dictionary ... >> >> : -! ( n addr -- ) tuck @ swap - swap ! ; >> ... or ... >> : -! ( n addr -- ) swap negate swap +! ; > > Why? Because it can? > If you must, write these terrible monsters in code (that's assembler). In my experience, +! is occasionally quite useful, but I've never felt a need for -!. And Coos is right, it's trivial in code but cumbersome and slow in high-level. 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]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web