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 1 of 4  [1] 2 3 4  Next page →

#7875 — dot-quote implementation question

fig-Forth's dot-quote ." when compiled compiles (.") which is a word for
typing compiled strings.  I'm wondering why a CFA routine, e.g., DOCON
DOCOL etc, was *not* used to implement string variables or string constants?
By CFA routine, I mean DOCOL DOCON DOVAR DOUSER

Also, fig-Forth marks CFA routines with ;CODE  Apparently, the ;CODE
routines in : CONSTANT VARIABLE and USER were named as DOCOL
DOCON DOVAR and DOUSER at some point.  With what Forth were those
names defined?


Rod Pemberton

[toc] | [next] | [standalone]

#7880

"Rod Pemberton" <do_not_have@noavailemail.cmm> writes:
>
>fig-Forth's dot-quote ." when compiled compiles (.") which is a word for
>typing compiled strings.  I'm wondering why a CFA routine, e.g., DOCON
>DOCOL etc, was *not* used to implement string variables or string constants?
>By CFA routine, I mean DOCOL DOCON DOVAR DOUSER

Probably because fig-Forth did not define string variables as separate
things.  The address of a counted string can be stored in a normal
cell-sized variable or a constant can be named for it.

>Also, fig-Forth marks CFA routines with ;CODE  Apparently, the ;CODE
>routines in : CONSTANT VARIABLE and USER were named as DOCOL
>DOCON DOVAR and DOUSER at some point.  With what Forth were those
>names defined?

I guess fig-Forth.  Fig-Forth was distributed as assembler listings
for conventional assemblers, and these routines had these names in the
assembly listings.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2011: http://www.euroforth.org/ef11/

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

#7891

On Dec 10, 7:00 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> "Rod Pemberton" <do_not_h...@noavailemail.cmm> writes:
> >Also, fig-Forth marks CFA routines with ;CODE  Apparently, the ;CODE
> >routines in : CONSTANT VARIABLE and USER were named as DOCOL
> >DOCON DOVAR and DOUSER at some point.  With what Forth were those
> >names defined?

> I guess fig-Forth.  Fig-Forth was distributed as assembler listings
> for conventional assemblers, and these routines had these names in the
> assembly listings.

Note that the names respected the sometimes tight constraints on
assembler labels in some assemblers of the day ~ all upper case, all
ASCII text, labels short ~ it looks like five chars or less in the
6502 printout (which gives DOUSER as DOUSE) (which allows an 8byte
fixed width table with chars, count or nul terminator, and two bytes
to hold the address of the label).

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

#7917

"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
news:2011Dec10.130036@mips.complang.tuwien.ac.at...
> "Rod Pemberton" <do_not_have@noavailemail.cmm> writes:
> >
> > fig-Forth's dot-quote ." when compiled compiles (.") which is a word for
> > typing compiled strings.  I'm wondering why a CFA routine, e.g., DOCON
> > DOCOL etc, was *not* used to implement string variables or string
> > constants?  By CFA routine, I mean DOCOL DOCON DOVAR DOUSER
>
> Probably because fig-Forth did not define string variables as separate
> things.  The address of a counted string can be stored in a normal
> cell-sized variable or a constant can be named for it.
>

Do you (or anyone else) think string variables are useful functionality?
Missing functionality?  If not, why not?  Many HLLs have them.  C doesn't
fully support them, which is more like Forth.


Rod Pemberton

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

#7923

On 11.12.2011 03:10, Rod Pemberton wrote:
> Do you (or anyone else) think string variables are useful functionality?
> Missing functionality?  If not, why not?  Many HLLs have them.  C doesn't
> fully support them, which is more like Forth.
>

Space, the final frontier. These are the voyages of the starship 
Enterforth. Its infinite mission, to explore strange new worlds to seek 
out new life and new variables, to boldly go where no C has gone before.

Beam me down, Scottie.

It's 2011 and people in c.l.f. are still trying to parse strings...

:o)

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

#7925

Rod Pemberton <do_not_have@noavailemail.cmm> wrote:
> 
> Do you (or anyone else) think string variables are useful functionality?

Sometimes.

> Missing functionality?

