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

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

dot-quote implementation question

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

Contents

  dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-10 05:28 -0500
    Re: dot-quote implementation question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-10 12:00 +0000
      Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-10 06:52 -0800
      Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-10 21:10 -0500
        Re: dot-quote implementation question "A. K." <akk@nospam.org> - 2011-12-11 08:59 +0100
        Re: dot-quote implementation question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-11 03:40 -0600
          Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-12 05:04 -0500
            Re: dot-quote implementation question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-12 04:56 -0600
              Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-13 10:08 -0500
            Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-12 07:42 -0800
              Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-13 09:47 -0500
                Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-17 04:57 -0500
                  Re: dot-quote implementation question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-17 04:20 -0600
                    Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-18 07:18 -0500
                      Re: dot-quote implementation question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-18 06:30 -0600
                        Re: dot-quote implementation question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-20 03:04 -0600
                Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-17 08:15 -0800
                  Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-18 07:53 -0500
                    Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-18 09:14 -0800
                      Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-19 05:24 -0500
                        Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-19 09:11 -0800
                          Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-19 10:53 -0800
                        Re: dot-quote implementation question "Elizabeth D. Rather" <erather@forth.com> - 2011-12-19 08:38 -1000
                          Re: dot-quote implementation question "A. K." <akk@nospam.org> - 2011-12-19 21:34 +0100
                            Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-19 12:51 -0800
                    Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-18 10:16 -0800
                    Re: dot-quote implementation question "Elizabeth D. Rather" <erather@forth.com> - 2011-12-18 08:18 -1000
                      Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-19 05:25 -0500
                        Re: dot-quote implementation question Coos Haak <chforth@hccnet.nl> - 2011-12-19 22:23 +0100
                          Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-20 10:53 -0500
                            Re: dot-quote implementation question Coos Haak <chforth@hccnet.nl> - 2011-12-20 19:58 +0100
                              Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-20 11:44 -0800
                              Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-21 16:16 -0500
                            Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-20 11:50 -0800
                              Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-21 14:56 -0500
                        Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-21 21:49 -0500
                    Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-18 14:33 -0800
                      Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-19 05:26 -0500
                        Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-19 09:38 -0800
                          Re: dot-quote implementation question "Elizabeth D. Rather" <erather@forth.com> - 2011-12-19 08:49 -1000
                            Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-19 13:04 -0800
                              Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-20 10:57 -0500
                                Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-20 12:23 -0800
                                  Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-20 14:27 -0800
                                  Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-21 16:14 -0500
                                    Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-21 14:53 -0800
                                      Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-21 21:48 -0500
                                        Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-21 22:02 -0800
                                          Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-29 03:39 -0500
                                            Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-29 12:37 -0800
                                              Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-30 13:31 -0500
                                                Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-30 11:12 -0800
                                                  Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-31 05:52 -0500
                                                    Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-31 11:33 -0800
                                                      Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-31 20:10 -0500
                                                        Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-31 19:12 -0800
                                                  Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-04 05:13 -0500
                                                    Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2012-01-04 12:49 -0800
                                    Re: dot-quote implementation question Coos Haak <chforth@hccnet.nl> - 2011-12-22 00:55 +0100
                                Re: dot-quote implementation question Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-12-20 21:43 +0000
                            Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-19 13:25 -0800
                              Re: dot-quote implementation question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-20 03:00 -0600
                                Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-20 04:40 -0800
                                Re: dot-quote implementation question Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-12-20 21:55 +0000
                                  Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-20 14:33 -0800
                                    Re: dot-quote implementation question Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-12-22 20:33 +0000
                                      Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-22 13:32 -0800
                                  Re: dot-quote implementation question Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-21 03:01 -0600
                                    Re: dot-quote implementation question Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-12-22 20:38 +0000
                              Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-20 10:53 -0500
                          Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-20 10:49 -0500
                            Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-20 08:20 -0800
                        Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-20 04:49 -0800
                          Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-20 10:58 -0500
                            Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-21 08:41 -0800
                              Re: dot-quote implementation question "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-21 16:14 -0500
                                Re: dot-quote implementation question BruceMcF <agila61@netscape.net> - 2011-12-21 15:14 -0800
        Strings (was: dot-quote implementation question) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-11 10:33 +0000
          Re: Strings (was: dot-quote implementation question) kenney@cix.compulink.co.uk - 2011-12-12 02:53 -0600

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

#8227

On Dec 19, 1:49 pm, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> On 12/19/11 7:38 AM, BruceMcF wrote:
>
>
>
>
>
> > On Dec 19, 5:26 am, "Rod Pemberton"<do_not_h...@noavailemail.cmm>
> > wrote:
>
> >>>> The sequence "LAST @ CFA !" stores DODOES into the CFA
> >>>> overwriting a DOVAR put there via CREATE. The sequence "R>  ,"
> >>>> stores the address of the after-DOES>  code in the PFA.
>
> > Its been over a quarter century since I last used these archaic terms.
> > Remind me what PFA is an abbreviation for? That's where the xt's go in
> > the compiled Forth definitions, right?

> > CFA:
> >     Address-of-routine-to-perform-following
> > PFA:
> >     Address-of-word1
> >     Address-of-word2
> >     ...

> Well, to be absolutely correct, PFA="Parameter Field *Address*" which
> means the address *of* the parameter field of the word being referenced.
> That is what you store in the parameter field of a word being compiled
> in an ITC implementation, for example. The *parameter field* is where
> the payload of a definition goes.

In the above, in assembler style, CFA and PFA as labels are the
addresses themselves, not variables containing those addresses. Maybe
"ActualCFA:" and "ActualPFA:"

> Similarly, CFA="Code Field Address" and is the address *of* the part of
> a definition that contains a pointer to the code to be executed, that
> is, the *code field*.

I recalled CFA, and thought I'd recalled PFA, but I've seen enough
different implementation styles and header structure since I last
looked at an ITC to be unsure.

