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

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

bug report Bernd Paysan's bigForth v231 v240

Started by"Rod Pemberton" <do_not_have@noavailemail.cmm>
First post2012-01-24 18:26 -0500
Last post2012-02-07 17:12 +0100
Articles 20 on this page of 64 — 17 participants

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

Contents

  bug report Bernd Paysan's bigForth v231 v240 "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-24 18:26 -0500
    Re: bug report Bernd Paysan's bigForth v231 v240 Brad <hwfwguy@gmail.com> - 2012-01-24 16:06 -0800
      Re: bug report Bernd Paysan's bigForth v231 v240 David Kuehling <dvdkhlng@gmx.de> - 2012-01-25 11:03 +0100
      Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-25 04:31 -0800
        Re: bug report Bernd Paysan's bigForth v231 v240 "Elizabeth D. Rather" <erather@forth.com> - 2012-01-25 08:00 -1000
          Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-25 10:04 -0800
    Re: bug report Bernd Paysan's bigForth v231 v240 "Elizabeth D. Rather" <erather@forth.com> - 2012-01-24 14:06 -1000
      Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-25 04:40 -0800
        Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-25 04:42 -0800
        Re: bug report Bernd Paysan's bigForth v231 v240 "Elizabeth D. Rather" <erather@forth.com> - 2012-01-25 08:02 -1000
        Re: bug report Bernd Paysan's bigForth v231 v240 Coos Haak <chforth@hccnet.nl> - 2012-01-25 19:45 +0100
      Re: bug report Bernd Paysan's bigForth v231 v240 "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-25 11:00 -0500
        Re: bug report Bernd Paysan's bigForth v231 v240 Coos Haak <chforth@hccnet.nl> - 2012-01-25 19:40 +0100
          Re: bug report Bernd Paysan's bigForth v231 v240 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-26 15:37 +0000
            Re: bug report Bernd Paysan's bigForth v231 v240 Coos Haak <chforth@hccnet.nl> - 2012-01-26 22:53 +0100
        Re: bug report Bernd Paysan's bigForth v231 v240 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-25 17:50 +0000
    Re: bug report Bernd Paysan's bigForth v231 v240 "Peter Knaggs" <pjk@bcs.org.uk> - 2012-01-25 00:27 +0000
    Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-25 04:29 -0800
      Re: bug report Bernd Paysan's bigForth v231 v240 "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-25 11:01 -0500
        Re: bug report Bernd Paysan's bigForth v231 v240 "Elizabeth D. Rather" <erather@forth.com> - 2012-01-25 07:51 -1000
    Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-25 04:43 -0800
      Re: bug report Bernd Paysan's bigForth v231 v240 "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-25 11:02 -0500
        Re: bug report Bernd Paysan's bigForth v231 v240 Doug Hoffman <glidedog@gmail.com> - 2012-01-25 11:27 -0500
        Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-25 08:38 -0800
          Re: bug report Bernd Paysan's bigForth v231 v240 Arnold Doray <invalid@invalid.com> - 2012-01-26 00:54 +0000
            Re: bug report Bernd Paysan's bigForth v231 v240 Coos Haak <chforth@hccnet.nl> - 2012-01-26 22:58 +0100
              Re: bug report Bernd Paysan's bigForth v231 v240 Arnold Doray <invalid@invalid.com> - 2012-01-27 04:15 +0000
                Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-27 02:29 -0800
                  Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-27 02:44 -0800
                    Re: bug report Bernd Paysan's bigForth v231 v240 Arnold Doray <invalid@invalid.com> - 2012-01-27 14:38 +0000
                      Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-27 08:06 -0800
                      Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-27 08:08 -0800
                  Re: bug report Bernd Paysan's bigForth v231 v240 Arnold Doray <invalid@invalid.com> - 2012-01-27 15:30 +0000
                    Re: bug report Bernd Paysan's bigForth v231 v240 "Elizabeth D. Rather" <erather@forth.com> - 2012-01-27 08:06 -1000
          Re: bug report Bernd Paysan's bigForth v231 v240 "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-27 20:21 -0500
            Re: bug report Bernd Paysan's bigForth v231 v240 "Elizabeth D. Rather" <erather@forth.com> - 2012-01-27 16:19 -1000
              Re: bug report Bernd Paysan's bigForth v231 v240 "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-28 14:18 -0500
                Re: bug report Bernd Paysan's bigForth v231 v240 Alex McDonald <blog@rivadpm.com> - 2012-01-28 12:30 -0800
                Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-28 13:42 -0800
                  Re: bug report Bernd Paysan's bigForth v231 v240 Brad <hwfwguy@gmail.com> - 2012-01-28 17:37 -0800
                    Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-29 00:31 -0800
                      Re: bug report Bernd Paysan's bigForth v231 v240 "Elizabeth D. Rather" <erather@forth.com> - 2012-01-29 07:19 -1000
                      Re: bug report Bernd Paysan's bigForth v231 v240 BruceMcF <agila61@netscape.net> - 2012-01-29 15:36 -0800
                        Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-30 03:46 -0800
                          Re: bug report Bernd Paysan's bigForth v231 v240 "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-12 18:01 -0500
                Re: bug report Bernd Paysan's bigForth v231 v240 "Elizabeth D. Rather" <erather@forth.com> - 2012-01-28 13:38 -1000
                Re: bug report Bernd Paysan's bigForth v231 v240 BruceMcF <agila61@netscape.net> - 2012-01-28 19:58 -0800
                  Re: bug report Bernd Paysan's bigForth v231 v240 kenney@cix.compulink.co.uk - 2012-01-29 05:04 -0600
                    Re: bug report Bernd Paysan's bigForth v231 v240 John Passaniti <john.passaniti@gmail.com> - 2012-01-29 10:58 -0800
                    Re: bug report Bernd Paysan's bigForth v231 v240 BruceMcF <agila61@netscape.net> - 2012-01-29 16:04 -0800
                Re: bug report Bernd Paysan's bigForth v231 v240 Arnold Doray <invalid@invalid.com> - 2012-01-29 09:18 +0000
                  Re: bug report Bernd Paysan's bigForth v231 v240 "Elizabeth D. Rather" <erather@forth.com> - 2012-01-29 07:23 -1000
              Re: bug report Bernd Paysan's bigForth v231 v240 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-30 14:20 +0000
                Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-30 06:51 -0800
                  Re: bug report Bernd Paysan's bigForth v231 v240 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-30 15:08 +0000
                Re: bug report Bernd Paysan's bigForth v231 v240 Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-30 09:10 -0600
            Re: bug report Bernd Paysan's bigForth v231 v240 BruceMcF <agila61@netscape.net> - 2012-01-27 19:02 -0800
            Re: bug report Bernd Paysan's bigForth v231 v240 Brad <hwfwguy@gmail.com> - 2012-01-28 09:32 -0800
        Re: bug report Bernd Paysan's bigForth v231 v240 Mark Wills <markrobertwills@yahoo.co.uk> - 2012-01-25 08:42 -0800
        Re: bug report Bernd Paysan's bigForth v231 v240 BruceMcF <agila61@netscape.net> - 2012-01-25 09:33 -0800
        Re: bug report Bernd Paysan's bigForth v231 v240 "Elizabeth D. Rather" <erather@forth.com> - 2012-01-25 07:55 -1000
        Re: bug report Bernd Paysan's bigForth v231 v240 Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-01-25 22:17 +0000
    Re: bug report Bernd Paysan's bigForth v231 v240 BruceMcF <agila61@netscape.net> - 2012-01-25 07:30 -0800
    Re: bug report Bernd Paysan's bigForth v231 v240 Bernd Paysan <bernd.paysan@gmx.de> - 2012-02-07 17:12 +0100

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#9219