Missing from what?  You want one, define one.  How is a string
variable going to be any different from create ... allot ?

Andrew.

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

#7963

"Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
news:HJqdneRGLvDg53nTnZ2dnUVZ_qidnZ2d@supernews.com...
> Rod Pemberton <do_not_have@noavailemail.cmm> wrote:
> >
> > Do you (or anyone else) think string variables are useful functionality?
>
> Sometimes.
>
> > Missing functionality?
>
> Missing from what?  You want one, define one.  How is a string
> variable going to be any different from create ... allot ?

It would be a true variable and it would need a CFA routine, like DOCON or
DOVAR etc, e.g., say DOSTR or somesuch ...  That functionality is not
present in Forth, i.e., missing functionality.  Current functionality is
close for string constants, but does not use a CFA routine.   A true string
variable would only be a string variable, like words created by CONSTANT or
VARIABLE.  Currently, string constants in Forth can be compiled into any
word.  So, there would probably be a word, say STRING, to create a string
variable that would store DOSTR in the CFA field.  A word created with
STRING could only hold a string, just like a word created by CONSTANT or
VARIABLE can only hold integer constants and variables.


Rod Pemberton

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

#7968

Rod Pemberton <do_not_have@noavailemail.cmm> wrote:
> "Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
> news:HJqdneRGLvDg53nTnZ2dnUVZ_qidnZ2d@supernews.com...
>> Rod Pemberton <do_not_have@noavailemail.cmm> wrote:
>> >
>> > Do you (or anyone else) think string variables are useful functionality?
>>
>> Sometimes.
>>
>> > Missing functionality?
>>
>> Missing from what?  You want one, define one.  How is a string
>> variable going to be any different from create ... allot ?
> 
> It would be a true variable and it would need a CFA routine, like DOCON or
> DOVAR etc, e.g., say DOSTR or somesuch ...  That functionality is not
> present in Forth, i.e., missing functionality.

But what would that routine do?  It'd leave its address on the stack.
Which is what CREATE does.

> Current functionality is close for string constants, but does not
> use a CFA routine.  A true string variable would only be a string
> variable, like words created by CONSTANT or VARIABLE.  Currently,
> string constants in Forth can be compiled into any word.  So, there
> would probably be a word, say STRING, to create a string variable
> that would store DOSTR in the CFA field.  A word created with STRING
> could only hold a string, just like a word created by CONSTANT or
> VARIABLE can only hold integer constants and variables.

What does DOSTR do?  A sample implementation would help?

Andrew.

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

#8034

"Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
news:7pmdnYvXSP5SQHjTnZ2dnUVZ_vOdnZ2d@supernews.com...
> Rod Pemberton <do_not_have@noavailemail.cmm> wrote:
> > "Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
> > news:HJqdneRGLvDg53nTnZ2dnUVZ_qidnZ2d@supernews.com...
> >> Rod Pemberton <do_not_have@noavailemail.cmm> wrote:
> >> >

> >> How is a string
> >> variable going to be any different from create ... allot ?
> >
> > It would be a true variable and it would need a CFA routine, like
> > DOCON or DOVAR etc, e.g., say DOSTR or somesuch ...  That
> > functionality is not present in Forth, i.e., missing functionality.
>
> But what would that routine do?  It'd leave its address on the stack.

The address of a word with the address of DOSTR in it's CFA may be the
address of that word's NFA or LFA.  So, DOSTR would leave the address
of the variable's data location on the stack, e.g., possibly PFA.  DOSTR
might need to do other stuff too.  The CFA routine DOVAR does this for
integer variables.  DOVAR doesn't need to do other stuff.  DOVAR and
DOCON essentially create routines for implementing two types: integer
variables and integer constants.  I was thinking that a DOSTR routine
could create a type for variable strings.  However, I guess DOVAR could
be re-used for any variable type that returns an address, which doesn't
need to modify the control-flow of the interpreter, and doesn't need to
do other stuff too.  DODOES modifies the control flow.  To re-use
DOVAR, strings and variables should be stored in the same memory area.

> Which is what CREATE does.