I think that for Rod's, DOCREATE should be the equivalent of:
   R> CELL+ EXIT

and DODOES should be the equivalent of:
   R> DUP @ >R CELL+ EXIT

... to avoid stepping on the address of target DOES> segment.

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

#8250

"BruceMcF" <agila61@netscape.net> wrote in message
news:5148d2e6-54e0-4168-94f5-fcc634bcba4a@i6g2000vbe.googlegroups.com...
> I think that for Rod's, DOCREATE should be the equivalent of:
>   R> CELL+ EXIT

Hmm, I don't have a DOCREATE.  Merits of DOCREATE are?

My CREATE COMPILEs a DOVAR currently.

> and DODOES should be the equivalent of:
>    R> DUP @ >R CELL+ EXIT

I'm not quite sure of the exact C to Forth for my DODOES primitive.  But, I
think it would be equivalent to (untested):

R> DUP CELL+ @ >R EXIT


Rod Pemberton

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

#8259

On Dec 20, 10:57 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "BruceMcF" <agil...@netscape.net> wrote in message
> news:5148d2e6-54e0-4168-94f5-fcc634bcba4a@i6g2000vbe.googlegroups.com...

> > I think that for Rod's, DOCREATE should be the equivalent of:
> >   R> CELL+ EXIT

> Hmm, I don't have a DOCREATE.  Merits of DOCREATE are?

You are defining variables and constants in your ASCII file, so you
don't need to have DOVAR or DOCON ...

: VARIABLE CREATE 0 , ;
: 2VARIABLE CREATE 0 , 0 , ;
: CONSTANT , DOES> @ ;
: 2CONSTANT , , DOES> 2@ ;

You can have CREATE build a new entry as:

CFA:    DODOES
PF:     DOES_CREATE

Where:
DOES_CREATE:
        EXIT

So the minimum set of C-routines you need for function pointers to
store in CFA's are DOCOL and DODOES.

Adding DOCREATE makes everything defined with CREATE that does *not*
take a DOES> quicker (including variables), since it ignores the first
PF field, pushes a value two integers past the CFA that it was located
in on the stack, and performs a NEXT, so it avoids the ENTER that is
done as a consequence of DOCOL and DODOES.

> My CREATE COMPILEs a DOVAR currently.

Why would you have a routine called DOVAR if you define VARIABLE in
the ASCII file?

> > and DODOES should be the equivalent of:
> >    R> DUP @ >R CELL+ EXIT
>
> I'm not quite sure of the exact C to Forth for my DODOES primitive.  But, I
> think it would be equivalent to (untested):
>
> R> DUP CELL+ @ >R EXIT

Is the return stack value pointing to the CFA or to the first address
of the parameter field?

Its got to be the latter, since otherwise you'd trample the CFA when
you use a variable, and blow things up.

But that means that:

CFA:    DODOES
PF:     x1 ; leave address of PF on stack
        x2 ; fetch this value and >R to execute DOES> segment

Then it would seem to mean that you'd be passing simple tests because
you are trampling *after* the simple test ~ possibly in space at HERE,
it you test the CREATEd word right away.

So create a 2-cell variable, execute DOES> on it, store to it, then
execute it again and see if it works.

: 2VARIABLE CREATE 0 , 0 , DOES> ;
2VARIABLE A
TRUE TRUE A 2!
A 2@ . .

If your C-code does what you say it does, the results could be
interesting.

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

#8265

On Dec 20, 3:23 pm, BruceMcF <agil...@netscape.net> wrote:
> On Dec 20, 10:57 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
>
> > "BruceMcF" <agil...@netscape.net> wrote in message
> >news:5148d2e6-54e0-4168-94f5-fcc634bcba4a@i6g2000vbe.googlegroups.com...
> > > I think that for Rod's, DOCREATE should be the equivalent of:
> > >   R> CELL+ EXIT
> > Hmm, I don't have a DOCREATE.  Merits of DOCREATE are?
>
> You are defining variables and constants in your ASCII file, so you
> don't need to have DOVAR or DOCON ...
>
> : VARIABLE CREATE 0 , ;
> : 2VARIABLE CREATE 0 , 0 , ;
> : CONSTANT , DOES> @ ;
> : 2CONSTANT , , DOES> 2@ ;
>
> You can have CREATE build a new entry as:
>
> CFA:    DODOES
> PF:     DOES_CREATE
>
> Where:
> DOES_CREATE:
>         EXIT
>
> So the minimum set of C-routines you need for function pointers to
> store in CFA's are DOCOL and DODOES.
... that is, over and above your actual primitives, which would be:

CFA:    pointer to C function of primitive

Your Forth primitives and DOCREATE and DOCOLON and you'd be set.

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

#8291

"BruceMcF" <agila61@netscape.net> wrote in message
news:325142d5-d312-4e7f-bc03-1ab41fc2dc48@o9g2000yqa.googlegroups.com...
> On Dec 20, 10:57 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
> > "BruceMcF" <agil...@netscape.net> wrote in message
> > news:5148d2e6-54e0-4168-94f5-fcc634bcba4a@i6g2000vbe.googlegroups.com...
...

> > My CREATE COMPILEs a DOVAR currently.
> >
> Why would you have a routine called DOVAR if you define
> VARIABLE in the ASCII file?

CREATE compiles something into the CFA ...

IIRC, descriptions of Forth that use the definitions for CONSTANT and
VARIABLE that I'm using and you posted, compile DODOES and DOVAR.  I don't
recall where those definitions came from.  They seem to be very prevalent.
Are those eForth definitions?  IIRC, fig-Forth compiled DOCON and DOVAR.  I
have some notes which say:

 CREATE compiles DOVAR (or ENTER DOVAR)
 VARIABLE compiles DOVAR (or ENTER DOVAR)
 CONSTANT compiles DODOES (or ENTER DODOES)
 LITERAL compiles DOLIT (or ENTER DOLIT)