FromMark Wills <markrobertwills@yahoo.co.uk>
Date2012-01-25 04:43 -0800
Message-ID<66478a3e-d8f8-4aed-a36b-2e61806f6a21@cf6g2000vbb.googlegroups.com>
In reply to#9205
On Jan 24, 11:26 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> Bernd Paysan,
>
> I know you're not fond of my statements, but I'm probably helping you out
> with this bug report.  Are you aware of the following issue?
>
> I noticed an interesting bug with your ANS bigForth v2.3.1 and v2.4.0.
> bigForth is overwriting data in some words.  Apparently, it's writing parsed
> data to DP or HERE, like the fig-Forth code does.  However, the DP
> dictionary-pointer or HERE is not being adjusted via an ALLOT.
>
> These are two of my test sequences which work for GForth and Win32Forth:
>
> CREATE GRAPES 1 , GRAPES @ .
>
> CREATE ORANGES 1 ORANGES ! ORANGES @ .
>
> The GRAPES example works because DP is adjusted via the , COMMA.
>
> CREATE GRAPES
> 1 ,
> GRAPES @ .
>
> The ORANGE example fails because DP isn't moved after storing the number.
> The number is being overwritten with parsed data.
>
> CREATE ORANGES
> 1 ORANGES !
> ORANGES @ .
>
> If one ALLOTS, replacing ORANGE with PEARS to prevent a name collision, then
> the second sequence works.
>
> CREATE PEARS
> 1 PEARS 1 CELLS ALLOT !
> PEARS @ .
>
> How do I know all this?  My fig-Forth based interpreter is doing the exactly
> same thing ...  The adjustment via ALLOT is the same too.  Apparently, there
> is a difference in where some Forths copy their parsed data.  fig-Forth code
> copies straight to DP or HERE.  Unfortunately, the one fig-Forth for DOS I
> tested had some other failure recognizing CREATE words.  I'll attempt to
> test on another fig-Forth to see if fig-Forth actually has the issue.  I may
> not report the results here though ...
>
> At least you now know what the issue is and can fix it ...
>
> Rod Pemberton

Yep... Rod, that's definately not a bug, mate!

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

#9225

From"Rod Pemberton" <do_not_have@noavailemail.cmm>
Date2012-01-25 11:02 -0500
Message-ID<jfp955$87t$1@speranza.aioe.org>
In reply to#9219
"Mark Wills" <markrobertwills@yahoo.co.uk> wrote in message
news:66478a3e-d8f8-4aed-a36b-2e61806f6a21@cf6g2000vbb.googlegroups.com...
...

> Yep... Rod, that's definately not a bug, mate!

The bug is that bigForth has parsing data overwriting the dictionary space,
which in this case is the initially the stored number.  Neither Gforth nor
Win32Forth adjust HERE or DP or ALLOT or COMMA either.  They don't
corrupt the initially stored value as long as nothing else is stored in the
dictionary.  Once something is stored in the dictionary, they overwrite the
initially stored value.  The actual allocation of the space stored into can
occur at some later point in time, either by a , COMMA or by an ALLOT.

See for yourself:


bigFORTH 1.4.0
CREATE ORANGE ok
1 ORANGE ! ok
ORANGE @ . 1092632577 ok
5 , ok
ORANGE @ . 5 ok

Gforth 0.7.0
CREATE ORANGE ok
1 ORANGE ! ok
ORANGE @ . 1 ok
5 , ok
ORANGE @ . 5 ok

Win32Forth 6.14.00
CREATE ORANGE ok
1 ORANGE !
ORANGE @ . 1 ok
5 , ok
ORANGE @ . 5 ok


I just tested 21 Forths.  13 work.  6 fail.  2 have other issues.  Standard
behavior seems to be to not overwrite dictionary space when parsing.


Rod Pemberton

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

#9226

FromDoug Hoffman <glidedog@gmail.com>
Date2012-01-25 11:27 -0500
Message-ID<4f202d62$0$282$14726298@news.sunsite.dk>
In reply to#9225
On 1/25/12 11:02 AM, Rod Pemberton wrote:

> CREATE ORANGE ok
> 1 ORANGE ! ok
... more defs
orange @ . => undefined

I don't know anything about fig-Forth (which you mentioned in your first 
post).

It is clear, at least to me, in reading the ANS docs that the above code 
should not be expected to give reliable results in ANS Forth.

The following should work for all ANS Forths (have no idea what happens 
on non-ANS):

create orange 55 ,
100 , \ or parse some text or whatever
orange @ . => 55
orange cell+ @ . => 100

\ or
create orange' 1 cells allot
65 orange' !
200 , \ or parse some text or whatever
orange' @ . => 65
orange' cell+ @ . => 200

-Doug

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

#9227

FromMark Wills <markrobertwills@yahoo.co.uk>
Date2012-01-25 08:38 -0800
Message-ID<692e810d-4789-456d-8b63-829cd518232c@do4g2000vbb.googlegroups.com>
In reply to#9225
On Jan 25, 4:02 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Mark Wills" <markrobertwi...@yahoo.co.uk> wrote in message
>
> news:66478a3e-d8f8-4aed-a36b-2e61806f6a21@cf6g2000vbb.googlegroups.com...
> ...
>
> > Yep... Rod, that's definately not a bug, mate!
>
> The bug is that bigForth has parsing data overwriting the dictionary space,
> which in this case is the initially the stored number.  Neither Gforth nor
> Win32Forth adjust HERE or DP or ALLOT or COMMA either.  They don't
> corrupt the initially stored value as long as nothing else is stored in the
> dictionary.  Once something is stored in the dictionary, they overwrite the
> initially stored value.  The actual allocation of the space stored into can
> occur at some later point in time, either by a , COMMA or by an ALLOT.
>
> See for yourself:
>
> bigFORTH 1.4.0
> CREATE ORANGE ok
> 1 ORANGE ! ok
> ORANGE @ . 1092632577 ok
> 5 , ok
> ORANGE @ . 5 ok
>
> Gforth 0.7.0
> CREATE ORANGE ok
> 1 ORANGE ! ok
> ORANGE @ . 1 ok
> 5 , ok
> ORANGE @ . 5 ok
>
> Win32Forth 6.14.00
> CREATE ORANGE ok
> 1 ORANGE !
> ORANGE @ . 1 ok
> 5 , ok
> ORANGE @ . 5 ok
>
> I just tested 21 Forths.  13 work.  6 fail.  2 have other issues.  Standard
> behavior seems to be to not overwrite dictionary space when parsing.
>
> Rod Pemberton

I see what you mean, Rod. However, I still don't think it is a bug.
I'll try to explain why. Sometimes it's difficult to explain things in
a text only environment such as this. If this was down the pub then it
would be on the back of beer mats, and consequently much easier!

Let's look at this:

CREATE FRED 99 ,

What you end up with, on an ITC system, is something like this:

                            HERE
------+---------+----+----+  v
 FRED | DO_PUSH | 0* | 99 |
------+---------+----+----+

Here, comma compiled in the value 99 and advanced HERE. Consequently,
HERE is pointing to the cell after 99.

Now, if we look at just CREATE FRED

                      HERE
------+---------+----+--v-+
 FRED | DO_PUSH | 0* |    |
------+---------+----+----+

At this point, HERE is pointing to the body of the CREATEd word, ready
for a value to be "comma'd" in. If it didn't do that (i.e. if CREATE
itself advance HERE then you'd waste a cell when compiling an array/
list:

CREATE LIST 1 , 2 , 3 ,

-----+---------+----+---------+---+---+---+
LIST | DO_PUSH | 0* | <empty> | 1 | 2 | 3 |
-----+---------+----+---------+---+---+---+

In this case, in order to access the first value in the list, one
would need to do:

LIST 1 CELLS + @

Not nice.

So, it seems, with bigForth, that it's using HERE for something, and
it's tripping you up, because you didn't compile a value into the body
of the word you created as was expected.

You should find that the following works:

CREATE APPLES 1 CELLS ALLOT

EXACTLY the same thing happens on my system as in bigForth, and I can
see why (though it confused me at first).

Did you try the code I posted earlier?

CREATE FRED
: TEST 1 2 3 ;
FRED
error: FRED not found

This is because, what gets compiled, is this:

                     BODY
-----+---------+----+------+-------+-----+---+-----+---+------+
FRED | DO_PUSH | 0* | TEST | LIT 1 | LIT | 2 | LIT | 3 | EXIT |
-----+---------+----+------+-------+-----+---+-----+---+------+
  ^--------------------+

So, the *body* of FRED actually has a part of the definition of TEST
in it.

Whereas:

CREATE FRED 1 CELLS ALLOT
: TEST 1 2 3 ;

Works. Because the following is compiled:

                     BODY
-----+---------+----+------+------+-------+-----+---+-----+---+------+
FRED | DO_PUSH | 0* | <??> | TEST | LIT 1 | LIT | 2 | LIT | 3 | EXIT |
-----+---------+----+------+------+-------+-----+---+-----+---+------+
  ^---------------------------+

The <??> is un-initialised memory, since ALLOT skipped over it.

Does that make sense?



* The zero is normally compiled just in case a CREATEd word is
subsequently modified by DOES> - it reserves space for an address if
required. If a CREATEd word is modified by DOES> then the DO_PUSH
(which just pushes the address of the body of the created word) is
replace with DO_DOES and the 0 in front of it is replaced with the
address of the code just after DOES> in the parent word.

HTH.

Mark

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

#9241