No, CREATE does not get executed when a variable is interpreted or
executed in an ITC Forth.  The CFA routine is what gets executed.  For
some implementations, the following is true.  It depends on the
implementation.  The CFA routine for variables is DOVAR.  CREATE gets
executed when a variable or constant are created using VARIABLE or
CONSTANT.  CREATE compiles DOVAR into the CFA for words
created by both VARIABLE and CONSTANT since they both use
CREATE.  For words created by VARIABLE, the CFA remains set to
DOVAR.  For words created by CONSTANT, DODOES eventually
overwrites the CFA which was set to DOVAR by CREATE because
CONSTANT uses DOES> .


Rod Pemberton

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

#7989

On Dec 12, 5:04 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Andrew Haley" <andre...@littlepinkcloud.invalid> wrote in message
> > Missing from what?  You want one, define one.  How is a string
> > variable going to be any different from create ... allot ?

> It would be a true variable and it would need a CFA routine,
> like DOCON or DOVAR etc, e.g., say DOSTR or somesuch ...
> That functionality is not present in Forth, i.e., missing
> functionality.

What difference does it make about it having "its own CFA routine"?

Since whether it has its own CFA routine rather than a DOES> link is
an implementation details as opposed to a functionality, not having it
is not missing a functionality.

Indeed, Forth94 is perfectly happy with:

: CONSTANT CREATE , DOES> @ ;

... so having an *integer* constant does not imply the existence of a
DOCON routines.

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

#8032

"BruceMcF" <agila61@netscape.net> wrote in message
news:b1b9cfa4-29dd-431d-9d52-9f8ac4d59ebd@v6g2000yqv.googlegroups.com...
>
> What difference does it make about it having "its own CFA routine"?

Two of the historical CFA routines, DOCON and DOVAR, seem to
implement two types for Forth: integer constant and integer variable.
I was thinking along the lines that additional routines could add additional
types.

> Since whether it has its own CFA routine rather than a DOES> link is
> an implementation details as opposed to a functionality, not having it
> is not missing a functionality.

Are you saying the CFA routines for DOVAR and DOCON are
sometimes one or both eliminated?

Are you saying all CFA routines except DOCOL can be replaced by
DODOES ("a DOES> link") to the appropriate functionality?

> Indeed, Forth94 is perfectly happy with:
>
> : CONSTANT CREATE , DOES> @ ;
>
> ... so having an *integer* constant does not
> imply the existence of a DOCON routines.

True.  Although, it seems likely that DOCON is still used internally for
pre-compiled constants.  Otherwise, I'd think the dictionary, at least the
pre-compiled portion, would be somewhat convoluted to implement, if using
DODOES and @ instead of DOCON.  Wouldn't it?

AIUI, DOVAR and @ can be equivalent to DOCON.  DODOES
performs DOVAR as part of it's functionality.


Rod Pemberton

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

#8165

"Rod Pemberton" <do_not_have@noavailemail.cmm> wrote in message
news:jc7oeq$76d$1@speranza.aioe.org...
> "BruceMcF" <agila61@netscape.net> wrote in message
> news:b1b9cfa4-29dd-431d-9d52-9f8ac4d59ebd@v6g2000yqv.googlegroups.com...
> >

Did my posts come across?  One to Andrew and one to Bruce? ...

> > Since whether it has its own CFA routine rather than a DOES> link is
> > an implementation details as opposed to a functionality, not having it
> > is not missing a functionality.
>
> Are you saying the CFA routines for DOVAR and DOCON are
> sometimes one or both eliminated?
>
> Are you saying all CFA routines except DOCOL can be replaced by
> DODOES ("a DOES> link") to the appropriate functionality?
>

I was hoping somebody would reply to those.  I previously found the
following definition in a Forth for Unix:

: CREATE HEADER COMPILE (DOES>) 0 , DOES> ;

I really didn't want to discuss that definition until someone answered my
questions.  I figured if I mentioned that definition first, it would flavor
the conversation towards that definition.

