Menu
▾
▴
amforth-devel
|
From: pito <pi...@vo...> - 2010-08-07 19:57:14
|
Hi friends, which one is the correct way to define 2variable in amforth: : 2variable here 2 cells allot constant ; : 2variable create 0 , 0 , ; Just to be sure we do not operate within the flash and thus we destroy it slowly...Pito. |
|
From: Leon M. <leo...@gm...> - 2010-08-08 03:17:55
|
Would your just take the old definition of variable (http://amforth.sourceforge.net/words/XT_VARIABLE.html) and replace the 2 with a 4? A more general request: could someone explain how variable works? I understand how it works in the system from Staring FORTH, but not this one. In addition, I have two more specific (and possibly quite newbish) questions. I think some of my confusion is related to HERE. The front page says it points to RAM. In (at least some of) the documentation of all the words (http://amforth.sourceforge.net/words/) it looks like it's pointing to Flash. Which is it? Also, why (CREATE) COMPILE COMPILE instead of CREATE? -Leon On Sat, Aug 7, 2010 at 2:57 PM, pito <pi...@vo...> wrote: > Hi friends, which one is the correct way to define 2variable in > amforth: > > : 2variable here 2 cells allot constant ; > : 2variable create 0 , 0 , ; > > Just to be sure we do not operate within the flash and thus we > destroy it slowly...Pito. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
|
From: Erich W. <ew....@na...> - 2010-08-08 06:52:11
|
Hi Leon, [Q] Does "here" point to flash or ram? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Prior to amforth version 4.0 here points to the next available location in flash memory and heap points to the next available location in RAM. Starting with version 4.0 here points to the next RAM location and dp points to the next flash location This is in the release notes of amforth 4.0 on the web page http://amforth.sourceforge.net/ > core: ANS94 mention that HERE points to the data (RAM) region. > Re-introduced DP as the dictionary (Flash) pointer. > HEAP is gone. > Migrate old HEAP to HERE and old HERE to DP. The migration effect is readily visible when comparing the files variable.asm diff -uw releases/3.9/core/words/variable.asm trunk/core/words/variable.asm --- releases/3.9/core/words/variable.asm 2010-06-02 11:33:51.000000000 +0200 +++ trunk/core/words/variable.asm 2010-07-02 21:16:41.000000000 +0200 @@ -12,7 +12,7 @@ .dw XT_DOCREATE .dw XT_COMPILE .dw PFA_DOVARIABLE - .dw XT_HEAP + .dw XT_HERE .dw XT_COMMA .dw XT_DOLITERAL .dw 2 So yes, there is unfortunately confusion and the answer depends on the version of amforth. [Q] How is variable and 2variable supposed to work? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "variable" is a location to hold a mutable piece of information. Thus the dicionary entry of a "variable" holds (in flash) a pointer to a RAM location. In a purely RAM based Forth (e.g. gforth) the definition : variable create> 0 , 0 , ; is perfectly adequate, because *everything* is in RAM anyway. In a flash based Forth as amforth the definition is more like : variable create> here , \ store addr of next avail. RAM 2 allot \ allot 2 bytes of RAM ; replacing 2 by 4 allocates 4 bytes indeed. However, the behaviour of the words involved in converting the character input (eg. "100.") into a double cell number must work consistently, too. I'm not an expert at this. The current definition of 2variable (trunk, verion 4.1) is found in trunk/lib/ans94/2x.frt : 2variable here 2 cells allot constant ; the value of "here" is put into a constant (flash) and thus points to the alloted RAM location. No need to use "create>". Nice! BTW that is how you create an array of arbitrary length. here 20 cells allot constant myArray (and yes, here used to be heap before version 4.0) Hope this helps. Cheers, Erich On 08/08/2010 05:17 AM, Leon Maurer wrote: > Would your just take the old definition of variable > (http://amforth.sourceforge.net/words/XT_VARIABLE.html) and replace > the 2 with a 4? > > A more general request: could someone explain how variable works? > > I understand how it works in the system from Staring FORTH, but not this one. > > In addition, I have two more specific (and possibly quite newbish) questions. > > I think some of my confusion is related to HERE. The front page says > it points to RAM. In (at least some of) the documentation of all the > words (http://amforth.sourceforge.net/words/) it looks like it's > pointing to Flash. Which is it? > > Also, why (CREATE) COMPILE COMPILE instead of CREATE? > -Leon > > On Sat, Aug 7, 2010 at 2:57 PM, pito<pi...@vo...> wrote: >> Hi friends, which one is the correct way to define 2variable in >> amforth: >> >> : 2variable here 2 cells allot constant ; >> : 2variable create 0 , 0 , ; >> >> Just to be sure we do not operate within the flash and thus we >> destroy it slowly...Pito. >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> Amforth-devel mailing list >> Amf...@li... >> https://lists.sourceforge.net/lists/listinfo/amforth-devel >> > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: Matt W. <wi...@gm...> - 2010-08-08 10:58:06
|
The best thing you can do in order to understand the inner workings of amforth (or any other forth), is to look at jonesforth http://www.annexia.org/forth and then get a copy of Threaded Interpretive Languages. I speak from experience. Matt |
|
From: Matthias T. <mt...@we...> - 2010-08-08 18:07:50
|
Hi Matt, > The best thing you can do in order to understand the inner workings of > amforth (or any other forth), is to look at jonesforth > > http://www.annexia.org/forth > > and then get a copy of Threaded Interpretive Languages. Be careful however. The Jonesforth implementations of many words are different from the amforth versions. So do not expect to understand amforth from jonesforth sources ;=) A prominent example is the difference between variable and constant: in amforth there is no runtime difference, variables are slightly customized constants at definition time. Matthias PS: I did not yet found fixes for the current bugs... still thinking... |
|
From: Matt W. <wi...@gm...> - 2010-08-08 20:38:03
|
> Be careful however. The Jonesforth implementations of > many words are different from the amforth versions. So > do not expect to understand amforth from jonesforth > sources ;=) Of course, the devel and differences are in the details (in this case, most notabl, Harvard vs. Von Neuman). However, once you get a handle on ITC and "writing Forth in assembler", it's possible to dig into the amforth source and understand what's going on. I found Jones one of the gentlest introductions. Matt |
|
From: Leon M. <leo...@gm...> - 2010-08-08 19:24:24
|
Thanks for the reply. As usual, this leads to more questions. > Prior to amforth version 4.0 > here points to the next available location in flash memory and > heap points to the next available location in RAM. > > Starting with version 4.0 > here points to the next RAM location and > dp points to the next flash location Have the word definitions available at http://amforth.sourceforge.net/words/ been updated to reflect this change, or are they using the old definitions? > In a flash based Forth as amforth the definition is more like > : variable > create> > here , \ store addr of next avail. RAM > 2 allot \ allot 2 bytes of RAM > ; That makes sense to me, but I'm still interested in definition amforth uses: http://amforth.sourceforge.net/words/XT_VARIABLE.html Why "(CREATE) COMPILE COMPILE" instead of CREATE? What is (literal) doing in front of the 2? Shouldn't sticking (literal) in the definition be handled by ':' ? I take it that (unnamed) replaces ',' since we want to store the address in flash. Thanks -Leon |
|
From: Matthias T. <mt...@we...> - 2010-08-09 18:11:44
|
Leon, > Have the word definitions available at > http://amforth.sourceforge.net/words/ been updated to reflect this > change, or are they using the old definitions? They usually reflect the bleeding edge of development but not every subversion commit. Currently it shows the brand new implementation of variable based upon constant... > That makes sense to me, but I'm still interested in definition amforth uses: > > http://amforth.sourceforge.net/words/XT_VARIABLE.html > > Why "(CREATE) COMPILE COMPILE" instead of CREATE? What is (literal) > doing in front of the 2? You'd better read the sources, since the html versions are somewhat broken, the script generating the files tries to make forth code from the assembly sources, with mixed success however.. > Shouldn't sticking (literal) in the The sequence (literal) <number> is a 1:1 translation of a compiled number. Think of it as the number only. The (create) word is a factor from the defining words that makes only a vocabulary entry without an XT or data field. The XT is filled afterwardds by words like : (with the DO_COLON address) or variable/constant (with PFA_DOVARIABLE) etc. A RAM based dictionary would not need to do so, but a flash based one will honor the not necessairy flash re-write that is needed while overwriting the XT. Matthias |
|
From: Leon M. <leo...@gm...> - 2010-08-10 02:20:13
|
I think I'm understanding this now, so hopefully one more round of questions will clear everything up. On Mon, Aug 9, 2010 at 1:11 PM, Matthias Trute <mt...@we...> wrote: > They usually reflect the bleeding edge of development but > not every subversion commit. Currently it shows the > brand new implementation of variable based upon constant... The description of HERE reads "address of the next free dictionary cell" -- which sounds like the old version. So is the code bleeding edge but not the comments? http://amforth.sourceforge.net/words/XT_HERE.html > You'd better read the sources, since the html versions are somewhat > broken, the script generating the files tries to make forth > code from the assembly sources, with mixed success however.. ... > The sequence (literal) <number> is a 1:1 translation of a > compiled number. Think of it as the number only. So the html is based off the sources, which has definitions that are essentially compiled by hand? But if I were defining VARIABLE interactively, ':' would take care of adding (LITERAL) for me? > The (create) word is a factor from the defining words that > makes only a vocabulary entry without an XT or data field. > The XT is filled afterwardds by words like : (with the DO_COLON > address) or variable/constant (with PFA_DOVARIABLE) etc. A RAM > based dictionary would not need to do so, but a flash based one > will honor the not necessairy flash re-write that is needed while > overwriting the XT. Is the "(CREATE) COMPILE COMPILE" in the definition of VARIABLE another artifact of being compiled by hand? If I were defining VARIABLE interactively, I would be able to use CREATE? Thanks again for your patience in answering all of this. -Leon |
|
From: Matthias T. <mt...@we...> - 2010-08-10 12:40:39
|
Leon, > The description of HERE reads "address of the next free dictionary > cell" -- which sounds like the old version. So is the code bleeding > edge but not the comments? Have you ever seen a valid and correct comment in source code? ;=) just fixed it, thank you. > So the html is based off the sources, which has definitions that are > essentially compiled by hand? Yes. > But if I were defining VARIABLE > interactively, ':' would take care of adding (LITERAL) for me? The (literal) is included automatically (and needs to get smarter somehow for dealing with double cell numbers, see Pitos bug with the 1.). > Is the "(CREATE) COMPILE COMPILE" in the definition of VARIABLE > another artifact of being compiled by hand? There is no compile compile... ? And never has been in variable.asm? the sequence "compile compile" can be the result of a "postpone compile" in real forth code. > If I were defining > VARIABLE interactively, I would be able to use CREATE? sure. The current definition is as follows: : variable here constant 2 allot ; Matthias |
|
From: Leon M. <leo...@gm...> - 2010-08-11 01:08:39
|
Awesome -- I'm all set then. Thanks again for explaining all this. -Leon |
Thanks for helping keep SourceForge clean.
X