> Is the return stack value pointing to the CFA or to the
> first address of the parameter field?

Uh ...

> Its got to be the latter, since otherwise you'd trample the CFA
> when you use a variable, and blow things up.
>
> But that means that:
>
> CFA:    DODOES
> PF:     x1 ; leave address of PF on stack
>         x2 ; fetch this value and >R to execute DOES> segment

Yeah, not sure ...

I have to get back to you on those.

> Then it would seem to mean that you'd be passing simple tests
> because you are trampling *after* the simple test ~ possibly in
> space at HERE, it you test the CREATEd word right away.
>
> So create a 2-cell variable, execute DOES> on it, store to it,
> then execute it again and see if it works.
>
> : 2VARIABLE CREATE 0 , 0 , DOES> ;
> 2VARIABLE A
> TRUE TRUE A 2!
> A 2@ . .
>
> If your C-code does what you say it does, the results could
> be interesting.
>

I don't have the 2X words.  It crashes if I rewrite to double operations
using normal @ and !, e.g., TRUE A ! TRUE A CELL+ ! .   It seems that this a
problem.  I can dump my definitions, but it's all in hex.  Currently, I've
got an address I can't identify as to which Forth word it belongs ...  I
guess I'm going to have to add name resolution to my dump before I can track
down what is going on.

If I change the two zero's to 5 and 6, it compiles 5 and 6 int PF x1 and x2
respectively.  PF x3 is an address in 2VAR.  The value at that addres does
not match valid address for DOES> or DODOES or anything related like EXIT
...  I think it's broken, or not fully functional.  I.e., at a minimum it is
shifting the address that points into 2VAR and I think the primitive gets
from PF x1 only.


Rod Pemberton

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

#8297

On Dec 21, 4:14 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

> CREATE compiles something into the CFA ...

It would be called DOCREA in the fig-Forth approach, if you don't have
a DOVAR because you finish compiling the system out of your ASCII
file.

> IIRC, descriptions of Forth that use the definitions for CONSTANT and
> VARIABLE that I'm using and you posted, compile DODOES and DOVAR.

They'd be either/or ~ if you define CONSTANT and VARIABLE with CREATE
and DOES> then DOCON and DOVAR are redundant, if you don't then you
need DOCON and DOVAR ~ sometimes DOCREA is the same as DOVAR and then
one of the two is redundant, sometimes its not.

> Are those eForth definitions?

They are long standing definitions. Heck, if you know the system in
detail and especially if you have a system monitor, you can bootstrap
from a working interpreter and with CREATE , and C, in the dictionary
and nothing else.

>  IIRC, fig-Forth compiled DOCON and DOVAR.

Yes.

>  CREATE compiles DOVAR (or ENTER DOVAR)
>  VARIABLE compiles DOVAR (or ENTER DOVAR)
>  CONSTANT compiles DODOES (or ENTER DODOES)
>  LITERAL compiles DOLIT (or ENTER DOLIT)

When the contents at the code field address are the same for CREATE
and
VARIABLE then whether you call it DOVAR or DOCREATE is arbitrary,
isn't it?

But given that you need to have two cells in your CREATEd structure so
it can work after DOES> has done it's magic, I'd suggest that you need
a DOCREATE and then can decide whether to have the compiled kernel one
routine longer and include a DOVAR:
   : VARIABLE HEADER 'DOVAR , 0 , ;

... and save space in all of your variables. But save that until after
CREATE DOES> works.

> If I change the two zero's to 5 and 6, it compiles 5 and 6 int PF x1
> and x2 respectively.  PF x3 is an address in 2VAR.  The value at that
> addres does not match valid address for DOES> or DODOES or anything
> related like EXIT ...  I think it's broken, or not fully functional.

I'd go House and say an attempted treatment could be the quickest
diagnosis tool. Change CREATE so that it pads an empty cell before
returns, and change DOES> so that it puts DODOES at the CFA and the
address of the target segment at the address following. It it fixes
the problem, your prior does was trashing the dictionary, just doing
it where it did not show up in the single cell test.

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

#8301

"BruceMcF" <agila61@netscape.net> wrote in message
news:b745bccd-d5c7-4f0d-823c-e4cb9a74adfc@p41g2000yqm.googlegroups.com...
> On Dec 21, 4:14 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
>
> > If I change the two zero's to 5 and 6, it compiles 5 and 6 int PF x1
> > and x2 respectively. PF x3 is an address in 2VAR. The value at that
> > addres does not match valid address for DOES> or DODOES or anything
> > related like EXIT ... I think it's broken, or not fully functional.
>
> I'd go House and say an attempted treatment could be the quickest
> diagnosis tool. Change CREATE so that it pads an empty cell before
> returns, and change DOES> so that it puts DODOES at the CFA and the
> address of the target segment at the address following. It it fixes
> the problem, your prior does was trashing the dictionary, just doing
> it where it did not show up in the single cell test.
>

I've basically confirmed that address pointing to the DOES> code is expected
in the 2nd  PF by my DODOES CFA primitive, but it is only written in that
location if there is exactly one , COMMA between CREATE ... DOES> .  One
comma is what is needed to make the version of CONSTANT I'm using work.
That address is placed in a different PF locations depending on the number
of , COMMAs.  Zero in 1st, one in 2nd, two in 3rd ...  I.e., gets placed at
DP or HERE which is affecte by the , COMMAs, but is read from a fixed
position.

So, it seems that having the extra PFA field or cell padding is needed to
provide a place where that address can be stored where won't shift around.
That's something I'd rather not do.  It seems wasteful.  I'll think about
other solutions maybe next year ...


Rod Pemberton

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

#8303

On Dec 21, 9:48 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "BruceMcF" <agil...@netscape.net> wrote in message
...
>> Change CREATE so that it pads an empty cell before
>> returns, and change DOES> so that it puts DODOES at the CFA