> > Indeed, Forth94 is perfectly happy with:
> >
> > : CONSTANT CREATE , DOES> @ ;
> >
> > ... so having an *integer* constant does not
> > imply the existence of a DOCON routines.
>
> True.  Although, it seems likely that DOCON is still used internally for
> pre-compiled constants.  Otherwise, I'd think the dictionary, at least the
> pre-compiled portion, would be somewhat convoluted to implement, if using
> DODOES and @ instead of DOCON.  Wouldn't it?
>

I was hoping somebody would respond to that to.  Does not having
DOCON make implementing pre-compiled constants more difficult?


Rod Pemberton

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

#8166

Rod Pemberton <do_not_have@noavailemail.cmm> wrote:
> "Rod Pemberton" <do_not_have@noavailemail.cmm> wrote in message
> news:jc7oeq$76d$1@speranza.aioe.org...
>> "BruceMcF" <agila61@netscape.net> wrote in message
>> news:b1b9cfa4-29dd-431d-9d52-9f8ac4d59ebd@v6g2000yqv.googlegroups.com...
>> >
> 
> Did my posts come across?  One to Andrew and one to Bruce? ...
> 
>> > Since whether it has its own CFA routine rather than a DOES> link is
>> > an implementation details as opposed to a functionality, not having it
>> > is not missing a functionality.
>>
>> Are you saying the CFA routines for DOVAR and DOCON are
>> sometimes one or both eliminated?
>>
>> Are you saying all CFA routines except DOCOL can be replaced by
>> DODOES ("a DOES> link") to the appropriate functionality?

Sure.  Why not?
 
> I was hoping somebody would reply to those.  I previously found the
> following definition in a Forth for Unix:
> 
> : CREATE HEADER COMPILE (DOES>) 0 , DOES> ;
> 
> I really didn't want to discuss that definition until someone answered my
> questions.  I figured if I mentioned that definition first, it would flavor
> the conversation towards that definition.

That looks odd.  I wonder what (DOES>) is.  It may be something to do
with the old fig-FORTH <BUILDS DOES> that required an extra cell after
the code field.

>> > Indeed, Forth94 is perfectly happy with:
>> >
>> > : CONSTANT CREATE , DOES> @ ;
>> >
>> > ... so having an *integer* constant does not
>> > imply the existence of a DOCON routines.
>>
>> True.  Although, it seems likely that DOCON is still used
>> internally for pre-compiled constants.  Otherwise, I'd think the
>> dictionary, at least the pre-compiled portion, would be somewhat
>> convoluted to implement, if using DODOES and @ instead of DOCON.
>> Wouldn't it?
> 
> I was hoping somebody would respond to that to.  Does not having
> DOCON make implementing pre-compiled constants more difficult?

Why on Earth should it?  Constants are either going to be handled as

: constant   create ,  ;code ...

or   

: constant   create ,  does> ...

or something that's equivalent.  Surely the question of whether to use
code or high-level is only a matter of efficiency.

Andrew.

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

#8187

"Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
news:NP-dnSVkwaKU8HHTnZ2dnUVZ_hmdnZ2d@supernews.com...
> [...]
> Surely the question of whether to use
> code or high-level is only a matter of efficiency.
>

So far I have 37 pre-compiled primitives (or low-level words), 39
pre-compiled high-level words, and 30 words in ASCII text.  It's in C, but
basically identical to the method used for fig-Forth assembly.  In order to
implement the inner and outer interpreters, parsing words, dictionary words,
and primitives, I need constants as pre-compiled words.  If I define them in
high-level code, they either redefinitions of the same word or unavailable
when I need them.

Hugh Aguilar was criticizing my decision to implement Forth in C, again.
So, I gave him a status update on alt.lang.asm.  It's here if anyone wants
to read it:

http://groups.google.com/group/alt.lang.asm/msg/8182959029b4ba23


Rod Pemberton

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

#8189

Rod Pemberton <do_not_have@noavailemail.cmm> wrote:
> "Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
> news:NP-dnSVkwaKU8HHTnZ2dnUVZ_hmdnZ2d@supernews.com...
>> [...]
>> Surely the question of whether to use
>> code or high-level is only a matter of efficiency.
> 
> So far I have 37 pre-compiled primitives (or low-level words), 39
> pre-compiled high-level words, and 30 words in ASCII text.  It's in
> C, but basically identical to the method used for fig-Forth
> assembly.  In order to implement the inner and outer interpreters,
> parsing words, dictionary words, and primitives, I need constants as
> pre-compiled words.  If I define them in high-level code, they
> either redefinitions of the same word or unavailable when I need
> them.

