Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #27952 > unrolled thread
| Started by | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| First post | 2014-01-19 13:15 -0500 |
| Last post | 2014-01-23 11:51 -0800 |
| Articles | 20 on this page of 65 — 15 participants |
Back to article view | Back to comp.lang.forth
quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-19 13:15 -0500
Re: quick review of <BUILDS and CREATE history albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-19 20:07 +0000
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-19 21:45 +0000
Re: quick review of <BUILDS and CREATE history Coos Haak <chforth@hccnet.nl> - 2014-01-19 22:02 +0100
Re: quick review of <BUILDS and CREATE history Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-19 17:24 -0600
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-19 14:54 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-19 22:37 -0500
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-19 18:01 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-20 00:27 -0500
Re: quick review of <BUILDS and CREATE history Elizabeth D Rather <erather@forth.com> - 2014-01-19 20:54 -1000
Re: quick review of <BUILDS and CREATE history Elizabeth D Rather <erather@forth.com> - 2014-01-19 21:19 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-20 16:14 -0500
Re: quick review of <BUILDS and CREATE history Elizabeth D Rather <erather@forth.com> - 2014-01-20 12:07 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-21 11:37 -0500
Re: quick review of <BUILDS and CREATE history albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-21 17:41 +0000
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-21 08:30 -1000
Re: quick review of <BUILDS and CREATE history oh2aun@gmail.com - 2014-01-21 11:17 -0800
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-21 09:44 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-21 15:18 -0500
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-21 12:07 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-21 22:04 -0500
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-21 19:21 -1000
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-22 13:38 +0000
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-22 08:50 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-23 17:17 -0500
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-23 13:46 -1000
Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-24 15:07 +0100
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-25 15:18 +0000
Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-25 20:18 +0100
Re: quick review of <BUILDS and CREATE history Coos Haak <chforth@hccnet.nl> - 2014-01-25 20:44 +0100
Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-25 21:41 +0100
Re: quick review of <BUILDS and CREATE history "Alex McDonald" <blog@rivadpm.com> - 2014-01-25 22:47 +0000
Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-26 01:54 +0100
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 16:49 +0000
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 15:40 +0000
Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-27 23:00 +0100
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-27 19:43 -0500
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-28 09:25 +0000
Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-28 19:45 +0100
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-30 15:32 +0000
Re: quick review of <BUILDS and CREATE history albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-28 14:20 +0000
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-25 15:28 +0000
Re: quick review of <BUILDS and CREATE history Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-25 13:51 -0600
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 15:34 +0000
Re: quick review of <BUILDS and CREATE history Lars Brinkhoff <lars.spam@nocrew.org> - 2014-01-24 08:11 +0100
Re: quick review of <BUILDS and CREATE history Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 01:28 -0800
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 05:00 -0500
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-24 09:32 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 17:48 -0500
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-24 13:14 -1000
Re: quick review of <BUILDS and CREATE history Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 16:16 -0800
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-23 12:13 -0500
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-22 13:32 +0000
Re: quick review of <BUILDS and CREATE history Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-20 04:14 -0800
Re: quick review of <BUILDS and CREATE history Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-20 06:31 -0600
Re: quick review of <BUILDS and CREATE history Elizabeth D Rather <erather@forth.com> - 2014-01-20 08:04 -1000
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-21 14:09 +0000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-20 16:14 -0500
Re: quick review of <BUILDS and CREATE history trebor.english@gmail.com - 2014-01-22 17:44 -0800
Re: quick review of <BUILDS and CREATE history trebor.english@gmail.com - 2014-01-22 18:24 -0800
Re: quick review of <BUILDS and CREATE history albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-23 14:00 +0000
Re: quick review of <BUILDS and CREATE history trebor.english@gmail.com - 2014-01-23 11:06 -0800
Re: quick review of <BUILDS and CREATE history Paul Rubin <no.email@nospam.invalid> - 2014-01-23 11:33 -0800
Re: quick review of <BUILDS and CREATE history trebor.english@gmail.com - 2014-01-23 11:42 -0800
Re: quick review of <BUILDS and CREATE history Mikael Nordman <oh2aun@gmail.com> - 2014-01-23 11:51 -0800
Page 1 of 4 [1] 2 3 4 Next page →
| From | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2014-01-19 13:15 -0500 |
| Subject | quick review of <BUILDS and CREATE history |
| Message-ID | <op.w9x40in85zc71u@localhost> |
Okay, let's see if I get this correct ... <BUILDS originally worked with DOES> . <BUILDS was defined as 0 CONSTANT in fig-Forth. CONSTANT used an early limited version of CREATE to build a dictionary header. Then, <BUILDS was obsoleted, and CREATE was enhanced to work in place of both the limited CREATE and <BUILDS. That gave rise to CREATE ... DOES> . Next, :NONAME was created to essentially do what the early limited CREATE did but without writing a name into the dictionary header. Many systems also have a non-standard word HEADER to do this too. Now, you guys are wanting to restore the original <BUILDS because the more powerful CREATE doesn't work as well in embedded systems that use flash memory, have limited writes, and separate address spaces. Is this correct? Why does it feel like I'm going around in circles? Is this a prime example of poor factoring? Can <BUILDS now be constructed with :NONAME ? Rod Pemberton
[toc] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-01-19 20:07 +0000 |
| Message-ID | <52dc306d$0$24958$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #27952 |
In article <op.w9x40in85zc71u@localhost>, Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote: > >Okay, let's see if I get this correct ... > ><BUILDS originally worked with DOES> . ><BUILDS was defined as 0 CONSTANT in fig-Forth. >CONSTANT used an early limited version of >CREATE to build a dictionary header. >Then, <BUILDS was obsoleted, and CREATE >was enhanced to work in place of both the >limited CREATE and <BUILDS. That gave rise >to CREATE ... DOES> . Next, :NONAME was >created to essentially do what the early >limited CREATE did but without writing a name >into the dictionary header. Many systems also >have a non-standard word HEADER to do this too. >Now, you guys are wanting to restore the original ><BUILDS because the more powerful CREATE doesn't >work as well in embedded systems that use flash >memory, have limited writes, and separate address >spaces. > >Is this correct? > >Why does it feel like I'm going around in circles? > >Is this a prime example of poor factoring? > >Can <BUILDS now be constructed with :NONAME ? You seem to fall in a pit that ISO digged us. As an implementor I see ISO as the layer above the carnal low level words that must work very wel together. The better they work together and the more powerful the design (which means the choice of those words), the less of those you need to define an ISO word, and the easier it is to add system words that people come up with. It is seldom or at least not natural that an ISO words is usable as one of those carnal words. :NONAME certainly isn't. It is unusable as such in an indirect threaded context, so it is unusable full stop. The proper view for <BUILDS is a service to the user of flash systems, not as another possible low level carnal word. [I was surprised to see : <BUILDS 0 CONSTANT ; in my FIG listing. What it says to me that CONSTANT was one of those carnal procedures in FIG. And that by some luck or good design it was usable as the word CONSTANT that a user most certainly want. Now this is only interesting if you're fond of fig-forth memorabilia. ] >Rod Pemberton 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-19 21:45 +0000 |
| Message-ID | <2014Jan19.224547@mips.complang.tuwien.ac.at> |
| In reply to | #27957 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <op.w9x40in85zc71u@localhost>,
>Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote:
>>
>>Okay, let's see if I get this correct ...
>>
>><BUILDS originally worked with DOES> .
>><BUILDS was defined as 0 CONSTANT in fig-Forth.
>>CONSTANT used an early limited version of
>>CREATE to build a dictionary header.
Not sure what you mean with "limited version of CREATE" here.
fig-Forth's CREATE starts a primitive, and is used as factor for other
defining words (which change the code field).
>[I was surprised to see : <BUILDS 0 CONSTANT ; in my FIG listing.
>What it says to me that CONSTANT was one of those carnal procedures in
>FIG.
What this actually says is that <BUILDS allots one cell more than
CREATE, just like CONSTANT. So instead of writing the longer
: <BUILDS CREATE 0 , ;
they wrote the shorter
: <BUILDS 0 CONSTANT ;
DOES> changes the code field, so it does not matter whether CONSTANT
or VARIABLE is used for defining <BUILDS; the difference between these
words is in the code field they create, and that is going to be
overwritten anyway.
- 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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2014-01-19 22:02 +0100 |
| Message-ID | <1nr7tql3zkqbb$.lga4ytx0ij36$.dlg@40tude.net> |
| In reply to | #27952 |
Op Sun, 19 Jan 2014 13:15:44 -0500 schreef Rod Pemberton: > Okay, let's see if I get this correct ... > > <BUILDS originally worked with DOES> . > <BUILDS was defined as 0 CONSTANT in fig-Forth. > CONSTANT used an early limited version of > CREATE to build a dictionary header. > Then, <BUILDS was obsoleted, and CREATE > was enhanced to work in place of both the > limited CREATE and <BUILDS. That gave rise > to CREATE ... DOES> . Next, :NONAME was > created to essentially do what the early > limited CREATE did but without writing a name > into the dictionary header. No, CREATE built a header which could not be executed by itself, it needs some more code, like this: : CONSTANT CREATE SMUDGE , ;CODE .. some assembly code : VARIABLE CONSTANT ;CODE ... assy code. :NONAME does not build a header*), it produces an xt. *) however, ciforth does. All :NONAME definitions are called NONAME. -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-19 17:24 -0600 |
| Message-ID | <zqqdnYChjNguw0HPnZ2dnUVZ_tednZ2d@supernews.com> |
| In reply to | #27952 |
Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote: > > Okay, let's see if I get this correct ... > > <BUILDS originally worked with DOES> . > <BUILDS was defined as 0 CONSTANT in fig-Forth. > CONSTANT used an early limited version of CREATE to build a > dictionary header. > Then, <BUILDS was obsoleted, and CREATE was enhanced to work in > place of both the limited CREATE and <BUILDS. That gave rise to > CREATE ... DOES> . That's basically right, but it's missing CREATE ... ;CODE , which was an important step along the way: ;CODE was a core defining word for a long while. > Next, :NONAME was created to essentially do what the early limited > CREATE did but without writing a name into the dictionary header. No, that's completely wrong. > Many systems also have a non-standard word HEADER to do this too. Which has nothing at all to do with :NONAME . > Now, you guys are wanting to restore the original <BUILDS because That's to do with a couple of nonstandard Forth systems. And, as discussed, there are plenty of ways around the problem. > the more powerful CREATE doesn't work as well in embedded systems > that use flash memory, have limited writes, and separate address > spaces. > > Is this correct? Sort of. > Why does it feel like I'm going around in circles? > > Is this a prime example of poor factoring? > > Can <BUILDS now be constructed with :NONAME ? No. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-01-19 14:54 -1000 |
| Message-ID | <QfadnSaNy6ZL7kHPnZ2dnUVZ_sidnZ2d@supernews.com> |
| In reply to | #27963 |
On 1/19/14 1:24 PM, Andrew Haley wrote: > Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote: >> >> Okay, let's see if I get this correct ... >> >> <BUILDS originally worked with DOES> . >> <BUILDS was defined as 0 CONSTANT in fig-Forth. >> CONSTANT used an early limited version of CREATE to build a >> dictionary header. >> Then, <BUILDS was obsoleted, and CREATE was enhanced to work in >> place of both the limited CREATE and <BUILDS. That gave rise to >> CREATE ... DOES> . > > That's basically right, but it's missing CREATE ... ;CODE , which was > an important step along the way: ;CODE was a core defining word for a > long while. Yes. At this stage, the expectation was that ;CODE would supply (in assembler) the behavior of this type of word. CREATE built the header. >> Next, :NONAME was created to essentially do what the early limited >> CREATE did but without writing a name into the dictionary header. > > No, that's completely wrong. :NONAME is, as Andrew points out, completely unrelated to this topic. We're talking about defining various kinds of data objects with specialized behaviors; :NONAME only constructs a headerless colon definition and returns its xt. Totally different topic altogether. >> Many systems also have a non-standard word HEADER to do this too. > > Which has nothing at all to do with :NONAME . There are two issues central to a Forth word: defining behavior and its execution behavior. All defining words of a class share the same defining behavior. The first step in constructing a defining behavior is to make its dictionary entry. CREATE, HEADER, and other named words in other implementations do this. At a primitive level, the dictionary entry construction can be (and often is) decoupled from any kind of assumed runtime behavior, but that primitive layer has never been standardized. The second step is to set the execution behavior. Currently, CREATE constructs a word with minimal defining behavior (just the header) and a default runtime behavior (return the address of the data space associated with it, which may have been allocated by a subsequent activity (ALLOT, comma, etc.) at compile time). DOES> allows the programmer to *replace* the default runtime behavior with something else. CREATE is required as a preamble to DOES> because it guarantees that there is a place for the link to the new runtime behavior to be stored. None of this is related to :NONAME because it constructs only one kind of definition: a colon definition with no head. It has no data space associated with it, and its semantics can't be changed. >> Now, you guys are wanting to restore the original <BUILDS because > > That's to do with a couple of nonstandard Forth systems. And, as > discussed, there are plenty of ways around the problem. > >> the more powerful CREATE doesn't work as well in embedded systems >> that use flash memory, have limited writes, and separate address >> spaces. >> >> Is this correct? > > Sort of. The issue under discussion is the fact that CREATE has stored a default runtime behavior, which is inauspicious when the dictionary is being built in flash. <BUILDS allocates the space for the runtime behavior pointer, but doesn't initialize it. As Andrew and others have pointed out, there are several ways to deal with the issue without adding a new word. >> Why does it feel like I'm going around in circles? Because you don't understand the issue. >> Is this a prime example of poor factoring? The only alternative factoring that might be helpful here would be to standardize the function of constructing the dictionary entry at a primitive level. Historically, no one has wanted to do this because of the severe constraints that would place on implementation strategies; the cure is far worse than the disease. >> Can <BUILDS now be constructed with :NONAME ? > > No. <Builds makes a header; :NONAME doesn't. They're the opposite of each other! 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 | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2014-01-19 22:37 -0500 |
| Message-ID | <op.w9yu1gm65zc71u@localhost> |
| In reply to | #27964 |
On Sun, 19 Jan 2014 19:54:43 -0500, Elizabeth D. Rather <erather@forth.com> wrote: > On 1/19/14 1:24 PM, Andrew Haley wrote: >> Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote: >>> Next, :NONAME was created to essentially do what the early limited >>> CREATE did but without writing a name into the dictionary header. >> >> No, that's completely wrong. > > :NONAME is, as Andrew points out, completely unrelated to this topic. > We're talking about defining various kinds of data objects with > specialized behaviors; :NONAME only constructs a headerless colon > definition and returns its xt. Totally different topic altogether. > So, defining CREATE in terms of : and ; and DOVAR and also defining : in terms of :NONAME and WORD and CMOVE is not possible? Odd... If :NONAME did not return an xt, what does it do differently from CREATE other than not install a name? I.e., it appears to me that :NONAME works much like HEADER, enough so that it can be a low-level replacement for it. In which case, since CREATE is defined in terms of : and that can be defined in terms of :NONAME, then :NONAME should be useable to construct <BUILDS since it's defined in terms of CREATE or a word like VARIABLE or CONSTANT which are, typically. Make sense? Or, still completely wrong? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-01-19 18:01 -1000 |
| Message-ID | <samdnZ0iro4aAkHPnZ2dnUVZ_t2dnZ2d@supernews.com> |
| In reply to | #27965 |
On 1/19/14 5:37 PM, Rod Pemberton wrote: > On Sun, 19 Jan 2014 19:54:43 -0500, Elizabeth D. Rather > <erather@forth.com> wrote: >> On 1/19/14 1:24 PM, Andrew Haley wrote: >>> Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote: > >>>> Next, :NONAME was created to essentially do what the early limited >>>> CREATE did but without writing a name into the dictionary header. >>> >>> No, that's completely wrong. >> >> :NONAME is, as Andrew points out, completely unrelated to this topic. >> We're talking about defining various kinds of data objects with >> specialized behaviors; :NONAME only constructs a headerless colon >> definition and returns its xt. Totally different topic altogether. >> > > So, defining CREATE in terms of : and ; and DOVAR > and also defining : in terms of :NONAME and WORD and CMOVE is > not possible? Odd... Well, some versions of the primitive that builds a header may use WORD and CMOVE, and DOVAR may in some systems be the name of the default behavior of CREATE. CREATE itself is, usually, a colon definition, but I can't imagine how it would *use* : or :NONAME because those words don't do anything related to what CREATE needs to do. > If :NONAME did not return an xt, what does it do differently from > CREATE other than not install a name? It's completely different. They don't do any of the same things. > I.e., it appears to me that :NONAME works much like HEADER, enough > so that it can be a low-level replacement for it. No, :NONAME specifically *doesn't* do what HEADER does. > In which case, > since CREATE is defined in terms of : It isn't. > and that can be defined in > terms of :NONAME, It can't. > then :NONAME should be useable to construct > <BUILDS since it's defined in terms of CREATE or a word like > VARIABLE or CONSTANT which are, typically. > > Make sense? Or, still completely wrong? Completely wrong. It sounds as though you have a very mistaken notion of what :NONAME does. 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 | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2014-01-20 00:27 -0500 |
| Message-ID | <op.w9yz3nnj5zc71u@localhost> |
| In reply to | #27966 |
On Sun, 19 Jan 2014 23:01:09 -0500, Elizabeth D. Rather <erather@forth.com> wrote: > Completely wrong. I was being sarcastic at the "Odd..." That's how my Forth works. It was constructed that way after help from you and Andrew (IIRC, or maybe it was Alex...) on correctly implementing :NONAME. The differences between my CREATE and :NONAME were trivial. > It sounds as though you have a very > mistaken notion of what :NONAME does. AIUI, :NONAME is the same as : except it doesn't install a name into the dictionary header of the word being defined and it returns an xt. It's definition is terminated by a ; just like a : definition. It compiles a definition just like a : definition. In most Forths, : calls CREATE to build the header and insert the name the word being defined. After CREATE is finished, the colon definition continues compiling until ; . AIUI, all I've done is switch things around to build : up from :NONAME instead of using CREATE. If it's correct, which I believe it is, <BUILDS can be built from :NONAME also. Some of the other confusing stuff was because I have two : and two ; . One of each is an initial bootstrap, and the other is a redefine into high-level Forth. If it's not correct, I guess I'm going to have to track down some more tests since Hayes etc didn't notice... Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2014-01-19 20:54 -1000 |
| Message-ID | <KbednR9Be4m-VUHPnZ2dnUVZ_rOdnZ2d@supernews.com> |
| In reply to | #27967 |
On 1/19/2014 7:27 PM, Rod Pemberton wrote:
> On Sun, 19 Jan 2014 23:01:09 -0500, Elizabeth D. Rather
> <erather@forth.com> wrote:
>
>> Completely wrong.
>
> I was being sarcastic at the "Odd..."
>
> That's how my Forth works. It was constructed that way
> after help from you and Andrew (IIRC, or maybe it was
> Alex...) on correctly implementing :NONAME. The
> differences between my CREATE and :NONAME were trivial.
I'm baffled. CREATE makes a header; :NONAME doesn't. CREATE doesn't turn
on the compiler. :NONAME does. These differences are critical, not trivial.
>> It sounds as though you have a very
>> mistaken notion of what :NONAME does.
>
> AIUI, :NONAME is the same as : except it doesn't install
> a name into the dictionary header of the word being defined
> and it returns an xt. It's definition is terminated by
> a ; just like a : definition. It compiles a definition
> just like a : definition.
>
> In most Forths, : calls CREATE to build the header
> and insert the name the word being defined. After
> CREATE is finished, the colon definition continues
> compiling until ; .
In most Forths that I'm familiar with, : calls a lower-level word to
build the header and insert the name. CREATE also calls that. However,
CREATE does *not* "continue compiling", instead it sets the default
action of the word just created to DODOES or equivalent with an
associated data location. : has no associated data location. In other
words, the only thing both : and CREATE share is a call to the
lower-level word to make the header.
Consider the definition:
: CONSTANT ( n -- ) CREATE ,
DOES> ( -- n ) @ ;
Here CREATE builds the header and , compiles the value in data space.
The fact that compiling continues is not due to CREATE, which has
finished executing, but to : which invoked CREATE and , and continued
compiling.
> AIUI, all I've done is switch things around to build
> : up from :NONAME instead of using CREATE. If it's
> correct, which I believe it is, <BUILDS can be built
> from :NONAME also.
<BUILDS and CREATE need to do two things that :NONAME does not: build a
header, and associate a data space address. :NONAME turns on the
compiler and records the *code space* location of the associated xt,
neither of which <BUILDS or CREATE do.
They have *nothing* in common.
The distinction between code space and data space is critical when
you're dealing with RAM/FLASH architectures.
> Some of the other confusing stuff was because I have
> two : and two ; . One of each is an initial bootstrap,
> and the other is a redefine into high-level Forth.
>
> If it's not correct, I guess I'm going to have to track
> down some more tests since Hayes etc didn't notice...
This is mostly conceptual stuff. Not sure the Hays test checks for that.
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 | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2014-01-19 21:19 -1000 |
| Message-ID | <ntWdnRWZo6aHU0HPnZ2dnUVZ_uWdnZ2d@supernews.com> |
| In reply to | #27968 |
On 1/19/2014 8:54 PM, Elizabeth D Rather wrote: >... > In most Forths that I'm familiar with, : calls a lower-level word to > build the header and insert the name. CREATE also calls that. However, > CREATE does *not* "continue compiling", instead it sets the default > action of the word just created to DODOES or equivalent with an > associated data location. : has no associated data location. In other > words, the only thing both : and CREATE share is a call to the > lower-level word to make the header. Sorry, I meant DOVAR, not DODOES. I have never used FigForth, and can't remember its names for things. Whatever, the default behavior for CREATE is to return the address of its data space. 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 | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2014-01-20 16:14 -0500 |
| Message-ID | <op.w9z7x2uk5zc71u@localhost> |
| In reply to | #27968 |
On Mon, 20 Jan 2014 01:54:25 -0500, Elizabeth D Rather <erather@forth.com> wrote: > On 1/19/2014 7:27 PM, Rod Pemberton wrote: > I'm baffled. CREATE makes a header; :NONAME doesn't. CREATE > doesn't turn on the compiler. :NONAME does. These differences > are critical, not trivial. > Based on your post and Mark's, I think my :NONAME is functioning like :NONAME combined with HEADER. >>> It sounds as though you have a very >>> mistaken notion of what :NONAME does. >> >> AIUI, :NONAME is the same as : except it doesn't install >> a name into the dictionary header of the word being defined >> and it returns an xt. It's definition is terminated by >> a ; just like a : definition. It compiles a definition >> just like a : definition. >> >> In most Forths, : calls CREATE to build the header >> and insert the name the word being defined. After >> CREATE is finished, the colon definition continues >> compiling until ; . > > In most Forths that I'm familiar with, : calls a lower-level word to > build the header and insert the name. CREATE also calls that. However, > CREATE does *not* "continue compiling", instead it sets the default > action of the word just created to DODOES or equivalent with an > associated data location. : has no associated data location. In other > words, the only thing both : and CREATE share is a call to the > lower-level word to make the header. > Let me break down what I'm doing currently. It's been a while since I've read/coded the code, so hopefully, no misunderstandings/mistakes posted... This is what :NONAME CREATE : and ; are doing: :NONAME -the next few steps creates a dictionary header --blanks name field area (NFA) --updates link field address (LFA) with LAST --updates dictionary bits (part of NFA) --updates LAST --updates dictionary pointer (DP) to code field address (CFA) -puts HERE (at current CFA) on the stack for use as an XT -compiles ENTER into the definition (at current CFA) -turns on compiling ] -SMUDGEs the definition being compiled (turns on) : -executes :NONAME -executes BL WORD to get name of definition -executes COUNT -sets up values for CMOVE which consumes :NONAMEs XT -finds the name field (NFA) -executes CMOVE to move the definition's name into the name field ; -compiles EXIT into a definition -SMUDGEs the definition being compiled (turns off) -turns off compiling [ CREATE -executes : -places HERE on the stack -executes ; -sets the dictionary pointer (DP) to code field address (CFA) -stores DOVAR into the code field address (CFA) -resets dictionary pointer (DP) to saved HERE on stack > Consider the definition: > > : CONSTANT ( n -- ) CREATE , > DOES> ( -- n ) @ ; > > Here CREATE builds the header and , compiles the value in data space. > The fact that compiling continues is not due to CREATE, which has > finished executing, but to : which invoked CREATE and , and continued > compiling. > All the common definitions which use CREATE work correctly. >> AIUI, all I've done is switch things around to build >> : up from :NONAME instead of using CREATE. If it's >> correct, which I believe it is, <BUILDS can be built >> from :NONAME also. > > <BUILDS and CREATE need to do two things that :NONAME > does not: build a header, and associate a data space > address. :NONAME turns on the compiler and records the > *code space* location of the associated xt, > neither of which <BUILDS or CREATE do. > > They have *nothing* in common. > > The distinction between code space and data space is critical > when you're dealing with RAM/FLASH architectures. > Okay, I suspect you're going to tell me to remove the header creation in :NONAME and place it into a word named HEADER or (CREATE). Then, have : call HEADER or (CREATE). So, then, the rough definition for : would become: : HEADER :NONAME BL WORD COUNT ... "get NFA" CMOVE ; I'm assuming the rest is acceptable ... ? IIRC, :NONAME on my system needed a header for the dictionary to be linked together correctly. If so, I'll have to check into why that is... It's probably wise to fix the issue. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2014-01-20 12:07 -1000 |
| Message-ID | <nbOdnWkOO6CKA0DPnZ2dnUVZ_oydnZ2d@supernews.com> |
| In reply to | #27979 |
On 1/20/2014 11:14 AM, Rod Pemberton wrote: > On Mon, 20 Jan 2014 01:54:25 -0500, Elizabeth D Rather > <erather@forth.com> wrote: > >> On 1/19/2014 7:27 PM, Rod Pemberton wrote: > >> I'm baffled. CREATE makes a header; :NONAME doesn't. CREATE >> doesn't turn on the compiler. :NONAME does. These differences >> are critical, not trivial. >> > > Based on your post and Mark's, I think my :NONAME is functioning > like :NONAME combined with HEADER. > >>>> It sounds as though you have a very >>>> mistaken notion of what :NONAME does. >>> >>> AIUI, :NONAME is the same as : except it doesn't install >>> a name into the dictionary header of the word being defined >>> and it returns an xt. It's definition is terminated by >>> a ; just like a : definition. It compiles a definition >>> just like a : definition. >>> >>> In most Forths, : calls CREATE to build the header >>> and insert the name the word being defined. After >>> CREATE is finished, the colon definition continues >>> compiling until ; . >> >> In most Forths that I'm familiar with, : calls a lower-level word to >> build the header and insert the name. CREATE also calls that. However, >> CREATE does *not* "continue compiling", instead it sets the default >> action of the word just created to DODOES or equivalent with an >> associated data location. : has no associated data location. In other >> words, the only thing both : and CREATE share is a call to the >> lower-level word to make the header. >> > > Let me break down what I'm doing currently. > It's been a while since I've read/coded the code, > so hopefully, no misunderstandings/mistakes posted... > This is what :NONAME CREATE : and ; are doing: > > :NONAME > -the next few steps creates a dictionary header > --blanks name field area (NFA) > --updates link field address (LFA) with LAST > --updates dictionary bits (part of NFA) > --updates LAST > --updates dictionary pointer (DP) to code field address (CFA) > -puts HERE (at current CFA) on the stack for use as an XT > -compiles ENTER into the definition (at current CFA) > -turns on compiling ] > -SMUDGEs the definition being compiled (turns on) > > : > -executes :NONAME > -executes BL WORD to get name of definition > -executes COUNT > -sets up values for CMOVE which consumes :NONAMEs XT > -finds the name field (NFA) > -executes CMOVE to move the definition's name into the name field > > ; > -compiles EXIT into a definition > -SMUDGEs the definition being compiled (turns off) > -turns off compiling [ > > CREATE > -executes : Should not execute : as it isn't building a colon definition. It's building a data object. > -places HERE on the stack > -executes ; No need for ; or : > -sets the dictionary pointer (DP) to code field address (CFA) Why didn't HEADER leave it set correctly? > -stores DOVAR into the code field address (CFA) > -resets dictionary pointer (DP) to saved HERE on stack You're wasting space and fiddling with DP much too much. CREATE should be very, very simple: * Build header * Set DOVAR in code field That's all. One common definition of CREATE is: : CREATE ( -- ) BL WORD COUNT (CREATE) ; This assumes, of course, that (CREATE) will initialize the code field appropriately to return the data space address. If it's being used by other defining words (e.g. : ) they might change it. This, of course, assumes the dictionary is being built in RAM. Setting the code field with a default and replacing it when necessary can be less fiddly than having each defining word have to do its own, since a great many defining words can start off with the data space address and go on from there. >> Consider the definition: >> >> : CONSTANT ( n -- ) CREATE , >> DOES> ( -- n ) @ ; >> >> Here CREATE builds the header and , compiles the value in data space. >> The fact that compiling continues is not due to CREATE, which has >> finished executing, but to : which invoked CREATE and , and continued >> compiling. >> > > All the common definitions which use CREATE work correctly. Good, but you're working a lot harder than you need to. >>> AIUI, all I've done is switch things around to build >>> : up from :NONAME instead of using CREATE. If it's >>> correct, which I believe it is, <BUILDS can be built >>> from :NONAME also. >> >> <BUILDS and CREATE need to do two things that :NONAME >> does not: build a header, and associate a data space >> address. :NONAME turns on the compiler and records the >> *code space* location of the associated xt, >> neither of which <BUILDS or CREATE do. >> >> They have *nothing* in common. >> >> The distinction between code space and data space is critical >> when you're dealing with RAM/FLASH architectures. >> > > Okay, I suspect you're going to tell me to remove the header > creation in :NONAME and place it into a word named HEADER > or (CREATE). Then, have : call HEADER or (CREATE). That's a start. The whole purpose of :NONAME is to *not* have a header. > So, then, the rough definition for : would become: > : HEADER :NONAME BL WORD COUNT ... "get NFA" CMOVE ; HEADER should do all the BL WORD COUNT stuff. In other words, it should build a complete header. And it should *not* do any compiling! Only : and :NONAME compile stuff. So take out the :NONAME. > I'm assuming the rest is acceptable ... ? > > IIRC, :NONAME on my system needed a header for the dictionary > to be linked together correctly. If so, I'll have to check > into why that is... It's probably wise to fix the issue. I think there are probably a lot of improvements possible. :NONAME *isn't* linked in the dictionary search; that's why it exists. 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 | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2014-01-21 11:37 -0500 |
| Message-ID | <op.w91ps0mn5zc71u@localhost> |
| In reply to | #27982 |
On Mon, 20 Jan 2014 17:07:17 -0500, Elizabeth D Rather <erather@forth.com> wrote: > On 1/20/2014 11:14 AM, Rod Pemberton wrote: >> On Mon, 20 Jan 2014 01:54:25 -0500, Elizabeth D Rather >> <erather@forth.com> wrote: >>> On 1/19/2014 7:27 PM, Rod Pemberton wrote: >> Let me break down what I'm doing currently. >> It's been a while since I've read/coded the code, >> so hopefully, no misunderstandings/mistakes posted... >> This is what :NONAME CREATE : and ; are doing: >> >> :NONAME >> -the next few steps creates a dictionary header >> --blanks name field area (NFA) >> --updates link field address (LFA) with LAST >> --updates dictionary bits (part of NFA) >> --updates LAST >> --updates dictionary pointer (DP) to code field address (CFA) >> -puts HERE (at current CFA) on the stack for use as an XT >> -compiles ENTER into the definition (at current CFA) >> -turns on compiling ] >> -SMUDGEs the definition being compiled (turns on) >> >> : >> -executes :NONAME >> -executes BL WORD to get name of definition >> -executes COUNT >> -sets up values for CMOVE which consumes :NONAMEs XT >> -finds the name field (NFA) >> -executes CMOVE to move the definition's name into the name field >> >> ; >> -compiles EXIT into a definition >> -SMUDGEs the definition being compiled (turns off) >> -turns off compiling [ >> >> CREATE >> -executes : > > Should not execute : as it isn't building a colon definition. It's > building a data object. > >> -places HERE on the stack >> -executes ; > > No need for ; or : > >> -sets the dictionary pointer (DP) to code field address (CFA) > > Why didn't HEADER leave it set correctly? > It's been a while since I worked on it, so I'm not 100% sure what it's doing... It appears from the code an ENTER was compiled in by :NONAME, i.e., DP or HERE moved. So, CREATE creates an empty definition with just ENTER and EXIT. > [edited together] > > The whole purpose of :NONAME is to *not* have a header. > [...] > :NONAME *isn't* linked in the dictionary search; that's why it exists. Does it really matter if :NONAME has a header and is linked? If the header is unfindable by FIND or ' etc... > HEADER should do all the BL WORD COUNT stuff. In other words, it should > build a complete header. And it should *not* do any compiling! Only : > and :NONAME compile stuff. So take out the :NONAME. Ok. Thanks. It appears I need to separate HEADER functionality from three of those four words. I think I prefer HEADER to (CREATE). () seems to be used for low-level words. AIR, : and ; were simpler at one point, since I started from fig-Forth documents. I'll have to see where they became warped... Is it possible to define : in terms of :NONAME, e.g., something like: : CREATE :NONAME DROP ... Where :NONAME would do the compiling and/or SMUDGE? I.e., an attempt not to duplicate the compiling code in both : and :NONAME. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-01-21 17:41 +0000 |
| Message-ID | <52deb134$0$25260$e4fe514c@dreader34.news.xs4all.nl> |
| In reply to | #27990 |
In article <op.w91ps0mn5zc71u@localhost>, Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote: <SNIP> >It appears from the code an ENTER was compiled in by :NONAME, >i.e., DP or HERE moved. So, CREATE creates an empty definition >with just ENTER and EXIT. You're confused. CREATE makes a word that when executed points to the current value of HERE. It remains to be seen whether the expression "empty definition" conveys any meaning. <SNIP> None of your ramblings makes any sense without the context of a specific implementation anyway. >Rod Pemberton -- 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-01-21 08:30 -1000 |
| Message-ID | <c7WdnXP0eoFfIUPPnZ2dnUVZ_t6dnZ2d@supernews.com> |
| In reply to | #27990 |
On 1/21/14 6:37 AM, Rod Pemberton wrote: > On Mon, 20 Jan 2014 17:07:17 -0500, Elizabeth D Rather ... > It's been a while since I worked on it, so I'm not 100% sure > what it's doing... It's possible you weren't 100% sure when you wrote it ;-) > It appears from the code an ENTER was compiled in by :NONAME, > i.e., DP or HERE moved. So, CREATE creates an empty definition > with just ENTER and EXIT. CREATE should have neither ENTER nor EXIT since it's a data object, not a definition. >> The whole purpose of :NONAME is to *not* have a header. >> [...] >> :NONAME *isn't* linked in the dictionary search; that's why it exists. > > Does it really matter if :NONAME has a header and is linked? > If the header is unfindable by FIND or ' etc... If it has a header, that defeats the purpose. Why not just have a normal colon definition? It's not the findability that :NONAME is intended to avoid, it's the space occupied by the header. >> HEADER should do all the BL WORD COUNT stuff. In other words, it should >> build a complete header. And it should *not* do any compiling! Only : >> and :NONAME compile stuff. So take out the :NONAME. > > Ok. Thanks. > > It appears I need to separate HEADER functionality from three of those > four words. I think I prefer HEADER to (CREATE). () seems to be used for > low-level words. AIR, : and ; were simpler at one point, since I started > from fig-Forth documents. I'll have to see where they became warped... Names of low-level words are up to the implementer. > Is it possible to define : in terms of :NONAME, e.g., something like: > > : CREATE :NONAME DROP ... Baffled again. Looks like you're defining CREATE, not colon. > Where :NONAME would do the compiling and/or SMUDGE? > > I.e., an attempt not to duplicate the compiling code in both : and :NONAME. In many implementations there is no "compiling code" since all you have to do is set STATE to non-zero, and the rest of the work is done by the text interpreter. In any case, "compiling code" is factorable. The important thing is to have a clear picture of the functionality of each word. You are obviously confused about the distinction between definitions and data objects and the purpose of :NONAME. That's partly because the word "definition" like "word" is occasionally used both with colon-type objects and and as a comprehensive term for all dictionary entries. The best way to keep them straight is to remember that definitions made with : and :NONAME share *nothing* with the class of objects defined by CREATE, CONSTANT, VARIABLE, etc., *except* the name field and link (and whatever other identifiers the implementation uses) in the header. 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 | oh2aun@gmail.com |
|---|---|
| Date | 2014-01-21 11:17 -0800 |
| Message-ID | <607a9320-ae2f-4a0b-b2d1-f7f6957f9d13@googlegroups.com> |
| In reply to | #27992 |
On Tuesday, January 21, 2014 8:30:26 PM UTC+2, Elizabeth D. Rather wrote: > > In many implementations there is no "compiling code" since all you have > to do is set STATE to non-zero, and the rest of the work is done by the > text interpreter. FlashForth PIC24 5.0 ok<$,ram> see :noname 4750 0007 ff77 rcall ihere 4752 0004 1f32 goto ] ok<$,ram>
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-01-21 09:44 -1000 |
| Message-ID | <NOWdnRzv-uWPU0PPnZ2dnUVZ_gCdnZ2d@supernews.com> |
| In reply to | #27993 |
On 1/21/14 9:17 AM, oh2aun@gmail.com wrote: > On Tuesday, January 21, 2014 8:30:26 PM UTC+2, Elizabeth D. Rather wrote: >> >> In many implementations there is no "compiling code" since all you have >> to do is set STATE to non-zero, and the rest of the work is done by the >> text interpreter. > > FlashForth PIC24 5.0 > ok<$,ram> > see :noname > 4750 0007 ff77 rcall ihere > 4752 0004 1f32 goto ] > ok<$,ram> > ...where ] is the word that commences compiling. Thanks, great example! 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 | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2014-01-21 15:18 -0500 |
| Message-ID | <op.w91z0xq85zc71u@localhost> |
| In reply to | #27992 |
On Tue, 21 Jan 2014 13:30:26 -0500, Elizabeth D. Rather <erather@forth.com> wrote: > On 1/21/14 6:37 AM, Rod Pemberton wrote: >> On Mon, 20 Jan 2014 17:07:17 -0500, Elizabeth D Rather >>> On 1/20/2014 11:14 AM, Rod Pemberton wrote: >>>> -sets the dictionary pointer (DP) to code field address (CFA) >>> >>> Why didn't HEADER leave it set correctly? >> >> It appears from the code an ENTER was compiled in by :NONAME, >> i.e., DP or HERE moved. So, CREATE creates an empty definition >> with just ENTER and EXIT. > > CREATE should have neither ENTER nor EXIT since it's a data object, > not a definition. > Um, sorry, I might be wrong about that ... It might be the ENTER from : is stored in the CFA. But, the EXIT from ; would still move DP or HERE at least into the 1st PFA. >>> [snip, moved up] >> >> Is it possible to define : in terms of :NONAME, e.g., something like: >> >> : CREATE :NONAME DROP ... > > Baffled again. Looks like you're defining CREATE, not colon. > Sorry, yes, that should've had two colons which was, hopefully, obvious: : : CREATE :NONAME DROP ... I have a low-level : and this would be for defining a new high-level : in Forth. Is it possible? If so, is it recommended to use :NONAME here or not? >>> The whole purpose of :NONAME is to *not* have a header. >>> [...] >>> :NONAME *isn't* linked in the dictionary search; that's why it exists. >> >> Does it really matter if :NONAME has a header and is linked? >> If the header is unfindable by FIND or ' etc... > > If it has a header, that defeats the purpose. Why not just have a > normal colon definition? Yes, I'll attempt to do that. I'll probably start by reworking the actions I posted for : ; CREATE and :NONAME into HEADER : ; CREATE and :NONAME. Then, I'll probably backtrack to see where I starting changing the definitions around. I'll likely also have to determine if I had an issue with linking definitions if a headerless :NONAME is used. > It's not the findability that :NONAME is intended to avoid, it's the > space occupied by the header. Ok. So, no header for :NONAME to conserve space. Now, I'm baffled. ISTM, if I do fix the issue with :NONAME by eliminating a header for it, then I'll break :NONAMEs functionality. I'm baffled as to how a :NONAME definition is going to be executable without a header. IIRC, an XT in my system points to the CFA in the header. The CFA field is then fetch'd to determine how to handle the definition as indicated by DOVAR DODOES ENTER etc. Without a header, there won't be a CFA with ENTER for the :NONAME defintion. The XT by itself is insufficient to tell the interpreter *how* to EXECUTE the definition. That's done by ENTER. The XT is only sufficient to tell the interpreter *where* the definition is, more specifically the CFA field in the header from which the header location and definition location can be determined. So, no header, no CFA, no ENTER, no way to tell if the XT points to a definition or a low-level "primitive" word. If I modify EXECUTE , I have no way to determine if the XT is for a regular definition with a header where I need to fetch the CFA, or a headerless :NONAME definition which won't have a CFA with ENTER. Sigh, are there some systems where :NONAME is unimplementable? E.g., ITC interpreted. Also, AIR, this issue of whether :NONAME is headerless or not was brought up previously in regards to ANS Forth. I'm not following ANS strictly, but IIRC that's where :NONAME was defined. AFAICT, ANS Forth doesn't say a :NONAME definition is headerless. It only requires :NONAME to 1) not have a name and 2) not be found. That can be done with a header in place, as I did. So, not having a name is not the same as being headerless. This goes towards the question of: "Does it really matter if :NONAME has a header and is linked? If the header is unfindable by FIND or ' etc..." This is what ANS says: "A.6.1.0460" "... If the current definition was created by :NONAME the current definition has no definition name and thus cannot be found in the dictionary." "A.6.2.0455" ":NONAME allows a user to create an execution token with the semantics of a colon definition without an associated name." *BOTH* :NONAME and : in ANS say they create a _definition_. There doesn't seem to be any mention regarding a difference in the way : and :NONAME create a definition. I.e., does the definition of "definition" include a header or not? ... Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-01-21 12:07 -1000 |
| Message-ID | <lP-dncyQC8MgckPPnZ2dnUVZ_umdnZ2d@supernews.com> |
| In reply to | #27995 |
On 1/21/14 10:18 AM, Rod Pemberton wrote: > On Tue, 21 Jan 2014 13:30:26 -0500, Elizabeth D. Rather > <erather@forth.com> wrote: >> On 1/21/14 6:37 AM, Rod Pemberton wrote: >>> On Mon, 20 Jan 2014 17:07:17 -0500, Elizabeth D Rather >>>> On 1/20/2014 11:14 AM, Rod Pemberton wrote: > >>>>> -sets the dictionary pointer (DP) to code field address (CFA) >>>> >>>> Why didn't HEADER leave it set correctly? >>> >>> It appears from the code an ENTER was compiled in by :NONAME, >>> i.e., DP or HERE moved. So, CREATE creates an empty definition >>> with just ENTER and EXIT. >> >> CREATE should have neither ENTER nor EXIT since it's a data object, >> not a definition. >> > > Um, sorry, I might be wrong about that ... > > It might be the ENTER from : is stored in the CFA. But, the EXIT > from ; would still move DP or HERE at least into the 1st PFA. The code field for CREATE needs to contain a pointer to DOVAR. There is no ; on an object built by CREATE and no EXIT. >>>> [snip, moved up] >>> >>> Is it possible to define : in terms of :NONAME, e.g., something like: >>> >>> : CREATE :NONAME DROP ... >> >> Baffled again. Looks like you're defining CREATE, not colon. >> > > Sorry, yes, that should've had two colons which was, hopefully, obvious: > > : : CREATE :NONAME DROP ... CREATE is inappropriate here. You want your word that builds a header. And :NONAME is also inappropriate because it returns the xt that you have to DROP. All you need to do is build the header, have a code field that points to DOCOL, and start the compiler. > I have a low-level : and this would be for defining a new high-level : > in Forth. Why do you need 2 versions of : ? > Is it possible? If so, is it recommended to use :NONAME here or not? It's unnecessary. See above. >>>> The whole purpose of :NONAME is to *not* have a header. >>>> [...] >>>> :NONAME *isn't* linked in the dictionary search; that's why it exists. >>> >>> Does it really matter if :NONAME has a header and is linked? >>> If the header is unfindable by FIND or ' etc... >> >> If it has a header, that defeats the purpose. Why not just have a >> normal colon definition? > > Yes, I'll attempt to do that. > > I'll probably start by reworking the actions I posted for : ; CREATE and > :NONAME into HEADER : ; CREATE and :NONAME. Then, I'll probably backtrack > to see where I starting changing the definitions around. I'll likely also > have to determine if I had an issue with linking definitions if a > headerless > :NONAME is used. There is nothing about a :NONAME to link. >> It's not the findability that :NONAME is intended to avoid, it's the >> space occupied by the header. > > Ok. So, no header for :NONAME to conserve space. Now, I'm baffled. > ISTM, if I do fix the issue with :NONAME by eliminating a header for > it, then I'll break :NONAMEs functionality. What do you think its functionality is? All it has to do is provide an xt to some compiled Forth. Look at the example provided by oh2aun above. > I'm baffled as to how a :NONAME definition is going to be executable > without a header. IIRC, an XT in my system points to the CFA in the > header. The CFA field is then fetch'd to determine how to handle > the definition as indicated by DOVAR DODOES ENTER etc. Without a header, > there won't be a CFA with ENTER for the :NONAME defintion. The XT > by itself is insufficient to tell the interpreter *how* to EXECUTE > the definition. That's done by ENTER. The XT is only sufficient to > tell the interpreter *where* the definition is, more specifically the > CFA field in the header from which the header location and definition > location can be determined. So, no header, no CFA, no ENTER, no way > to tell if the XT points to a definition or a low-level "primitive" word. Again, you are making this far too complicated. Yes, the thing built by :NONAME has a code field, normally (in an ITC Forth) the address of DODOES, followed by the executable content. The xt is the address of that code field. All EXECUTE needs to do is jump to that address. It doesn't need to "determine" anything. > If I modify EXECUTE , I have no way to determine if the XT is for a > regular definition with a header where I need to fetch the CFA, or a > headerless :NONAME definition which won't have a CFA with ENTER. > > Sigh, are there some systems where :NONAME is unimplementable? > E.g., ITC interpreted. An xt needs to be the address of the code required to execute the word. It has to be there for all words. That isn't what I'm calling the "header". A "header" consists of name and linking info. > Also, AIR, this issue of whether :NONAME is headerless or not was > brought up previously in regards to ANS Forth. I'm not following > ANS strictly, but IIRC that's where :NONAME was defined. > > AFAICT, ANS Forth doesn't say a :NONAME definition is headerless. > It only requires :NONAME to 1) not have a name and 2) not be found. > That can be done with a header in place, as I did. So, not having > a name is not the same as being headerless. This goes towards > the question of: > > "Does it really matter if :NONAME has a header and is linked? > If the header is unfindable by FIND or ' etc..." The only conceivable reason for having :NONAME is so that you can have a sequence of Forth code without a header. It consists of a code field followed by the code. > This is what ANS says: > > "A.6.1.0460" > > "... If the current definition was created by > :NONAME the current definition has no definition name > and thus cannot be found in the dictionary." > > "A.6.2.0455" > > ":NONAME allows a user to create an execution token with > the semantics of a colon definition without an associated > name." > > > *BOTH* :NONAME and : in ANS say they create a _definition_. > There doesn't seem to be any mention regarding a difference > in the way : and :NONAME create a definition. I.e., does the > definition of "definition" include a header or not? ... A "definition" includes a code field (DOCOL, or whatever you call it) followed by a sequence of code in whatever form your implementation provides. Most defining words also include a header consisting of name and dictionary link, maybe other info. :NONAME doesn't. Hope this helps. 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 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | comp.lang.forth
csiph-web