> I've basically confirmed that address pointing to the DOES> code is expected
> in the 2nd  PF by my DODOES CFA primitive, but it is only written in that
> location if there is exactly one , COMMA between CREATE ... DOES> .

 One
> comma is what is needed to make the version of CONSTANT I'm using work.
> That address is placed in a different PF locations depending on the
> number of , COMMAs. ?..

Ah, yes, to make one consumer of it work, you stopped DOES> trampling
at the head of the program field, at the cost of storing it relative
to HERE when DOES> executes ... whiech there is no general way to let
DODEAS where the address is located, because there'd be no placefor
the offset to be stored.

> So, it seems that having the extra PFA field or cell padding is needed to
> provide a place where that address can be stored where won't shift
> around.

> That's something I'd rather not do.  It seems wasteful.  I'll think about
> other solutions maybe next year ...

The waste is when CREATE is used without DOES> ... and the solution to
that is to tokenize the C-function pointer in the cfa so if its an
address, the does action can be implied.

If that waste bothers you, then DO use an actual DOVAR and DOCON, and
use a lower level common factor than CREATE. Say,
   HEADER ( "name" -- )

: VARIABLE ( "name" -- ) HEADER 'DOVAR , 0 , ;
: CONSTANT ( x "name" -- ) HEADER 'DOCON , , ;
: CREATE ( "name" -- ) HEADER 'DOCREATE , 0 , ;

But allowing a word that has been made with CREATE to inherit a new
behavior with DOES> is no waste, and as you note, you cannot embed a
piece of a c-routine at the head of the does segment to do it there.
Space required to provide desired functionality is not wasted space.

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

#8417

"BruceMcF" <agila61@netscape.net> wrote in message
news:f4e32f99-7fc0-4839-9336-09c970930129@f33g2000yqh.googlegroups.com...
On Dec 21, 9:48 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "BruceMcF" <agil...@netscape.net> wrote in message
...
> >> Change CREATE so that it pads an empty cell before
> >> returns, and change DOES> so that it puts DODOES at the CFA

> > So, it seems that having the extra PFA field or cell padding is needed
> > to provide a place where that address can be stored where won't
> > shift around.

> > That's something I'd rather not do. It seems wasteful. I'll think about
> > other solutions maybe next year ...

> The waste is when CREATE is used without DOES> ... and the solution to
> that is [...]

... perhaps to use an eForth compatible DOES> ?

eForth uses definitions similar to those I'm using for CONSTANT and
VARIABLE.  I'm not quite sure, but it seems that eForth doesn't overwrite
the CFA with DODOES.  I think doing that may be the source of my problems.
Instead, I think eForth leaves the CFA as DOVAR, compiles DODOES inline into
a defintion, and follows that by the DOES> address.  I think DODOES in
eForth is implemented like a LIT value, except that the value gets jumped to
instead of stacked.

Currently, my DOES> is this:

: DOES> R> , LIT DODOES LAST @ CFA ! ;

It compiles the DOES> address into the PF region - in no specific location -
and compiles DODOES into the CFA.  So, the DODOES in the CFA doesn't know
where to find the DOES> address.  DODOES gets an address immediately
following the DODOES location, which in this case is one location past the
CFA, or always the 1st PF.

For my DOES> to be compatible with the CONSTANT and VARIABLE definitions, I
think my DOES> should something like this:

: DOES> COMPILE DODOES R> , ;

DODOES here is like LIT, but instead of placing the next value compiled into
the word onto the stack, the next value gets jumped to.  This compiles
DODOES inline into the definition followed by the DOES> address.  The CFA
remains set to DOVAR.  So, when DODOES is executed, it fetches the following
inlined data, which is the DOES> address, and jumps to it.  I think that
should work.  Since DODOES is inline, it always knows the address is
immediately afterwards.  That implies my DODOES definition/implementation is
correct for this DOES> definition.  Implementing DOES> this way should also
allow multiple DOES> 's per definition, although what use that'd be or it's
legality is unknown by me.  I may have to change DOVAR to allow execution to
continue with the remaining compiled words in a definition.  That change
should allow VARIABLE and/or CONSTANT work.  Implementing DOES> this way,
perhaps the eForth way, should eliminate the need for a mandatory PFA field
or padding.  I've not tested this.

FYI, my primitive or low-level DODOES is effectively:

: DODOES R> DUP CELL+ @ >R ;

My high-level DODOES is coded as that.  I've never used the high-level
version, so it's commented out.


Rod Pemberton

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

#8440

On Dec 29, 3:39 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> eForth uses definitions similar to those I'm using for CONSTANT and
> VARIABLE.  I'm not quite sure, but it seems that eForth doesn't
> overwrite the CFA with DODOES.  I think doing that may be the source
> of my problems.

> Instead, I think eForth leaves the CFA as DOVAR, compiles DODOES
> inline into a defintion, and follows that by the DOES> address.

Which eForth, v1 or v2?

No, it does not leave the CFA as DOVAR, instead it changes the CFA as
the location of DODOES at the head of the does segment. Yes, it does
compile DODOES inline at the head of the does segment.

As you've noted, your CFA is not a real code field, its a C-function-
pointer-field, "CFPFA" ... and that's why you can't use the eForth
implementation.

*That's* what limits your choices to two basic approaches:
(1) Pad CREATE words so that PFA =(CFA++)++, rather than CFA++
(2) Encode the difference between actual C-function-pointers and DOES
target segment addresses, and have your C-coded inner interpreter
decode and act appropriately.

You can chase up other options "debug code" style, but they will be
will-o-wisps ~ the other valid options for an indirect threaded
interpreter assume that the content of the CFA is actually a code
address. For a particular CPU and particular C-compiler, you could
embed code that would work correctly, but it would not be portable
across multiple CPU''s and C-compilers.