Ah, OK, so you've got yourself a nasty bootstrapping problem.  There's
a number of good techniques for implementing Forth that are going to
be difficult or impractical to use if you're going via standard C.

Andrew.

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

#8239

Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
> Rod Pemberton <do_not_have@noavailemail.cmm> wrote:
>> "Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
>> news:NP-dnSVkwaKU8HHTnZ2dnUVZ_hmdnZ2d@supernews.com...
>>> [...]
>>> Surely the question of whether to use
>>> code or high-level is only a matter of efficiency.
>> 
>> So far I have 37 pre-compiled primitives (or low-level words), 39
>> pre-compiled high-level words, and 30 words in ASCII text.  It's in
>> C, but basically identical to the method used for fig-Forth
>> assembly.  In order to implement the inner and outer interpreters,
>> parsing words, dictionary words, and primitives, I need constants as
>> pre-compiled words.  If I define them in high-level code, they
>> either redefinitions of the same word or unavailable when I need
>> them.
> 
> Ah, OK, so you've got yourself a nasty bootstrapping problem.  There's
> a number of good techniques for implementing Forth that are going to
> be difficult or impractical to use if you're going via standard C.

I've been thinking about this, and it seems to me like the core
problem is trying to do this in pure Standard C.  If you allowed
yourself the freedom to use a few machine-dependent features it'd be
much easier and much cleaner.  Sure, there would be a portability
layer, but it needn't be a huge thing.

Andrew.

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

#8171

On Dec 13, 9:47 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "BruceMcF" <agil...@netscape.net> wrote in message
> > What difference does it make about it having "its own CFA routine"?

> Two of the historical CFA routines, DOCON and DOVAR, seem to
> implement two types for Forth: integer constant and integer variable.

The key word there is "implement". And of course, historically those
are not types at all ~ they are equally integer constants and
variables, character constants and variables, and pointer constants
and variables.

> I was thinking along the lines that additional routines could
> add additional types.

Yes, in a non-type-checking language, first order "types" would seem
to mean a system of routines for operating on that data. And yes,
implementing a constant and a variable is a reasonable part of that.

But whether the additional routines are primitives or compiled Forth
code is not an essential distinction for that. Implementing string
variables and constants that rely on DOES> routines for their function
would not make any essential difference to that.

>> Since whether it has its own CFA routine rather than a DOES> link is
>> an implementation details as opposed to a functionality, not having it
>> is not missing a functionality.

> Are you saying the CFA routines for DOVAR and DOCON are
> sometimes one or both eliminated?

DOCON definitely ~ its a question of efficiency (you don't want slow
constants) and sometimes bootstrapping whether its needed. Indeed,
going back to the $10 computer project where the target is the
venerable 6502 instruction set, because the $10 computers are
*produced* to run almost equally venerable cracks of old NES games, if
RAM is precious and clock cycles are precious but the dictionary is
mostly in flash RAM that is paged into memory in big chunks, you might
have a subroutine threaded forth and the CONSTANT might be compiled by
copying the string:
   DEX
   LDA #0
   STA DL,X
   LDA #0
   STA DH,X
   RTS
... and then CONSTANT picking the constant values off the stack and
putting them in the right place.

Don't confuse the behavior of the words with the implementation of the
words ~ a danger if you are implementing a Forth without first
programming a couple of applications in Forth.

> Are you saying all CFA routines except DOCOL can be replaced by
> DODOES ("a DOES> link") to the appropriate functionality?

Well, that would rely heavily on CREATE, so in that implementation
approach, DOCREA and DODOES would be critical. DOCON is an efficiency
decision.

> > Indeed, Forth94 is perfectly happy with:
>
> > : CONSTANT CREATE , DOES> @ ;
>
> > ... so having an *integer* constant does not
> > imply the existence of a DOCON routines.
>
> True.  Although, it seems likely that DOCON is still used
> internally for pre-compiled constants.  Otherwise, I'd think
> the dictionary, at least the pre-compiled portion, would be
> somewhat convoluted to implement, if using DODOES and @ instead
> of DOCON.  Wouldn't it?