FromArnold Doray <invalid@invalid.com>
Date2012-01-26 00:54 +0000
Message-ID<jfq87j$57g$1@dont-email.me>
In reply to#9227
On Wed, 25 Jan 2012 08:38:33 -0800, Mark Wills wrote:


> 
> EXACTLY the same thing happens on my system as in bigForth, and I can
> see why (though it confused me at first).
> 
> Did you try the code I posted earlier?
> 
> CREATE FRED : TEST 1 2 3 ;
> FRED error: FRED not found
> 

Is this true in general or just for bigForth & TurboForth? On GForth I 
get this: 

Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
create fred : test 1 2 3  ;   ok
fred  ok
.S <1> 4538600280  ok
test  ok
.S <4> 4538600280 1 2 3  ok


> This is because, what gets compiled, is this:
> 
>                      BODY
> -----+---------+----+------+-------+-----+---+-----+---+------+
> FRED | DO_PUSH | 0* | TEST | LIT 1 | LIT | 2 | LIT | 3 | EXIT |
> -----+---------+----+------+-------+-----+---+-----+---+------+
>   ^--------------------+
> 
> So, the *body* of FRED actually has a part of the definition of TEST in
> it.
> 

You lost me there... Shouldn't the : (COLON) create a new dictionary 
entry for TEST, thereby ending FRED's definition? 

But even assuming that your diagram is right, why is FRED "not found"?

Thanks,
Arnold

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

#9245

FromCoos Haak <chforth@hccnet.nl>
Date2012-01-26 22:58 +0100
Message-ID<6w8ox9r5rxpy.9w84bdzfm5op.dlg@40tude.net>
In reply to#9241
Op Thu, 26 Jan 2012 00:54:12 +0000 (UTC) schreef Arnold Doray:

> On Wed, 25 Jan 2012 08:38:33 -0800, Mark Wills wrote:
> 
> 
>> 
>> EXACTLY the same thing happens on my system as in bigForth, and I can
>> see why (though it confused me at first).
>> 
>> Did you try the code I posted earlier?
>> 
>> CREATE FRED : TEST 1 2 3 ;
>> FRED error: FRED not found
>> 
> 
> Is this true in general or just for bigForth & TurboForth? On GForth I 
> get this: 
> 
> Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `bye' to exit
> create fred : test 1 2 3  ;   ok
> fred  ok
> .S <1> 4538600280  ok
> test  ok
> .S <4> 4538600280 1 2 3  ok
> 
> 
>> This is because, what gets compiled, is this:
>> 
>>                      BODY
>> -----+---------+----+------+-------+-----+---+-----+---+------+
>> FRED | DO_PUSH | 0* | TEST | LIT 1 | LIT | 2 | LIT | 3 | EXIT |
>> -----+---------+----+------+-------+-----+---+-----+---+------+
>>   ^--------------------+
>> 
>> So, the *body* of FRED actually has a part of the definition of TEST in
>> it.
>> 
> 
> You lost me there... Shouldn't the : (COLON) create a new dictionary 
> entry for TEST, thereby ending FRED's definition? 
CREATE FRED created the definion and finished it at the same instant.
The colon has nothing to do with it, it started the definition TEST
> 
> But even assuming that your diagram is right, why is FRED "not found"?

FRED is found, you typed it in and Gforth answered with its data address,
4538600280

> 
> Thanks,
> Arnold


-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html

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

#9247

FromArnold Doray <invalid@invalid.com>
Date2012-01-27 04:15 +0000
Message-ID<jft8de$62b$1@dont-email.me>
In reply to#9245
On Thu, 26 Jan 2012 22:58:06 +0100, Coos Haak wrote:

> Op Thu, 26 Jan 2012 00:54:12 +0000 (UTC) schreef Arnold Doray:
> 
>> On Wed, 25 Jan 2012 08:38:33 -0800, Mark Wills wrote:
>> 
>> 
>> 
>>> EXACTLY the same thing happens on my system as in bigForth, and I can
>>> see why (though it confused me at first).
>>> 
>>> Did you try the code I posted earlier?
>>> 
>>> CREATE FRED : TEST 1 2 3 ;
>>> FRED error: FRED not found
>>> 
>>> 
>> Is this true in general or just for bigForth & TurboForth? On GForth I
>> get this:
>> 
>> Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
>> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
>> Type `bye' to exit create fred : test 1 2 3  ;   ok fred  ok .S <1>
>> 4538600280  ok test  ok .S <4> 4538600280 1 2 3  ok
>> 
>> 
>>> This is because, what gets compiled, is this:
>>> 
>>>                      BODY
>>> -----+---------+----+------+-------+-----+---+-----+---+------+
>>> FRED | DO_PUSH | 0* | TEST | LIT 1 | LIT | 2 | LIT | 3 | EXIT |
>>> -----+---------+----+------+-------+-----+---+-----+---+------+
>>>   ^--------------------+
>>> 
>>> So, the *body* of FRED actually has a part of the definition of TEST
>>> in it.
>>> 
>>> 
>> You lost me there... Shouldn't the : (COLON) create a new dictionary
>> entry for TEST, thereby ending FRED's definition?
> CREATE FRED created the definion and finished it at the same instant.
> The colon has nothing to do with it, it started the definition TEST
>> 
>> But even assuming that your diagram is right, why is FRED "not found"?
> 
> FRED is found, you typed it in and Gforth answered with its data
> address,
> 4538600280
> 

I was refering to Mark's diagram and explanations. I don't understand his 
explanations for FRED and TEST. GForth's behaviour is what I expect any 
Forth to do, and is unsurprising. -AD

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

#9248