If you are not using the top half of the memory range, your C-function-
pointers will all be positive, and one encoding is to set the sign bit
of DOES segment addresses. Then its an if-then on the value being
positive, jumping to the C-function if its positive, otherwise
clearing the top bit and performing DODOES inline within the C-coded-
inner-interpreter.

However, option (1) is simpler, so I'd suggest doing that first,
profiling the result, and if it consumes more space than you want
while having ample speed for your purposes, exploring option (2).

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

#8485

"BruceMcF" <agila61@netscape.net> wrote in message
news:dd825268-f575-4665-ba8d-bd6297b89455@z12g2000yqm.googlegroups.com...
> On Dec 29, 3:39 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
> > eForth uses definitions similar to those I'm using for CONSTANT and
> > VARIABLE. I'm not quite sure, but it seems that eForth doesn't
> > overwrite the CFA with DODOES. I think doing that may be the source
> > of my problems.
>
> > Instead, I think eForth leaves the CFA as DOVAR, compiles DODOES
> > inline into a defintion, and follows that by the DOES> address.
>
> Which eForth, v1 or v2?

Not sure.  No point.

> No, it does not leave the CFA as DOVAR, instead it changes the CFA as
> the location of DODOES at the head of the does segment. Yes, it does
> compile DODOES inline at the head of the does segment.

Hmm...  Ok.

> As you've noted, your CFA is not a real code field, its a C-function-
> pointer-field, "CFPFA" ... and that's why you can't use the eForth
> implementation.
>
> *That's* what limits your choices to two basic approaches:
> (1) Pad CREATE words so that PFA =(CFA++)++, rather than CFA++
> (2) Encode the difference between actual C-function-pointers and DOES
> target segment addresses, and have your C-coded inner interpreter
> decode and act appropriately.

So, I decided I try what I thought eForth was doing, that you said it
wasn't, to see if I could get that to work or not.  It seems a bit cleaner
to me.  If not, then I would attempt one of the methods you've strongly
suggested.  Am I stubborn? ;-)

Well, I got sidetracked slightly and ran into some other issues.  I didn't
know why there was an EXIT on my constants created with DOCON, but not on
my variables created with DOVAR.  Removing the the EXIT's and the part of
the DOCON primitive code that used the EXIT's revealed a bug in X, the
termination primitive for the dictionary.  So, I fixed that.  I decide to
eliminate DOCON since I also have LIT.  Why use a primitive for a constant
that can only be used in the CFA when I can use LIT for constants anywhere
as long as I use ENTER ... EXIT?  I had used DOCON for six constants: 3
bootstrap and 3 high-level forth.  I replace them with ENTER ... EXIT
sequences using LIT.  So, I now have one less CFA routine and primitive!
Unfortunately, that created a circular reference for one constant.  I needed
to know CELL for LIT indirectly via CELL+ and which meant I couldn't define
CELL in terms of LIT.  So, I implemented a variable with CELL's value and
rewrote CELL to fetch that variable.  That breaks the circular reference.
So,I upped my variables to ten.  In the process, I realized that DOVAR could
probably be eliminated too.  If LIT can fetch the next value from the
instruction stream, place it on the stack, and continue execution with the
next compiled address, then one should be able to code a similar word that
places the address of the next value on the stack and continues execution.
If so, then DOVAR can be eliminated too (except maybe for CELL ...).  Is
there a common name for such a word? e.g., ADR or LOC? To me, it just seems
to be the interpreter definition for LIT but without the fetch:

: LIT R> DUP CELL+ >R @ ;

As for the DOES>, the changed definition seems to be compiling properly and
in a way I think should work.  But, I would need to change DOVAR to allow
execution to continue with the next compiled address after the variable
value.  That would require adjusting the primitive to push a value on the
return stack and have each variable use an EXIT leading me back into the
same issue I just had with DOCON.  Now, if I eliminate DOVAR replacing it
with a word like LIT that doesn't fetch, then I can see this all working ...
And, I'll have eliminated another primitive and CFA routine!  Alternately, I
may duplicate DOVAR's functionality with one for pre-compiled variables, and
another slightly modified for DOVAR for runtime, at least until I can rework
things.


Rod Pemberton

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

#8491

On Dec 30, 1:31 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

> So, I decided I try what I thought eForth was doing, that you said it
> wasn't, to see if I could get that to work or not.  It seems a bit
> cleaner to me.

So, you are going to leave the CFA as DOVAR. How precisely does that
result in a call to the does segment? You don't have a working DOES>
unless the does segment gets executed. That requires the address of
the does segment to be stored in the CREATEd word.

There is a third solution, actually, which is to make it a doubly
indirect threaded compiler ~ have the contents at the code field
address be the address of a C function pointer rather than being a C
function pointer itself. Then you can embed the C function pointer for
DODOES at the head of the DOES segment and you are set.

> I decide to eliminate DOCON since I also have LIT.  Why use a
> primitive for a constant that can only be used in the CFA when I can
> use LIT for constants anywhere as long as I use ENTER ... EXIT?

The normal rationale is efficiency ~ saving the execution of the ENTER
and EXIT. If the focus is on a small kernel, its fine to have pre-
compiled constants using LIT.

> If LIT can fetch the next value from the instruction stream, place
> it on the stack, and continue execution with the next compiled
> address, then one should be able to code a similar word that
> places the address of the next value on the stack and continues
> execution.

Where would you use it? Other than in defining a variable to be a four
cell sequence of:
   ENTER <foo> [_variable_location_] EXIT
... in place of:
   DOVAR [_variable_location_]

... because if its a straight up swap of that "<foo>" word for DOVAR
when that "<foo>" word is not used anywhere else, its hard to see what
the benefit is.