You'd just build DODOES and @ and the HLL CONSTANT in the dictionary
before building the first pre-compiled constant. If you are meta-
compiling a free-standing system, the constant values required to
*build* the system are in the host, and the constants *in the target*
only need to be available when the target kernel starts. So you can
just as well embed the constant values in the definitions as literals
and build all the constants available on target start-up as the last
step.

> AIUI, DOVAR and @ can be equivalent to DOCON.  DODOES
> performs DOVAR as part of it's functionality.

In that approach ~ which again, is an *implementation* approach not a
language behavior design question ~ DODOES is not in the CFA in any
event. Its compiled as a code stub in the word that contained DOES> to
start up the interpreting of the following section, and the CFA
contains a pointer to that code.

Given that there's more juggling required than for a CREATE without a
DOES>, when you originally create a word, a DOVAR or DOCREA is
normally put into it to avoid that overhead.

But if its indirect or direct threaded, and you were trying to bring
up fig-Forth fashion, but with a minimum of code, you COULD have a
stub in the coded section that does:

DOVAR:
   CALL DODOES
   .WORD FETCH,EXIT

... and that's your DOVAR. It depends on what your objectives are. If
you are just trying to bring up a Forth system from scratch fig-Forth
style, which might be slow but which can then be used to meta-compile
a more efficient one, having the smallest possible processor dependent
section and then a larger section assembling compiled Forth
definitions which is processor independent is one way to go.

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

#8191

"BruceMcF" <agila61@netscape.net> wrote in message
news:36148df9-ee6c-43b3-bf46-d0123bd1f593@d17g2000yql.googlegroups.com...
>
> Don't confuse the behavior of the words with the implementation of the
> words ~ a danger if you are implementing a Forth without first
> programming a couple of applications in Forth.

If my implementation correctly implements the behavior of the words, does it
matter if I confuse them?

E.g., if my Forth eventually becomes ANS and passes the Hayes core tests,
does it matter if I "wrongly" implemented the functionality of some words?
I.e., a word may have an understanding, or specification meaning, or
historical meaning that is not captured by the tests or implemented by me,
but passes the test.  If so, is the error on my side or the compliance suite
side?  I think it's the latter ...  I have been attempting to capture the
essence of various words as they were implemented in other older Forths.
Sometimes they all do things the same way and other times it's wildly split
as to what was done and what works.

> > AIUI, DOVAR and @ can be equivalent to DOCON. DODOES
> > performs DOVAR as part of it's functionality.
>
> In that approach ~ which again, is an *implementation* approach not a
> language behavior design question ~ DODOES is not in the CFA in any
> event. Its compiled as a code stub in the word that contained DOES> to
> start up the interpreting of the following section, and the CFA
> contains a pointer to that code.

Ok.  Mine works a bit differently, currently.

I have a CFA routine which I call DODOES.  It gets the address for the "code
stub in the word that contained DOES> to start up the interpreting of the
following section" which I'll refer to as after-DOES> address hereafter.
The after-DOES> address is compiled by DOES> into a word's PFA.  DOES> also
compiles DODOES into the CFA.  AIUI, I have to compile the after-DOES>
address into the PFA due to my use of C.  I describe my  implementation in
some depth, after which I have a question about using , COMMA with CREATE
and DOES> prior to the DOES> which could break my implementation.

It's in C not assembly, so I can't put "raw" jump-to addresses into the CFA.
If it were in assembly, the CFA could be set to any address where a valid
assembly routine exists.  I.e., for assembly that works that way, the CFA
can be set to the exact starting point of the after-DOES> code.  It just
jumps there using the CFA value.  Since mine is in C, the CFA must point to
a valid C routine.  I can't place a C routine inlined with the after-DOES>
code and call that routine.  I don't have a built-in C compiler in my Forth
interpreter.  So, I can't create address values at runtime for the CFA.  All
CFA values must be known at compile time.  This means I have a limited and
fixed set of legitimate CFA values, unlike an assembly implementation which
could have a huge number of them.  In this case, that means one of my
primitive (low-level) routines is used for CFA's:  DOVAR DOCON DOCOL
DODOES etc.  The after-DOES> code is in compiled Forth as interpretable
addresses.  That means I have to have a routine which interprets the
addresses there.  DOCOL (or ENTER) does just that, but it needs to be
redirected to the after-DOES> code.  So, DODOES is a routine that gets
the address for the after-DOES> code from within the word compiled using
DOES> and does the redirection.