FromMark Wills <markrobertwills@yahoo.co.uk>
Date2012-01-27 02:29 -0800
Message-ID<dd103a99-683b-40e7-b9fc-5a5c6ac62d2f@w5g2000yqn.googlegroups.com>
In reply to#9247
On Jan 27, 4:15 am, Arnold Doray <inva...@invalid.com> wrote:
> On Thu, 26 Jan 2012 22:58:06 +0100, Coos Haak wrote:
> > Op Thu, 26 Jan 2012 00:54:12 +0000 (UTC) schreef Arnold Doray:
>
> >> On Wed, 25 Jan 2012 08:38:33 -0800, Mark Wills wrote:
>
> >>> EXACTLY the same thing happens on my system as in bigForth, and I can
> >>> see why (though it confused me at first).
>
> >>> Did you try the code I posted earlier?
>
> >>> CREATE FRED : TEST 1 2 3 ;
> >>> FRED error: FRED not found
>
> >> Is this true in general or just for bigForth & TurboForth? On GForth I
> >> get this:
>
> >> Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
> >> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> >> Type `bye' to exit create fred : test 1 2 3  ;   ok fred  ok .S <1>
> >> 4538600280  ok test  ok .S <4> 4538600280 1 2 3  ok
>
> >>> This is because, what gets compiled, is this:
>
> >>>                      BODY
> >>> -----+---------+----+------+-------+-----+---+-----+---+------+
> >>> FRED | DO_PUSH | 0* | TEST | LIT 1 | LIT | 2 | LIT | 3 | EXIT |
> >>> -----+---------+----+------+-------+-----+---+-----+---+------+
> >>>   ^--------------------+
>
> >>> So, the *body* of FRED actually has a part of the definition of TEST
> >>> in it.
>
> >> You lost me there... Shouldn't the : (COLON) create a new dictionary
> >> entry for TEST, thereby ending FRED's definition?
> > CREATE FRED created the definion and finished it at the same instant.
> > The colon has nothing to do with it, it started the definition TEST
>
> >> But even assuming that your diagram is right, why is FRED "not found"?
>
> > FRED is found, you typed it in and Gforth answered with its data
> > address,
> > 4538600280
>
> I was refering to Mark's diagram and explanations. I don't understand his
> explanations for FRED and TEST. GForth's behaviour is what I expect any
> Forth to do, and is unsurprising. -AD

Actually Arnold, you're right.

I just tried it again in TurboForth and it worked fine. I don't know
what I was thinking.

However, my explanation regarding what happens in the dictionary (or
rather, what the memory looks like after compilation) is correct:

CREATE FRED
: TEST 1 2 3 ;
FRED @ $.
>> A2EA ok:0
' TEST >LINK @ $.
>> A2EA ok:0

So... What's that 0xA2EA value in FRED? When we do FRED @ we get A2EA.
Where did that come from? It's the value stored in the *back pointer
field* of *dictionary entry* of *TEST*! In other words, TESTs back
pointer points to A2EA, which is the beginning of FREDs dictionary
entry!

So, when you do CREATE FRED memory looks like this:

-----+---------+---+
FRED | DO_PUSH | *-----HERE
-----+---------+---+

So, HERE is currently pointing at the BODY of FRED (effectively
waiting for a value to be comma'd in).

However, we don't comma in a value. We begin a new definition:

: TEST 1 2 3 ;

Which gives us (ITC)

------+---------+------+-------+-----+---+-----+---+-----+---+------+
 FRED | DO_PUSH | TEST | DOCOL | LIT | 1 | LIT | 2 | LIT | 3 | EXIT |
------+---------+------+-------+-----+---+-----+---+-----+---+------+
   ^               |
   +---------------+

The beginning of the definition of TEST (which in my case is the back
pointer to the previous definition (FRED)) lies in the BODY of FRED.

Such that FRED @ reveals the value in the back-pointer field of TEST -
as evidenced by:

' TEST >LINK @ $.
A2EA ok:0

Confusing, huh!? But it is correct.

However, you *are* correct. There's no reason for the definition of
FRED to be lost. I apologise for misleading you. I just tried it now
in TurboForth and it does work.

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

#9249

FromMark Wills <markrobertwills@yahoo.co.uk>
Date2012-01-27 02:44 -0800
Message-ID<a6b90129-1151-4010-add4-1d84307c9b3a@g27g2000yqa.googlegroups.com>
In reply to#9248
On Jan 27, 10:29 am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> On Jan 27, 4:15 am, Arnold Doray <inva...@invalid.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Thu, 26 Jan 2012 22:58:06 +0100, Coos Haak wrote:
> > > Op Thu, 26 Jan 2012 00:54:12 +0000 (UTC) schreef Arnold Doray:
>
> > >> On Wed, 25 Jan 2012 08:38:33 -0800, Mark Wills wrote:
>
> > >>> EXACTLY the same thing happens on my system as in bigForth, and I can
> > >>> see why (though it confused me at first).
>
> > >>> Did you try the code I posted earlier?
>
> > >>> CREATE FRED : TEST 1 2 3 ;
> > >>> FRED error: FRED not found
>
> > >> Is this true in general or just for bigForth & TurboForth? On GForth I
> > >> get this:
>
> > >> Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
> > >> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> > >> Type `bye' to exit create fred : test 1 2 3  ;   ok fred  ok .S <1>
> > >> 4538600280  ok test  ok .S <4> 4538600280 1 2 3  ok
>
> > >>> This is because, what gets compiled, is this:
>
> > >>>                      BODY
> > >>> -----+---------+----+------+-------+-----+---+-----+---+------+
> > >>> FRED | DO_PUSH | 0* | TEST | LIT 1 | LIT | 2 | LIT | 3 | EXIT |
> > >>> -----+---------+----+------+-------+-----+---+-----+---+------+
> > >>>   ^--------------------+
>
> > >>> So, the *body* of FRED actually has a part of the definition of TEST
> > >>> in it.
>
> > >> You lost me there... Shouldn't the : (COLON) create a new dictionary
> > >> entry for TEST, thereby ending FRED's definition?
> > > CREATE FRED created the definion and finished it at the same instant.
> > > The colon has nothing to do with it, it started the definition TEST
>
> > >> But even assuming that your diagram is right, why is FRED "not found"?
>
> > > FRED is found, you typed it in and Gforth answered with its data
> > > address,
> > > 4538600280
>
> > I was refering to Mark's diagram and explanations. I don't understand his
> > explanations for FRED and TEST. GForth's behaviour is what I expect any
> > Forth to do, and is unsurprising. -AD
>
> Actually Arnold, you're right.
>
> I just tried it again in TurboForth and it worked fine. I don't know
> what I was thinking.
>
> However, my explanation regarding what happens in the dictionary (or
> rather, what the memory looks like after compilation) is correct:
>
> CREATE FRED
> : TEST 1 2 3 ;
> FRED @ $.
>
> >> A2EA ok:0
> ' TEST >LINK @ $.
> >> A2EA ok:0
>
> So... What's that 0xA2EA value in FRED? When we do FRED @ we get A2EA.
> Where did that come from? It's the value stored in the *back pointer
> field* of *dictionary entry* of *TEST*! In other words, TESTs back
> pointer points to A2EA, which is the beginning of FREDs dictionary
> entry!
>
> So, when you do CREATE FRED memory looks like this:
>
> -----+---------+---+
> FRED | DO_PUSH | *-----HERE
> -----+---------+---+
>
> So, HERE is currently pointing at the BODY of FRED (effectively
> waiting for a value to be comma'd in).
>
> However, we don't comma in a value. We begin a new definition:
>
> : TEST 1 2 3 ;
>
> Which gives us (ITC)
>
> ------+---------+------+-------+-----+---+-----+---+-----+---+------+
>  FRED | DO_PUSH | TEST | DOCOL | LIT | 1 | LIT | 2 | LIT | 3 | EXIT |
> ------+---------+------+-------+-----+---+-----+---+-----+---+------+
>    ^               |
>    +---------------+
>
> The beginning of the definition of TEST (which in my case is the back
> pointer to the previous definition (FRED)) lies in the BODY of FRED.
>
> Such that FRED @ reveals the value in the back-pointer field of TEST -
> as evidenced by:
>
> ' TEST >LINK @ $.
> A2EA ok:0
>
> Confusing, huh!? But it is correct.
>
> However, you *are* correct. There's no reason for the definition of
> FRED to be lost. I apologise for misleading you. I just tried it now
> in TurboForth and it does work.

If you're interested in trying it in TurboForth then you could visit
www.harmlesslion.com and download Classic99 from here:

http://www.harmlesslion.com/cgi-bin/showprog.cgi?Windows

Classic99 is a TI-99/4A emulator for Windows (not written by me). The
author has included TurboForth (it's embedded in the .exe) and the
util disk which accompanies it.

TurboForth may not be to your taste however, as it's very retro, 80's
style (though it is F83 not FIG).

<Entire CLF community rolls eyes!>

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

#9251

FromArnold Doray <invalid@invalid.com>
Date2012-01-27 14:38 +0000
Message-ID<jfuct5$sjp$1@dont-email.me>
In reply to#9249
On Fri, 27 Jan 2012 02:44:47 -0800, Mark Wills wrote:

> On Jan 27, 10:29 am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
>> On Jan 27, 4:15 am, Arnold Doray <inva...@invalid.com> wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > On Thu, 26 Jan 2012 22:58:06 +0100, Coos Haak wrote:
>> > > Op Thu, 26 Jan 2012 00:54:12 +0000 (UTC) schreef Arnold Doray:
>>
>> > >> On Wed, 25 Jan 2012 08:38:33 -0800, Mark Wills wrote:
>>
>> > >>> EXACTLY the same thing happens on my system as in bigForth, and I
>> > >>> can see why (though it confused me at first).
>>
>> > >>> Did you try the code I posted earlier?
>>
>> > >>> CREATE FRED : TEST 1 2 3 ;
>> > >>> FRED error: FRED not found
>>
>> > >> Is this true in general or just for bigForth & TurboForth? On
>> > >> GForth I get this:
>>
>> > >> Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation,
>> > >> Inc. Gforth comes with ABSOLUTELY NO WARRANTY; for details type
>> > >> `license' Type `bye' to exit create fred : test 1 2 3  ;   ok fred
>> > >>  ok .S <1>
>> > >> 4538600280  ok test  ok .S <4> 4538600280 1 2 3  ok
>>
>> > >>> This is because, what gets compiled, is this:
>>
>> > >>>                      BODY
>> > >>> -----+---------+----+------+-------+-----+---+-----+---+------+
>> > >>> FRED | DO_PUSH | 0* | TEST | LIT 1 | LIT | 2 | LIT | 3 | EXIT |
>> > >>> -----+---------+----+------+-------+-----+---+-----+---+------+
>> > >>>   ^--------------------+
>>
>> > >>> So, the *body* of FRED actually has a part of the definition of
>> > >>> TEST in it.
>>
>> > >> You lost me there... Shouldn't the : (COLON) create a new
>> > >> dictionary entry for TEST, thereby ending FRED's definition?
>> > > CREATE FRED created the definion and finished it at the same
>> > > instant.
>> > > The colon has nothing to do with it, it started the definition TEST
>>
>> > >> But even assuming that your diagram is right, why is FRED "not
>> > >> found"?
>>
>> > > FRED is found, you typed it in and Gforth answered with its data
>> > > address,
>> > > 4538600280
>>
>> > I was refering to Mark's diagram and explanations. I don't understand
>> > his explanations for FRED and TEST. GForth's behaviour is what I
>> > expect any Forth to do, and is unsurprising. -AD
>>
>> Actually Arnold, you're right.
>>
>> I just tried it again in TurboForth and it worked fine. I don't know
>> what I was thinking.
>>
>> However, my explanation regarding what happens in the dictionary (or
>> rather, what the memory looks like after compilation) is correct:
>>
>> CREATE FRED : TEST 1 2 3 ;
>> FRED @ $.
>>
>> >> A2EA ok:0
>> ' TEST >LINK @ $.
>> >> A2EA ok:0
>>
>> So... What's that 0xA2EA value in FRED? When we do FRED @ we get A2EA.
>> Where did that come from? It's the value stored in the *back pointer
>> field* of *dictionary entry* of *TEST*! In other words, TESTs back
>> pointer points to A2EA, which is the beginning of FREDs dictionary
>> entry!
>>
>> So, when you do CREATE FRED memory looks like this:
>>
>> -----+---------+---+
>> FRED | DO_PUSH | *-----HERE -----+---------+---+
>>
>> So, HERE is currently pointing at the BODY of FRED (effectively waiting
>> for a value to be comma'd in).
>>
>> However, we don't comma in a value. We begin a new definition:
>>
>> : TEST 1 2 3 ;
>>
>> Which gives us (ITC)
>>
>> ------+---------+------+-------+-----+---+-----+---+-----+---+------+
>>  FRED | DO_PUSH | TEST | DOCOL | LIT | 1 | LIT | 2 | LIT | 3 | EXIT |
>> ------+---------+------+-------+-----+---+-----+---+-----+---+------+
>>    ^               |
>>    +---------------+
>>
>> The beginning of the definition of TEST (which in my case is the back
>> pointer to the previous definition (FRED)) lies in the BODY of FRED.
>>
>> Such that FRED @ reveals the value in the back-pointer field of TEST -
>> as evidenced by:
>>
>> ' TEST >LINK @ $.
>> A2EA ok:0
>>
>> Confusing, huh!? But it is correct.
>>
>> However, you *are* correct. There's no reason for the definition of
>> FRED to be lost. I apologise for misleading you. I just tried it now in
>> TurboForth and it does work.
> 
> If you're interested in trying it in TurboForth then you could visit
> www.harmlesslion.com and download Classic99 from here:
> 
> http://www.harmlesslion.com/cgi-bin/showprog.cgi?Windows
> 
> Classic99 is a TI-99/4A emulator for Windows (not written by me). The
> author has included TurboForth (it's embedded in the .exe) and the util
> disk which accompanies it.
> 
> TurboForth may not be to your taste however, as it's very retro, 80's
> style (though it is F83 not FIG).
> 
> <Entire CLF community rolls eyes!>

Thank you for the tip on the Classic99 emulator. I have stopped using 
Windows for over a decade now, so I hope it runs on Wine. I will 
definitely give it a try.

Do you plan to release your source code? Or is it already on the website?

What made you choose the TI-99/4A? 

Cheers,
Arnold

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

#9253

FromMark Wills <markrobertwills@yahoo.co.uk>
Date2012-01-27 08:06 -0800
Message-ID<5729ad3f-a4b5-40b3-9079-d7f01347b338@c6g2000vbk.googlegroups.com>
In reply to#9251
On Jan 27, 2:38 pm, Arnold Doray <inva...@invalid.com> wrote:
> On Fri, 27 Jan 2012 02:44:47 -0800, Mark Wills wrote:
> > On Jan 27, 10:29 am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> >> On Jan 27, 4:15 am, Arnold Doray <inva...@invalid.com> wrote:
>
> >> > On Thu, 26 Jan 2012 22:58:06 +0100, Coos Haak wrote:
> >> > > Op Thu, 26 Jan 2012 00:54:12 +0000 (UTC) schreef Arnold Doray:
>
> >> > >> On Wed, 25 Jan 2012 08:38:33 -0800, Mark Wills wrote:
>
> >> > >>> EXACTLY the same thing happens on my system as in bigForth, and I
> >> > >>> can see why (though it confused me at first).
>
> >> > >>> Did you try the code I posted earlier?
>
> >> > >>> CREATE FRED : TEST 1 2 3 ;
> >> > >>> FRED error: FRED not found
>
> >> > >> Is this true in general or just for bigForth & TurboForth? On
> >> > >> GForth I get this:
>
> >> > >> Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation,
> >> > >> Inc. Gforth comes with ABSOLUTELY NO WARRANTY; for details type
> >> > >> `license' Type `bye' to exit create fred : test 1 2 3  ;   ok fred
> >> > >>  ok .S <1>
> >> > >> 4538600280  ok test  ok .S <4> 4538600280 1 2 3  ok
>
> >> > >>> This is because, what gets compiled, is this:
>
> >> > >>>                      BODY
> >> > >>> -----+---------+----+------+-------+-----+---+-----+---+------+
> >> > >>> FRED | DO_PUSH | 0* | TEST | LIT 1 | LIT | 2 | LIT | 3 | EXIT |
> >> > >>> -----+---------+----+------+-------+-----+---+-----+---+------+
> >> > >>>   ^--------------------+
>
> >> > >>> So, the *body* of FRED actually has a part of the definition of
> >> > >>> TEST in it.
>
> >> > >> You lost me there... Shouldn't the : (COLON) create a new
> >> > >> dictionary entry for TEST, thereby ending FRED's definition?
> >> > > CREATE FRED created the definion and finished it at the same
> >> > > instant.
> >> > > The colon has nothing to do with it, it started the definition TEST
>
> >> > >> But even assuming that your diagram is right, why is FRED "not
> >> > >> found"?
>
> >> > > FRED is found, you typed it in and Gforth answered with its data
> >> > > address,
> >> > > 4538600280
>
> >> > I was refering to Mark's diagram and explanations. I don't understand
> >> > his explanations for FRED and TEST. GForth's behaviour is what I
> >> > expect any Forth to do, and is unsurprising. -AD
>
> >> Actually Arnold, you're right.
>
> >> I just tried it again in TurboForth and it worked fine. I don't know
> >> what I was thinking.
>
> >> However, my explanation regarding what happens in the dictionary (or
> >> rather, what the memory looks like after compilation) is correct:
>
> >> CREATE FRED : TEST 1 2 3 ;
> >> FRED @ $.
>
> >> >> A2EA ok:0
> >> ' TEST >LINK @ $.
> >> >> A2EA ok:0
>
> >> So... What's that 0xA2EA value in FRED? When we do FRED @ we get A2EA.
> >> Where did that come from? It's the value stored in the *back pointer
> >> field* of *dictionary entry* of *TEST*! In other words, TESTs back
> >> pointer points to A2EA, which is the beginning of FREDs dictionary
> >> entry!
>
> >> So, when you do CREATE FRED memory looks like this:
>
> >> -----+---------+---+
> >> FRED | DO_PUSH | *-----HERE -----+---------+---+
>
> >> So, HERE is currently pointing at the BODY of FRED (effectively waiting
> >> for a value to be comma'd in).
>
> >> However, we don't comma in a value. We begin a new definition:
>
> >> : TEST 1 2 3 ;
>
> >> Which gives us (ITC)
>
> >> ------+---------+------+-------+-----+---+-----+---+-----+---+------+
> >>  FRED | DO_PUSH | TEST | DOCOL | LIT | 1 | LIT | 2 | LIT | 3 | EXIT |
> >> ------+---------+------+-------+-----+---+-----+---+-----+---+------+
> >>    ^               |
> >>    +---------------+
>
> >> The beginning of the definition of TEST (which in my case is the back
> >> pointer to the previous definition (FRED)) lies in the BODY of FRED.
>
> >> Such that FRED @ reveals the value in the back-pointer field of TEST -
> >> as evidenced by:
>
> >> ' TEST >LINK @ $.
> >> A2EA ok:0
>
> >> Confusing, huh!? But it is correct.
>
> >> However, you *are* correct. There's no reason for the definition of
> >> FRED to be lost. I apologise for misleading you. I just tried it now in
> >> TurboForth and it does work.
>
> > If you're interested in trying it in TurboForth then you could visit
> >www.harmlesslion.comand download Classic99 from here:
>
> >http://www.harmlesslion.com/cgi-bin/showprog.cgi?Windows
>
> > Classic99 is a TI-99/4A emulator for Windows (not written by me). The
> > author has included TurboForth (it's embedded in the .exe) and the util
> > disk which accompanies it.
>
> > TurboForth may not be to your taste however, as it's very retro, 80's
> > style (though it is F83 not FIG).
>
> > <Entire CLF community rolls eyes!>
>
> Thank you for the tip on the Classic99 emulator. I have stopped using
> Windows for over a decade now, so I hope it runs on Wine. I will
> definitely give it a try.
>
> Do you plan to release your source code? Or is it already on the website?
>
> What made you choose the TI-99/4A?
>
> Cheers,
> Arnold

Hi Arnold

The source code is available. Currently, it's only available on the
TurboForth mailing list over at Yahoo (see http://turboforth.net/download.htm)
for the mailing address URL.

However, there's no reason why I shouldn't put it up on TurboForth.net
too. I'll try and do that tonight. It's heavily commented code, mostly
in assembly, but it's quite easy to follow.

I chose the TI-99/4A simply because I'm intimately familiar with it's
architecture, and the TMS9900 instruction set. It was the first
computer in my family as a child back in '82/83.

These days, I just can't get the enthusiasm to learn Pentium machine
code on PC's, and I'm not really interested in C anymore. I like
coding on the metal.

I'm currently building a TMS9995 based machine on bread board for
"fun". TurboForth will be ported to it. I'm doing the glue logic with
an FPGA which gives me a chance to do a little VHDL. From there, I'll
probably have a go at a very simple Forth based processor. It's all
just for fun.

Mark

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

#9254

FromMark Wills <markrobertwills@yahoo.co.uk>
Date2012-01-27 08:08 -0800
Message-ID<c29c0833-1e39-490c-8c4d-5b0f7ee1252d@b18g2000vbz.googlegroups.com>
In reply to#9251
On Jan 27, 2:38 pm, Arnold Doray <inva...@invalid.com> wrote:
> On Fri, 27 Jan 2012 02:44:47 -0800, Mark Wills wrote:
> > On Jan 27, 10:29 am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> >> On Jan 27, 4:15 am, Arnold Doray <inva...@invalid.com> wrote:
>
> >> > On Thu, 26 Jan 2012 22:58:06 +0100, Coos Haak wrote:
> >> > > Op Thu, 26 Jan 2012 00:54:12 +0000 (UTC) schreef Arnold Doray:
>
> >> > >> On Wed, 25 Jan 2012 08:38:33 -0800, Mark Wills wrote:
>
> >> > >>> EXACTLY the same thing happens on my system as in bigForth, and I
> >> > >>> can see why (though it confused me at first).
>
> >> > >>> Did you try the code I posted earlier?
>
> >> > >>> CREATE FRED : TEST 1 2 3 ;
> >> > >>> FRED error: FRED not found
>
> >> > >> Is this true in general or just for bigForth & TurboForth? On
> >> > >> GForth I get this:
>
> >> > >> Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation,
> >> > >> Inc. Gforth comes with ABSOLUTELY NO WARRANTY; for details type
> >> > >> `license' Type `bye' to exit create fred : test 1 2 3  ;   ok fred
> >> > >>  ok .S <1>
> >> > >> 4538600280  ok test  ok .S <4> 4538600280 1 2 3  ok
>
> >> > >>> This is because, what gets compiled, is this:
>
> >> > >>>                      BODY
> >> > >>> -----+---------+----+------+-------+-----+---+-----+---+------+
> >> > >>> FRED | DO_PUSH | 0* | TEST | LIT 1 | LIT | 2 | LIT | 3 | EXIT |
> >> > >>> -----+---------+----+------+-------+-----+---+-----+---+------+
> >> > >>>   ^--------------------+
>
> >> > >>> So, the *body* of FRED actually has a part of the definition of
> >> > >>> TEST in it.
>
> >> > >> You lost me there... Shouldn't the : (COLON) create a new
> >> > >> dictionary entry for TEST, thereby ending FRED's definition?
> >> > > CREATE FRED created the definion and finished it at the same
> >> > > instant.
> >> > > The colon has nothing to do with it, it started the definition TEST
>
> >> > >> But even assuming that your diagram is right, why is FRED "not
> >> > >> found"?
>
> >> > > FRED is found, you typed it in and Gforth answered with its data
> >> > > address,
> >> > > 4538600280
>
> >> > I was refering to Mark's diagram and explanations. I don't understand
> >> > his explanations for FRED and TEST. GForth's behaviour is what I
> >> > expect any Forth to do, and is unsurprising. -AD
>
> >> Actually Arnold, you're right.
>
> >> I just tried it again in TurboForth and it worked fine. I don't know
> >> what I was thinking.
>
> >> However, my explanation regarding what happens in the dictionary (or
> >> rather, what the memory looks like after compilation) is correct:
>
> >> CREATE FRED : TEST 1 2 3 ;
> >> FRED @ $.
>
> >> >> A2EA ok:0
> >> ' TEST >LINK @ $.
> >> >> A2EA ok:0
>
> >> So... What's that 0xA2EA value in FRED? When we do FRED @ we get A2EA.
> >> Where did that come from? It's the value stored in the *back pointer
> >> field* of *dictionary entry* of *TEST*! In other words, TESTs back
> >> pointer points to A2EA, which is the beginning of FREDs dictionary
> >> entry!
>
> >> So, when you do CREATE FRED memory looks like this:
>
> >> -----+---------+---+
> >> FRED | DO_PUSH | *-----HERE -----+---------+---+
>
> >> So, HERE is currently pointing at the BODY of FRED (effectively waiting
> >> for a value to be comma'd in).
>
> >> However, we don't comma in a value. We begin a new definition:
>
> >> : TEST 1 2 3 ;
>
> >> Which gives us (ITC)
>
> >> ------+---------+------+-------+-----+---+-----+---+-----+---+------+
> >>  FRED | DO_PUSH | TEST | DOCOL | LIT | 1 | LIT | 2 | LIT | 3 | EXIT |
> >> ------+---------+------+-------+-----+---+-----+---+-----+---+------+
> >>    ^               |
> >>    +---------------+
>
> >> The beginning of the definition of TEST (which in my case is the back
> >> pointer to the previous definition (FRED)) lies in the BODY of FRED.
>
> >> Such that FRED @ reveals the value in the back-pointer field of TEST -
> >> as evidenced by:
>
> >> ' TEST >LINK @ $.
> >> A2EA ok:0
>
> >> Confusing, huh!? But it is correct.
>
> >> However, you *are* correct. There's no reason for the definition of
> >> FRED to be lost. I apologise for misleading you. I just tried it now in
> >> TurboForth and it does work.
>
> > If you're interested in trying it in TurboForth then you could visit
> >www.harmlesslion.comand download Classic99 from here:
>
> >http://www.harmlesslion.com/cgi-bin/showprog.cgi?Windows
>
> > Classic99 is a TI-99/4A emulator for Windows (not written by me). The
> > author has included TurboForth (it's embedded in the .exe) and the util
> > disk which accompanies it.
>
> > TurboForth may not be to your taste however, as it's very retro, 80's
> > style (though it is F83 not FIG).
>
> > <Entire CLF community rolls eyes!>
>
> Thank you for the tip on the Classic99 emulator. I have stopped using
> Windows for over a decade now, so I hope it runs on Wine. I will
> definitely give it a try.
>
> Do you plan to release your source code? Or is it already on the website?
>
> What made you choose the TI-99/4A?
>
> Cheers,
> Arnold

Oh, regarding Classic99 in Wine: Yes it does work. I use it with
Ubuntu and it works just fine.

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

#9252

FromArnold Doray <invalid@invalid.com>
Date2012-01-27 15:30 +0000
Message-ID<jfufu9$sjp$2@dont-email.me>
In reply to#9248
On Fri, 27 Jan 2012 02:29:42 -0800, Mark Wills wrote:

> However, my explanation regarding what happens in the dictionary (or
> rather, what the memory looks like after compilation) is correct:
> 
> CREATE FRED : TEST 1 2 3 ;
> FRED @ $.
>>> A2EA ok:0
> ' TEST >LINK @ $.
>>> A2EA ok:0
> 
> So... What's that 0xA2EA value in FRED? When we do FRED @ we get A2EA.
> Where did that come from? It's the value stored in the *back pointer
> field* of *dictionary entry* of *TEST*! In other words, TESTs back
> pointer points to A2EA, which is the beginning of FREDs dictionary
> entry!
> 
> So, when you do CREATE FRED memory looks like this:
> 
> -----+---------+---+
> FRED | DO_PUSH | *-----HERE -----+---------+---+
> 
> So, HERE is currently pointing at the BODY of FRED (effectively waiting
> for a value to be comma'd in).
> 
> However, we don't comma in a value. We begin a new definition:
> 
> : TEST 1 2 3 ;
> 
> Which gives us (ITC)
> 
> ------+---------+------+-------+-----+---+-----+---+-----+---+------+
>  FRED | DO_PUSH | TEST | DOCOL | LIT | 1 | LIT | 2 | LIT | 3 | EXIT |
> ------+---------+------+-------+-----+---+-----+---+-----+---+------+
>    ^               |
>    +---------------+
> 
> The beginning of the definition of TEST (which in my case is the back
> pointer to the previous definition (FRED)) lies in the BODY of FRED.
> 
> Such that FRED @ reveals the value in the back-pointer field of TEST -
> as evidenced by:
> 
> ' TEST >LINK @ $.
> A2EA ok:0
> 
> Confusing, huh!? But it is correct.

Thanks again Mark. That was a very clear explanation.

Cheers,
Arnold

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

#9255

From"Elizabeth D. Rather" <erather@forth.com>
Date2012-01-27 08:06 -1000
Message-ID<pridne-LyLcrer_SnZ2dnUVZ_sSdnZ2d@supernews.com>
In reply to#9252
On 1/27/12 5:30 AM, Arnold Doray wrote:
> On Fri, 27 Jan 2012 02:29:42 -0800, Mark Wills wrote:
>
>> However, my explanation regarding what happens in the dictionary (or
>> rather, what the memory looks like after compilation) is correct:
>>
>> CREATE FRED : TEST 1 2 3 ;
>> FRED @ $.
>>>> A2EA ok:0
>> ' TEST>LINK @ $.
>>>> A2EA ok:0
>>
>> So... What's that 0xA2EA value in FRED? When we do FRED @ we get A2EA.
>> Where did that come from? It's the value stored in the *back pointer
>> field* of *dictionary entry* of *TEST*! In other words, TESTs back
>> pointer points to A2EA, which is the beginning of FREDs dictionary
>> entry!
>>
>> So, when you do CREATE FRED memory looks like this:
>>
>> -----+---------+---+
>> FRED | DO_PUSH | *-----HERE -----+---------+---+
>>
>> So, HERE is currently pointing at the BODY of FRED (effectively waiting
>> for a value to be comma'd in).
>>
>> However, we don't comma in a value. We begin a new definition:
>>
>> : TEST 1 2 3 ;
>>
>> Which gives us (ITC)
>>
>> ------+---------+------+-------+-----+---+-----+---+-----+---+------+
>>   FRED | DO_PUSH | TEST | DOCOL | LIT | 1 | LIT | 2 | LIT | 3 | EXIT |
>> ------+---------+------+-------+-----+---+-----+---+-----+---+------+
>>     ^               |
>>     +---------------+
>>
>> The beginning of the definition of TEST (which in my case is the back
>> pointer to the previous definition (FRED)) lies in the BODY of FRED.
>>
>> Such that FRED @ reveals the value in the back-pointer field of TEST -
>> as evidenced by:
>>
>> ' TEST>LINK @ $.
>> A2EA ok:0
>>
>> Confusing, huh!? But it is correct.
>
> Thanks again Mark. That was a very clear explanation.
>
> Cheers,
> Arnold

Yes, but I'm surprised that it was necessary. What part of "CREATE 
doesn't allocate any data space" is hard to understand?

Mark's example is typical of integrated dictionary/data space 
implementations, although exactly what would be found at the first 
location of a colon definition will vary. In an implementation in which 
data space is segregated, it might just be whatever is left over in an 
otherwise unused cell, or one used for some prior purpose.

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]

#9257

From"Rod Pemberton" <do_not_have@noavailemail.cmm>
Date2012-01-27 20:21 -0500
Message-ID<jfvim7$hsl$1@speranza.aioe.org>
In reply to#9227
"Mark Wills" <markrobertwills@yahoo.co.uk> wrote in message
news:692e810d-4789-456d-8b63-829cd518232c@do4g2000vbb.googlegroups.com...
...

> So, it seems, with bigForth, that it's using HERE for something,

Yes.

> and it's tripping you up,

No.

> because you didn't compile a value into the body
> of the word you created

True.

The space is not allocated from Forth's perspective.  It's present though.
So, it was allocated for use, just not in the Forth sense.  From Forth's
perspective, it still could be allocated at a later time though, e.g.,
ALLOT.

Whether one should or shouldn't use space that is not allocated from Forth's
perspective is apparently open to debate.  I've not noticed anything in the
spec's on it, although I haven't fully read them ...

> as was expected.

uh ...


fig-Forth copies parsing data to HERE.  It's part of WORD.That should
overwrite what's at HERE when unallocated.  I couldn't get the test to work
on actual fig-Forths.  CREATE <name> was accepted, but the CREATE-ed word
couldn't be found ...  I based my parsing on fig-Forth code.  It seems
bigForth is doing the same.

FYI, it turns out it's an easy fix.

Instead of copying every word parsed by ENCLOSE via CMOVE to HERE, you leave
the parsed words in your parsing buffer which is TIB in my case.  The code
only copies the name to the name field when CREATE is executed, instead of
copying the parsed token every time WORD is executed.  I had to change
FIND and CREATE and WORD  You probably won't need to change FIND.

Fixing "the issue" has a few advantages too.

Copying every parsed word in the input stream to HERE slowed down my
interpreter.  bigForth seems so slow ...  Now, it only copies when CREATE
creates a name field.  Copying the parsed stream to HERE also implies the
name field is at the start of the dictionary.  I.e., an additional copy is
needed if the name field isn't at the start and you are copying all parsed
to HERE.  When not copying all parsed data to HERE, you still need a copy
but you eliminate the unecessary copies to HERE.

> Did you try the code I posted earlier?
>

No, I didn't.  I will since you brought it up again.

> CREATE FRED
> : TEST 1 2 3 ;
> FRED
> error: FRED not found

There's no error on mine ...  At the moment, it passively does nothing for
unfound words.  That's on the TO DO list.  I have to ' TICK <name> DUMP to
see if the word is correctly built.  DUMP is customized C code which
displays the dictionary header and a fixed bunch of cells, e.g., first
portion of the body or PF area, as hex.

But, from what you said in the other posts, I think you may have meant TEST.
You were probably thinking of something like this:

CREATE FRED
: TEST 1 2 3 ;
4 FRED !
TEST

The store to FRED should've overwritten the first part of the dictionary
structure for TEST.  If your name field is first, the name field will be
corrupted, i.e., it shouldn't find TEST.  The now fixed version of my
interpreter "blows up" since the link field is first.

> This is because, what gets compiled, is this:
>
>                      BODY
> -----+---------+----+------+-------+-----+---+-----+---+------+
> FRED | DO_PUSH | 0* | TEST | LIT 1 | LIT | 2 | LIT | 3 | EXIT |
> -----+---------+----+------+-------+-----+---+-----+---+------+
>   ^--------------------+
>
> So, the *body* of FRED actually has a part of the definition
> of TEST in it.

My interpreter does the following.  I recently removed DOVAR  That's been
replaced with an ENTER VAR sequence for now.  I've not fixed my DOES> with
an additional field in the header yet either ...  FRED returns the address
of TEST.

                BODY
-----+---------+-----+------+-------+-----+---+-----+---+------+
FRED | ENTER   | VAR | TEST | LIT 1 | LIT | 2 | LIT | 3 | EXIT |
-----+---------+-----+------+-------+-----+---+-----+---+------+
   ^--------------------+

> [snip]
>
> Does that make sense?

Yes.

I don't have an issue understanding what is happening.  I found and brought
up the issue.

> * The zero is normally compiled just in case a CREATEd word is
> subsequently modified by DOES> - it reserves space for an address if
> required. If a CREATEd word is modified by DOES> then the DO_PUSH
> (which just pushes the address of the body of the created word) is
> replace with DO_DOES and the 0 in front of it is replaced with the
> address of the code just after DOES> in the parent word.

It's on the TO DO list ...  I have to make sure it doesn't break my
structure addressing words.


Rod Pemberton

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

#9258

From"Elizabeth D. Rather" <erather@forth.com>
Date2012-01-27 16:19 -1000
Message-ID<_eCdnZLZSrOuxr7SnZ2dnUVZ_qOdnZ2d@supernews.com>
In reply to#9257
On 1/27/12 3:21 PM, Rod Pemberton wrote:
> "Mark Wills"<markrobertwills@yahoo.co.uk>  wrote in message
> news:692e810d-4789-456d-8b63-829cd518232c@do4g2000vbb.googlegroups.com...
> ...
>
>> So, it seems, with bigForth, that it's using HERE for something,
>
> Yes.
>
>> and it's tripping you up,
>
> No.
>
>> because you didn't compile a value into the body
>> of the word you created
>
> True.
>
> The space is not allocated from Forth's perspective.  It's present though.
> So, it was allocated for use, just not in the Forth sense.  From Forth's
> perspective, it still could be allocated at a later time though, e.g.,
> ALLOT.

If you're programming in Forth, "the Forth sense" is all that matters, IMO.

> Whether one should or shouldn't use space that is not allocated from Forth's
> perspective is apparently open to debate.  I've not noticed anything in the
> spec's on it, although I haven't fully read them ...

I am baffled as to how you think you're entitled to use space that 
hasn't been explicitly allocated. The definition of CREATE contains a 
notice to the effect that it has not allocated any space. You must do 
so. If you have done one of the things that allocates data space (ALLOT, 
, C, etc.) then that space is yours. Otherwise, it is the system's 
space, to use at it sees fit.

All implementations are different in terms of how they use data space, 
so you can get no portable behavior without allocating data space before 
using it. People in this thread have noted different system approaches 
to using scratch space, but I haven't seen anyone claim that you have 
any *entitlement* to expect unallocated space to be preserved, so I do 
not think that is "open to debate".

>> as was expected.
>
> uh ...

Exactly!

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]

#9263

From"Rod Pemberton" <do_not_have@noavailemail.cmm>
Date2012-01-28 14:18 -0500
Message-ID<jg1hpt$15e$1@speranza.aioe.org>
In reply to#9258
"Elizabeth D. Rather" <erather@forth.com> wrote in message
news:_eCdnZLZSrOuxr7SnZ2dnUVZ_qOdnZ2d@supernews.com...
> On 1/27/12 3:21 PM, Rod Pemberton wrote:
...

> > Whether one should or shouldn't use space that is not allocated from
> > Forth's perspective is apparently open to debate.  I've not noticed
> > anything in the spec's on it, although I haven't fully read them ...
>
> I am baffled as to how you think you're entitled to use space that
> hasn't been explicitly allocated.
>

I'm not about to use space that isn't allocated (from Forth's perspective).
However, AISI, it's not a matter of entitlement.  It's an issue of user
expectation.  A user, i.e., a novice programmer, expects Forth words to do
only what they've been told that the Forth words do.  They don't expect
anything more or anything less.  They don't expect side effects, undefined
behavior, or expect to be required to have an inside knowledge of what is
happening in the Forth parser and compiler.  If storing and allocation are
separate, why would the user expect that the order in which they occur is
important?  When a value is stored into the dictionary via , COMMA the user
expects that the value is allocated too.  They don't expect that a COMMA'd
value could be overwritten.  So, when a value is ! STOREd into a variable,
why would a user *expect* that the variable's value could be overwritten?
Wasn't the variable created already?  Wasn't space allocated for the
variable when it was created?  If no space was allocated for the variable
when it was created, what was the point of creating the variable?  Forth is
contrary to *all* other programming languages.  Name one other language
where a variable is created but has no space allocated for it by default.
Some languages do provide that ability as a feature, but don't do so by
default.  It's only if the user has inside knowledge or understands there is
a side effect to using CREATE that the user would have the expectation
that an ALLOT is required.  In essence, there is a hidden constraint placed
upon when or where or how VARIABLE can legally be used with CREATE.


Rod Pemberton

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

#9264

FromAlex McDonald <blog@rivadpm.com>
Date2012-01-28 12:30 -0800
Message-ID<1d23d681-8965-49ce-8b08-f773af0e85a6@j42g2000vbt.googlegroups.com>
In reply to#9263
On Jan 28, 11:18 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Elizabeth D. Rather" <erat...@forth.com> wrote in messagenews:_eCdnZLZSrOuxr7SnZ2dnUVZ_qOdnZ2d@supernews.com...> On 1/27/12 3:21 PM, Rod Pemberton wrote:
>
> ...
>
> > > Whether one should or shouldn't use space that is not allocated from
> > > Forth's perspective is apparently open to debate.  I've not noticed
> > > anything in the spec's on it, although I haven't fully read them ...
>
> > I am baffled as to how you think you're entitled to use space that
> > hasn't been explicitly allocated.
>
> I'm not about to use space that isn't allocated (from Forth's perspective).
> However, AISI, it's not a matter of entitlement.  It's an issue of user
> expectation.  A user, i.e., a novice programmer, expects Forth words to do
> only what they've been told that the Forth words do.  They don't expect
> anything more or anything less.  They don't expect side effects, undefined
> behavior, or expect to be required to have an inside knowledge of what is
> happening in the Forth parser and compiler.  If storing and allocation are
> separate, why would the user expect that the order in which they occur is
> important?  When a value is stored into the dictionary via , COMMA the user
> expects that the value is allocated too.  They don't expect that a COMMA'd
> value could be overwritten.  So, when a value is ! STOREd into a variable,
> why would a user *expect* that the variable's value could be overwritten?

Because CREATE isn't a variable, that's why.

> Wasn't the variable created already?  Wasn't space allocated for the
> variable when it was created?  If no space was allocated for the variable
> when it was created, what was the point of creating the variable?  Forth is
> contrary to *all* other programming languages.  Name one other language
> where a variable is created but has no space allocated for it by default.

CREATE doesn't create a variable; it creates a name that references
the address at HERE. If you want a variable then say so with VARIABLE.
In C, you might look at struct, and other language also support record
types. Forth's CREATE is no different in that respect.

> Some languages do provide that ability as a feature, but don't do so by
> default.  It's only if the user has inside knowledge or understands there is
> a side effect to using CREATE that the user would have the expectation
> that an ALLOT is required.  In essence, there is a hidden constraint placed
> upon when or where or how VARIABLE can legally be used with CREATE.

The last sentence doesn't make sense.

>
> Rod Pemberton

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

#9265

FromMark Wills <markrobertwills@yahoo.co.uk>
Date2012-01-28 13:42 -0800
Message-ID<57ec0fe0-2873-447f-b94f-2d82e6f14e92@j14g2000vba.googlegroups.com>
In reply to#9263
On Jan 28, 7:18 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Elizabeth D. Rather" <erat...@forth.com> wrote in messagenews:_eCdnZLZSrOuxr7SnZ2dnUVZ_qOdnZ2d@supernews.com...> On 1/27/12 3:21 PM, Rod Pemberton wrote:
>
> ...
>
> > > Whether one should or shouldn't use space that is not allocated from
> > > Forth's perspective is apparently open to debate.  I've not noticed
> > > anything in the spec's on it, although I haven't fully read them ...
>
> > I am baffled as to how you think you're entitled to use space that
> > hasn't been explicitly allocated.
>
> I'm not about to use space that isn't allocated (from Forth's perspective).
> However, AISI, it's not a matter of entitlement.  It's an issue of user
> expectation.  A user, i.e., a novice programmer, expects Forth words to do
> only what they've been told that the Forth words do.  They don't expect
> anything more or anything less.  They don't expect side effects, undefined
> behavior, or expect to be required to have an inside knowledge of what is
> happening in the Forth parser and compiler.  If storing and allocation are
> separate, why would the user expect that the order in which they occur is
> important?  When a value is stored into the dictionary via , COMMA the user
> expects that the value is allocated too.  They don't expect that a COMMA'd
> value could be overwritten.  So, when a value is ! STOREd into a variable,
> why would a user *expect* that the variable's value could be overwritten?
> Wasn't the variable created already?  Wasn't space allocated for the
> variable when it was created?  If no space was allocated for the variable
> when it was created, what was the point of creating the variable?  Forth is
> contrary to *all* other programming languages.  Name one other language
> where a variable is created but has no space allocated for it by default.
> Some languages do provide that ability as a feature, but don't do so by
> default.  It's only if the user has inside knowledge or understands there is
> a side effect to using CREATE that the user would have the expectation
> that an ALLOT is required.  In essence, there is a hidden constraint placed
> upon when or where or how VARIABLE can legally be used with CREATE.
>
> Rod Pemberton

CREATE doesn't ALLOT space. VARIABLE does.

: VARIABLE  CREATE 0 , ; IMMEDIATE

Mark

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

#9271

FromBrad <hwfwguy@gmail.com>
Date2012-01-28 17:37 -0800
Message-ID<83822332-16af-45eb-96dd-c91cf431ed4f@p12g2000yqe.googlegroups.com>
In reply to#9265
On Jan 28, 2:42 pm, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> CREATE doesn't ALLOT space. VARIABLE does.
>
> : VARIABLE  CREATE 0 , ; IMMEDIATE
>
VARIABLE is not IMMEDIATE.

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web