> As for the DOES>, the changed definition seems to be compiling
> properly and in a way I think should work.  But, I would need to
> change DOVAR to allow execution to continue with the next compiled
> address after the variable value.

But you can't use that alternate DOVAR for CREATE, because CREATE can
have a body much longer than just one cell. Just consider a normal
long string constant,

: $CONSTANT ( ca u "name" )
   CREATE DUP , HERE SWAP CHARS DUP ALLOT MOVE
   DOES> DUP @ SWAP CELL+ ;

Where its:
      <name-structure>
CFA:  DOCREATE ; or maybe DODOES
      ; ?? Maybe one cell padding for DOES> segment address
      .word u ; stored cell long length
      .char ... ; "u" chars in string.

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

#8512

"BruceMcF" <agila61@netscape.net> wrote in message
news:724b7ee6-9199-4566-b504-c8b90203cd4d@d8g2000yqk.googlegroups.com...
> On Dec 30, 1:31 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:

> So, you are going to leave the CFA as DOVAR.

I'm going to attempt to ...

> How precisely
> does that result in a call to the does segment?

It doesn't.

> You don't have a working DOES>
> unless the does segment gets executed.

It should.

> That requires the address of the does segment
> to be stored in the CREATEd word.

It is.


CONSTANT, which uses DOES>, does this:

DOVAR   ( CFA )
<comma'd constant>       ( 1st PF )
... ( optional compiled addresses )
DODOES
DOES> address
... ( optional compiled addresses )
EXIT

DOVAR executes placing the address of the constant on the stack.  It will
continue execution at DODOES. (not currently implemented)  DODOES pushes the
IP on the stack, gets the DOES> address and pushes that on the return stack.
EXIT returns to pushed address.  It seems to me that DODOES no longer needs
to push the IP since DOVAR is doing that.

> There is a third solution, actually, which is to make it a doubly
> indirect threaded compiler ~ have the contents at the code field
> address be the address of a C function pointer rather than being a C
> function pointer itself. Then you can embed the C function pointer for
> DODOES at the head of the DOES segment and you are set.

I'd have to review how exactly I did that.  There was quite a bit of
juggling until I found an ANSI C compatible solution for addresses,
constants, function pointers, etc.  I.e., I'm not sure at the moment for
which one the C type would be correct.

> > I decide to eliminate DOCON since I also have LIT. Why use a
> > primitive for a constant that can only be used in the CFA when I can
> > use LIT for constants anywhere as long as I use ENTER ... EXIT?
>
> The normal rationale is efficiency ~ saving the execution of the ENTER
> and EXIT. If the focus is on a small kernel, its fine to have pre-
> compiled constants using LIT.

Yes, but in my case that adds a primitive, i.e., C code, instead of Forth
code as text or precompiled in C.

> > If LIT can fetch the next value from the instruction stream, place
> > it on the stack, and continue execution with the next compiled
> > address, then one should be able to code a similar word that
> > places the address of the next value on the stack and continues
> > execution.
>
> Where would you use it?

DOVAR, the DODOES described above, ...

> [...] is not used anywhere else, its hard to see what
> the benefit is.

Well, it should eliminate a primitive which is C code.  One primitive is not
a big issue, but the fewer the better.  The Forth code can become more
generalized or standardized and less C environment specific.

> > As for the DOES>, the changed definition seems to be compiling
> > properly and in a way I think should work. But, I would need to
> > change DOVAR to allow execution to continue with the next compiled
> > address after the variable value.
>
> But you can't use that alternate DOVAR for CREATE, because CREATE
> can have a body much longer than just one cell. Just consider a normal
> long string constant,
>
> : $CONSTANT ( ca u "name" )
>    CREATE DUP , HERE SWAP CHARS DUP ALLOT MOVE
>    DOES> DUP @ SWAP CELL+ ;
>
> Where its:
>       <name-structure>
> CFA:  DOCREATE ; or maybe DODOES
>       ; ?? Maybe one cell padding for DOES> segment address
>       .word u ; stored cell long length
>       .char ... ; "u" chars in string.

I think $CONSTANT would do this:

<dictionary header>
CFA: DOVAR
comma'd constant
.string ... ;  ( non-standard format )
DODOES
DOES> address
EXIT

Yes, if DOVAR continues execution after the constant, that would require a
branch or 'DOSTR' to skip over ALLOT'd space ...  So, there are some issues
with user defined strings and arrays.  I think a different definition could
place the ALLOT'd space after the code ...  If so, is this an implementation
issue?  I.e., are there or could there be some Forth's for which the
$CONSTANT definition will fail validly?  , COMMA and C, seem to be the
primary uses of ALLOT, at least in what I've coded so far.  It's possible
that ALLOT could be modified or duplicated so that large allocations place a
branch around the allotted space.  String concatenation or linked lists via
multiple ALLOTs might be an issue.  Are those done that way in Forth?
Anyway, just a thought ...


Rod Pemberton

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

#8523

On Dec 31, 5:52 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> <dictionary header>
> CFA: DOVAR
> comma'd constant
> .string ... ;  ( non-standard format )
> DODOES
> DOES> address
> EXIT

> Yes, if DOVAR continues execution after the constant, that would
> require a branch or 'DOSTR' to skip over ALLOT'd space ...

Over and above the massive wasted space you are adding to CREATEd
segments that have a DOES> applied just to avoid padding all CREATEd
words by one cell ...

... while building the body in standard Forth code, the data space is
*contiguous* ~ unbroken.

Remember, the PURPOSE of CREATE HERE and ALLOT is as building blocks
to allow the construction of general purpose data structures. That is
*why* they can be used to define VARIABLE and CONSTANT ~ but a version
that only *works* for defining VARIABLE and CONSTANT does not actually
work when interpreting actual Forth code.

(1) And the construction of the general purpose data structure has to
be able to start AS SOON as you are done with CREATE.