Currrently, my DOES> looks like this:

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

Recently, I was able to implement it as a defintion in ASCII text.  It's
definition was changed recently too.  I broke it a while back and just fixed
it.  fig-Forth has a SMUDGE in it.  I don't yet.  Obviously, the R>
indicates it's an interpreted Forth, in this case ITC.  LAST is probably
non-standard.  I'd have to recheck was LAST is supposed to do ...  Due to
implementation issues, I have both LAST and LATEST.  LATEST is only for the
NFA.  Actually, LATEST for the dictionary bits that are normally part of the
NFA, but I needed to relocate away from the name portion of the NFA.  LAST
gets the address of the start of current dictionary entry.  LAST is that
address no matter how I reorganize the dictionary structure.  It could be
NFA, LFA, CFA, or PFA.  I had LFA's first, but that caused an issue with a
fig-Forth like definition when I converted from word-by-word parsing to
line-by-line.  So, I reorganized with NFA first, at least temporarily.  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.

DODOES is a primitive (low-level word) in C.  It's placed into the CFA.
When executed instead of ENTER or DOCOL, it pushes the W register onto
the data/parameter stack.  W register is the current instruction pointer for
the interpreter.  DODOES then pushes the 1st PFA value onto the return
stack.  That value is the address that DOES> comma'd into a definition.
It's the address of the after-DOES> code.

Since I'm storing the address of the after-DOES> code in the PFA, I suspect
that a , COMMA could insert values prior to the stored after-DOES> address.
In which case, DODOES would fail.  It doesn't "know" that the after-DOES>
address is not in the location it expects.  Is it valid to use , COMMA
between CREATE and DOES> ?  If someone knows of valid, functional examples
of a , COMMA being used between CREATE and DOES> in a word, could you
post them?  I'll need something to break and/or test with.

> But if its indirect or direct threaded, and you were trying to bring
> up fig-Forth fashion, but with a minimum of code, you COULD have a
> stub in the coded section that does:
>
> DOVAR:
>    CALL DODOES
>    .WORD FETCH,EXIT
>
> ... and that's your DOVAR.

Did you mean DOCON due to the FETCH?

Well, either way, that won't work in my current implementation.  Both DOCON
and DODOES manipulate the return stack, while DOVAR doesn't.  DOCON
continues execution after the constant.  DOVAR doesn't.  DODOES continues
execution at the after-DOES> address stored in the word by DOES>, i.e., the
DOES> "jump-to" address is in the 1st PFA.  All three are primitives
(low-level words).

> It depends on what your objectives are.

My current main objective is to reduce my set of primitives and pre-compiled
Forth code.  I'm migrating to Forth words in ASCII text.  The issue I'm
having is the parsing words are needed to parse words in ASCII text, i.e.,
catch-22.  I may actually have to add some primitives that I didn't
implement since there is no easy way to implement them in high level Forth.


Rod Pemberton

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

#8197

On Dec 18, 7:53 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

> I have a CFA routine which I call DODOES.  It gets the address for
> the "code stub in the word that contained DOES> to start up the
> interpreting of the following section" which I'll refer to as
> after-DOES> address hereafter.

Where is that address for the DOES> segment stored? Under
   <BUILD ... DOES>
... a DODOES was stored in the CFA, the address of the DOES segment
was the first data entry, and DOES> executed the first data entry in
the built word and returned the address of the second data entry in
the built word..

The innovation in moving from <BUILDS ... DOES> to CREATE ... DOES>
was DOES> setting things up so that the address for the DOES> segment
in setting it up so that address *is* the CFA entry, so there is no
difference in size with a regular CREATEd word, so you can CREATE in
one word or on the command line and then execute DOES> in some
following word.

> The after-DOES> address is compiled by DOES> into a word's PFA.
> DOES> also compiles DODOES into the CFA.

Then I assume you have to pad CELL with a spare cell and return the
address two cells after the CFA as the data field address. Luckily
only CREATEd words can take >BODY so you don't have to worry about
detecting which ones have the data space right after the CFA and which
ones have the data space with a cell of padding/address.

I guess it kind of sucks if you have to put a spare cell in a CREATE
just in case a DOES> is executed later, but that's the cost for
portability to implementations that are able to embed something at the
head of the DOES> segment that can acts as a target for a CFA.

That means you wouldn't want to ditch DOVAR in favor of DOCREA because
while that space inefficiency might not be that much relative overhead
for a larger CREATEd structure or stack pad, it would start to add up
if present in every VARIABLE.

However, you could ditch DOCREA, by just putting DODOES in place when
you CREATE the word and starting the target address out at a stub that
is, in effect:

:noname DOES> ;

Then DOES> only has to update that DODOES target address, and CREATE
only has to set a variable with the address of that most recent DODOES
target address.

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

#8210

"BruceMcF" <agila61@netscape.net> wrote in message
news:6cc60bcb-a38a-4108-9d53-60d189f33d0f@t38g2000yqe.googlegroups.com...
> On Dec 18, 7:53 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
...

> > I have a CFA routine which I call DODOES. It gets the address for
> > the "code stub in the word that contained DOES> to start up the
> > interpreting of the following section" which I'll refer to as
> > after-DOES> address hereafter.
>
> Where is that address for the DOES> segment stored? Under
>    <BUILD ... DOES>
> ... a DODOES was stored in the CFA, the address of the DOES
> segment was the first data entry, and DOES> executed the first data
> entry in the built word and returned the address of the second data
> entry in the built word..

That sounds like what I'm describing.  It's fig-Forth based.  fig-Forth has
both <BUILDS and CREATE.  I've not implemented the <BUILDS and
don't plan to.  I did a fig-Forth like CREATE or so I thought ...

> The innovation in moving from <BUILDS ... DOES> to
> CREATE ... DOES> was DOES> setting things up so that the
> address for the DOES> segment in setting it up so that address
> *is* the CFA entry,

Ok.

Perhaps, I may have merged the two concepts or implemented more of a <BUILDS
instead of a CREATE.  This may be because of following the fig-Forth way, or
because of the limitations I was seeing for runtime values for the CFA using
C.

In my post to Ms. Rather, it seems a few examples are working, which I
thought shouldn't be working due to intermediate COMMA's.  So, I'm going to
have to more thoroughly review what is actually being done.  I.e., from
reading my code, I think the address for the after-DOES> code should either
be shifted to a wrong location, or it should overwrite data in the PFA area.

> so there is no difference in size with a regular CREATEd word,
> so you can CREATE in one word or on the command line and
> then execute DOES> in some following word.

Ok.

fig-Forth indicates DOES> is compile only.  I guess Forth moved away from
that.

> The innovation in moving from <BUILDS ... DOES> to CREATE ... DOES>
> was DOES> setting things up so that the address for the DOES> segment
> in setting it up so that address *is* the CFA entry, so there is no
> difference in size with a regular CREATEd word, so you can CREATE in
> one word or on the command line and then execute DOES> in some
> following word.

I'll have to think about whether or not I can find a solution to do those
two things (address in CFA no PFA and same size PFA as normal CREATEd
word) with the constraints I'm having on CFA values.  I'm not sure that I
can.
However, I'm not entirely clear on why those cited situations won't work.
The functionality of DOES> is independent of the other word(s).  So, why
does it matter if DOES> is used in a different word? or interactively?  I
could probably use a couple of examples.  I may have built something
different from either <BUILDS or CREATE ...

> > The after-DOES> address is compiled by DOES> into a word's
> > PFA.  DOES> also compiles DODOES into the CFA.
>
> Then I assume you have to pad CELL with a spare cell and return
> the address two cells after the CFA as the data field address.

No, I'm not.


Rod Pemberton

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web