(2) And has to be able to be patched with DOES> *at any time while
building that word*.

(1) and (2) are an envelope around your design criteria. Violate (1)
and CREATE is useless as a general purpose data structure building
word, violate (2) and you place constraints on DOES> that do not exist
in normal implementations and which existing or future Forth94 source
has not reason to respect.

Think about a structure that is an item in a linked list of counted
strings:

CFA: DOVAR
     .word ... ; comma'd constant
     ; **1 ?
     .word nextitem
     ; **2 ?
     .byte $4,"item
     ; **3 ?

: MAKE-LINKED: ( addr1 "name" -- addr2 )
   CREATE HERE SWAP , ;

There are a set of things, "tokens", that are linked in the background
for whatever reason.

: token: ( "name" -- ) \ "name" ( -- addr )
   token-head @ MAKE-LINKED: token-head ! DOES> CELL+ ;

The $token is one of them (I suppose it might be strings of 31 or
less, so high three bits not clear can be detected to be some other
type of token), and the string token word itself should act as a
string constant:

: $token: ( ca u "name" -- ) \ "name" ( -- ca u )
   token: DUP 31 0 XOR AND ABORT" token string too long."
   $, DOES> CELL+ COUNT ;

Note that you don't "know" that the string is going to be counted when
$, executes, since its just a word that places a counted string at
HERE.

Now matter how much you squirm, the DODOES cannot be placed at point
"**2" above without violating contiguity of the body. So its got to
either be at point **1 or at point **3.

But it can't be at **3, because DOES> can be executed at any time
while build the word. Including, as above, executed once for one data
structure and executed again for an extension of that data structure
to over-ride the original default behavior.

So it has to be at **1.

But if its at **1, what do you gain leaving the DOVAR in place,
because the first thing your DODOES would have to do would be to DROP
the variable address placed on the stack to put in its place the
address of the actual body of the created word.

And if its at **1, you have added TWO cells to every created word.

CFA:    DOVAR
        .word ... ; variable location, not used
        DOCREATED
        .word 0 ; still need a place for the DODOES address to go
        EXIT
        ; body

... which on DOES becomes

CFA:    DOVAR
        .word xxxx ; variable location, not used
        DODOES
        .word does_segment
        EXIT
> So, there are some issues with user defined strings and arrays.

Yes, there are issues: you are breaking the actual use of CREATE for
actual code, while flailing around with trying to do the basics the
hard way around.

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

#8534

"BruceMcF" <agila61@netscape.net> wrote in message
news:a9e89231-b066-43ef-be72-2f0fe439a526@n39g2000yqh.googlegroups.com...
> On Dec 31, 5:52 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
> > <dictionary header>
> > CFA: DOVAR
> > comma'd constant
> > .string ... ; ( non-standard format )
> > DODOES
> > DOES> address
> > EXIT
>
> > Yes, if DOVAR continues execution after the constant, that would
> > require a branch or 'DOSTR' to skip over ALLOT'd space ...
>
> Over and above the massive wasted space you are adding to CREATEd
> segments that have a DOES> applied just to avoid padding all CREATEd
> words by one cell ...

Yeah, that too ...

> ... while building the body in standard Forth code, the data space is
> *contiguous* ~ unbroken.

Yes.

> CFA: DOVAR
>      .word ... ; comma'd constant
>      ; **1 ?
>      .word nextitem
>      ; **2 ?
>      .byte $4,"item
>      ; **3 ?
> [...]
> Now matter how much you squirm, the DODOES cannot be placed
> at point "**2" above without violating contiguity of the body. So its
> got to either be at point **1 or at point **3.
> [...]
> So it has to be at **1.

It seems that it is quite complicated to store a DOES> address in the PF
region.  I.e., a variable location leads to inability to locate it, a fixed
location will overwrite data or code address or vice-versa, allowing
execution to continue until it finds it will work for code definitions but
not data definitions which will have to be jumped over, etc.  The apparent
difficulties in implementing DOES> would imply to me that DOES> is really
not a good fit with the way a Forth interpreter works ...  I don't believe
that other Forth words have such issues, do they?  Well, I can't store the
DOES> address in the CFA.  I'm 100% positive that'll fail.  So, I may have
no choice but to add a extra field for it.  Once I do that, that field will
be named PFA instead of the code or data part of a word.  So, what is the
code or data part usually named?

> Yes, there are issues: you are breaking the actual use of CREATE
> for actual code, while flailing around with trying to do the basics the
> hard way around.

I'm just exploring the options ...

If I hadn't realized the my DOES> only worked for CONSTANT and VARIABLE, I
wouldn't be going through this.  It was hard enough to find info on how they
worked the first time, and to get them to work for CONSTANT and VARIABLE.  I
couldn't even dump definitions as hex values back then ...

The one solution is elegant for a code definition, IMO.  I hadn't considered
a data definition.  That could be lack of Forth experience, or it could be I
didn't come across the iimplementation problem via execution of some other
word since I'm not done implementing ...  ;-)   E.g., I haven't implemented
." dot-quote, etc., where I would be storing a block of data in a word.
E.g., I know another use of CREATE fails due to an overwrite of my input
buffer.  I just haven't found and fixed it yet.

Thanks.


Rod Pemberton

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

#8540

On Dec 31, 8:10 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

> It seems that it is quite complicated to store a DOES> address in the PF region.

That shouldn't be surprising, since the whole point of the data body
is to give the user maximum flexibility, and so trying to implement
DOES> to trample on the body is not going to occur to even a sometime
off&on forth user like myself, let alone an experienced forth user.

> Well, I can't store the
> DOES> address in the CFA.  I'm 100% positive that'll fail.

That depends on your inner interpreter: but it should be easier to add
the padding and wait until you have a working system.

All of this is because your "CFA" isn't really a code field address.
If it was a CFA, you could just embed code to do the does segment
launch at the start of the does, then the address of that code can go
into the code field.

(1) Make it a pointer to a c function pointer, then you can start the
does segment with a DODOES that is a c-function pointer

(2) Make your primitives tokens, and execute the primitives in a case
statement. Do the does action implicitly when the contents of CFA are
out of range of the tokes.

(3) If the c-function pointers will be in the positive, flip the sign
bit of does-segment addresses.

So its not particularly hard to come up with a one cell substitute
that will work with the right c-coded inner interpreter, its just that
padding the CFA only requires adjusting DOCREATE DODOES and CREATE so
its probably the short path to a working implementation.

Regarding terminology, go ahead and call the thing that holds c-
function the code field, so the address of that field is the CFA. The
data body address is a traditional parameter field, so its address may
as well be the PFA.

You don't have to call the padding cell anything, just treat the code
field as two cells wide. CFA>PFA would just be:
    : CFA>PFA ( cfa -- pfa) CELL+ CELL+ ;

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

#8649

"BruceMcF" <agila61@netscape.net> wrote in message
news:724b7ee6-9199-4566-b504-c8b90203cd4d@d8g2000yqk.googlegroups.com...
> On Dec 30, 1:31 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
...

> > If LIT can fetch the next value from the instruction stream, place
> > it on the stack, and continue execution with the next compiled
> > address, then one should be able to code a similar word that
> > places the address of the next value on the stack and continues
> > execution.
>
> Where would you use it?

: LOC R> DUP CELL+ >R ;

I responded to that before but not as completely, so I'll be repeating
myself slightly.  I think LOC should allow me to eliminate DOVAR.  The
exception is CELL which also has a circular reference with LOC.  CELL
will have to remain DOVAR based for now.  LOC is more generic and does the
same thing as DOVAR, but allows execution to continue with the following
compiled word, just like LIT.  Also, LOC, a high-level word, can be used to
implement both variables and constants - stand-alone or inlined - without
need of DOVAR or DOCON as primitives.  E.g., it should be useful if someone
needs a word local, temporary variable such as counter.  I think it would be
convenient with DUP and +! for a counter within a loop.  It'd be unnamed and
completely internal to the current definition.  For bootstrap code, LIT
<val> can replaced with: LOC <val> @

I really like the extra flexibility that LOC provides, or should.  I'll
probably attempt using LOC in the next few days.  I probably won't remove
or replace LIT with LOC, at least for a while, since I've got 22 of them
already ...


Rod Pemberton

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

#8662

On Jan 4, 5:13 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> I really like the extra flexibility that LOC provides, or should.  I'll
> probably attempt using LOC in the next few days.

> I probably won't remove or replace LIT with LOC, at least for a while,
> since I've got 22 of them already ...

I don't get the benefit yet ... if you're swapping DOVAR with LOC then
you've not gained anything yet in terms of primitive count, and have
made each VARIABLE one cell larger. If you replace each:
   ... [DOLIT] [<value>] ....

... in the definition with:
   ... [LOC] [<value>] [@] ...

... you've fattened up all of your definitions by one cell per
literal, to eliminate the [LIT] and allow [LOC] to work as both a
space-inefficient DOVAR factor and a space-inefficient DOLIT factor.

But if you are willing to make all of your variables one cell bigger,
you can define VARIABLE as (in effect):
   : VARIABLE HERE 0 , ALLOT CONSTANT ;

... like a variable definition in a ROMable Forth compiler, making the
variable a constant pointing to the variable cell.

That saves the primitive right away and allows literals to be two
cells per literal in a definition rather than three cells per literal.

Indeed, if you are willing to trade off dictionary size for fewer
primitives, you can VARIABLE make two cells bigger than the fig-Forth
style and CONSTANT one cell bigger, with, in effect:
   : CONSTANT HEADER 'DOLIT , , 'EXIT , ;
   : VARIABLE HERE 0 , CONSTANT ;

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

#8300

Op Wed, 21 Dec 2011 16:14:25 -0500 schreef Rod Pemberton:

<snip>
> CREATE compiles something into the CFA ...

CREATE makes a header and cfa (containing DOCREA or ENTER DOCREA). Both did
not exist before executing CREATE.

> 
> IIRC, descriptions of Forth that use the definitions for CONSTANT and
> VARIABLE that I'm using and you posted, compile DODOES and DOVAR.  I don't
> recall where those definitions came from.  They seem to be very prevalent.
> Are those eForth definitions?  IIRC, fig-Forth compiled DOCON and DOVAR.  I
> have some notes which say:
Those definitions are in eForth but they are much older. E.g. in Figforth
from about 1978.

> 
>  CREATE compiles DOVAR (or ENTER DOVAR)
>  VARIABLE compiles DOVAR (or ENTER DOVAR)
>  CONSTANT compiles DODOES (or ENTER DODOES)
>  LITERAL compiles DOLIT (or ENTER DOLIT)

LITERAL is something different. DOLIT does not start a definition. LITERAL
compiles DOLIT and the number into the colon definition. In Figforth it was
called LIT.

-- 
Coos

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

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

#8261

In article <jcqb56$rai$1@speranza.aioe.org>,
Rod Pemberton <do_not_have@noavailemail.cmm> wrote:
>"BruceMcF" <agila61@netscape.net> wrote in message
>news:5148d2e6-54e0-4168-94f5-fcc634bcba4a@i6g2000vbe.googlegroups.com...
>> I think that for Rod's, DOCREATE should be the equivalent of:
>>   R> CELL+ EXIT
>
>Hmm, I don't have a DOCREATE.  Merits of DOCREATE are?
>
>My CREATE COMPILEs a DOVAR currently.

You would be better off if your thinking went like
"my DOVAR compiles a CREATE currently".
>
>

<SNIP>

>
>
>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]

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

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

csiph-web